Network requirements: port 52311 with bidirectional TCP/UDP

Usage and Config Platform
1

“Please open port 52311, bidirectionally for TCP/UDP”
“You need to open port 52311, bidirectionally, for TCP/UDP”
“According to the wireshark/tcpdump trace, you haven’t to opened port 52311 bidirectionally for TCP/UDP”

It sounds straightforward but my professional experience in a customer facing role has proven that the requirement is difficult for the vast majority of customers to meet fully on all segments until there has been a certain amount of exposure to the product.

The requirement becomes more problematic for customers with external service providers.

After an implementation is configured properly a later move to a new service provider introduces a large risk due to a likelihood of a misunderstanding or miscommunication.

Why?

What can IBM do to improve the way this requirement is communicated? Is that requirement too simplified? Does the installation documentation need better diagrams or added configuration scenarios?

I would be grateful if someone who has been through this from a network administration perspective can provide some insight.

1 Like
2

I’ve been working with IEM in a customer facing and non-customer facing role for a few years from top (database and application installation) to bottom (network and client setup and maintenance) and I’m confused by what you’re asking. Are you suggesting that some customers don’t want to open these ports to make the application work because they don’t know how it works?

3

Does the installation documentation need better diagrams or added configuration scenarios?

This diagram found on the dev works community is probably the most informative diagram when communicating the network requirements to a client. It goes into detail on each connection type and also specifies the direction of that communication.

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Network%20Traffic%20Guide

Regards,

Gwyn

1 Like
4

Not really following your question either. We stood up the entire solution in the datacenter and had comms down to 1250 remote locations with very little headache and many less ports opened up than similar products, like BladeLogic, which required multiple ports with bi-directional communication requirements. What problems are you experiencing with external service providers?

5

Customers that I have worked with over the past 4 years seem to find meeting the requirement difficult not because they don’t want to meet it, but because the ownership of network administration typically doesn’t belong to the same staff that operates IEM. Most of my customers, though not all, have been at a large scale - 50K endpoints or much larger on a single IEM server.

When the solution is architected and the requirements are drafted, the customer will typically nod and say they understand this network requirement.

Then when installation day arrives, we find the port hasn’t been opened or maybe it is open for one of the protocols but not both. Or it is open for both but it isn’t synchronous. And we spend hours, sometimes days going back and forth. The firewall owners will say “everything is open,” the IEM staff will try to find other potential interpretations of client log and tcp dump errors and presume there is something wrong with the product. Net result is time is wasted. A lot of time that could be spent doing something much more productive.

I just went through this again with a customer that has had their implementation up and running for about a year. One of their segments was moved to a new external service provider. Unsurprisingly there was an outage on that segment for 3 business days. The customer and the network service provider kept hitting the ball back to me, asking why the product wasn’t working.

It took that many days to convince the right person that the port they said was open really wasn’t, despite the wireshark trace results and log file interpretations. And once the port was open, TCP and UDP weren’t configured for bidirectional communication.

I don’t think it is often, if ever, that there is a reluctance to open a port. I think the administrator(s) in charge of meeting the requirement simply don’t understand it, but maybe I’m wrong.

Based on the responses this could also be a problem isolated to large scale customers whose IT staff have very compartmentalized responsibilities. Communication breakdown?

Regardless of the cause, I’d really like to find a way to prevent this loss of time for all parties involved. If there is a way that IBM can do a better job of articulating the requirement, I’m all for starting the movement.

2 Likes
6

Hi GwyndafDavies

I agree - I use a version of that as the source for requirements documents and it does (in my opinion) contain all the needed information to stand up a straightforward IEM solution. In practice it hasn’t seemed to be all that helpful for network administrators - either that or they are perhaps too far from the fold to be reading it.

This thread is making me wonder whether the issues I see in the field are isolated to large scale customers with compartmentalized IT roles than the general IEM audience.

1 Like
7

When explained like that, it does feel like a breakdown in communication on the customer’s side outside the control of IBM. All IBM can provide is what is necessary for their application to function. They can’t dictate to the customer’s network team what they must do anymore than the customer experiencing this frustration. Most layer 8 issues will remain our of your control.

8

Honestly I do not think it’s anything that you are doing wrong or can do about this to a certain degree. I have lived through the networking troubleshooting where the port was said to be opened and it really isn’t. Personally, I think it comes down to many organizations networking teams reluctance for security’s sake to open any ports. From a Systems Administrator’s\Customer’s perspective I love the fact it’s only 1 port that needs to be open (TCP and UDP) in the High Range (Which hackers usually shy away from) vs. AD, for example, which requires 19+ ports to be opened to operate normally. My suggestion is to possibly heavily emphasize that it only requires one port which is more secure for the customers organization in general and/or contrast against Active Directory or other End Point Management Systems which requires many more ports to be open. There will always be those customers that feel that even 1 port is too much and will require those troubleshooting sessions and proof that the port still isn’t open.

1 Like
9

I run BigFix with over 65,000 nodes and we have the wild west of networking. Sometimes the ports are open and sometimes they not and maybe its one way or the other way. So I feel i have lived through all of these troubleshooting scenarios. The larger the network the troubleshooting is just amplified and can affect small customers too.

Wire shark is a good technical tool but can be overkill to verify a simple network connectivity problem. A test I ask client to perform for connectivity issues are from the client machine is have them open up a web browser and tell them to paste the gatherURL into the address line:

Client → Server Test

http://yourservername:52311/cgi-bin/bfenterprise/besgathermirror.exe?url=http://sync.bigfix.com/cgi-bin/bfgather/bessecurity

…and you should see results, afterall bigfix is really a glorified web server :smile:

reference:
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/BigFix%20Monitoring

This basic test at least tells you TCP 52311 is open client → server/relay.

Server → Client Test

You can send a client refresh from the console (assuming the client has connected and shows up in the console) and check the client logs for UDP client refresh update.

Other options are using a port scan tool from client to server and server to client to check the ports are open.

In some instances UDP 52311 inbound to the client is restricted intentionally and a as long as your client can talk outbound you can enable and set command polling to allow the client to talk out if the UDP ping is not making it to your client.

reference:
http://www-01.ibm.com/support/docview.wss?uid=swg21505846

So technically not correct but its an easy thing to tell new customers to open this port for both protocols.

BigFix Client: (inbound) UDP 52311 from servers/relay
BigFix Client: (outbound) TCP 52311 to the servers/relays

BigFix Server: (inbound) TCP 52311 from clients/relays
BigFix Server (outbound) UDP 52311 to client networks

Hmm and finally to a suggestion what IBM can do:
How about before even installing bigfix on any system is have IBM write a small tool which opens up a listener port on 52311 UDP and TCP and install on a intended server and client and the tool could also query the other system by entering a IP of the other host. If successful the tool would respond with a success or fail. This may help new client perform a simple check between systems. You could provide the tool to customers and tell them once they have passed you at least have the basic network requirements to install BigFix. Other checks could be added such as 80 or 443 if webreports is going to be accessed. Basically a pre-flight tool customers can run.

Stacy Lee
Stanford University

2 Likes
10

Excellent feedback, Stacy. Thank you!!
Mary McGough
IBM

11

New link to the netowrk traffic guide mentioned above:
https://bigfix-wiki.hcltechsw.com/wikis/home?lang=en-us#!/wiki/BigFix%20Wiki/page/Network%20Traffic%20Guide

5 Likes
12

Is it just me? When I go to the new Network Traffic Guide page, I see the text but not the graphic.

–Mark

13

Nope, not just you. I saw a problem report on it already.

14

Hi @JasonWalker … any update on correcting the issue? The page is still not showing the diagram - only its text.