LUW to LUW Firewall schematics

Jorg Lueke

LUW to LUW Firewall schematics

Does someone have a link to an ideally helpful diagram or description of what is needed port wise for firewall requests when connecting from one LUW instance to a remote one. Trial and error will probably get us there but it would be nice to see it described somewhere official

 

Db2 Dba, Sysprog, Architect

https://www.linkedin.com/in/jorg-lueke-8b391b4/

Luke Numrych

RE: LUW to LUW Firewall schematics
(in response to Jorg Lueke)

Hi Jorg,

Apologies if I misunderstood your question...

If you are simply looking to connect to a database on a remote system to execute queries against it, then all you should need is a firewall rule allowing traffic from your source IP address to the IP address of the remote system on the remote instance port.  You would then catalog the remote instance as a node and then the remote database as a database at that node to connect to it via CLP.  Same requirements would have to be satisfied for federation.

 

Luke

Jorg Lueke

RE: LUW to LUW Firewall schematics
(in response to Luke Numrych)

Hi Luke

Yes in theory it should be client to db server on port 50000 (or whatever the db is set to). But with just that rule the connection hangs. It seems there's a requirement for packets coming back...I think.

Luke Numrych

RE: LUW to LUW Firewall schematics
(in response to Jorg Lueke)

Can you elaborate on "connection hangs"?  At which point of the connection process does it hang?  By "hang", do you mean that no error is returned at all?

It is possible that your firewalls are configured in a way to allow return traffic to pass only on certain client ports... You would have to discuss that with your firewall team.

I've had the opportunity to work with some "smart" firewalls recently, and I had a similar issue - the client-side could establish a TCPIP connection to the server via telnet for example, so on the surface it seemed that traffic was allowed to pass on the DB2 instance port.  However, the moment I would attempt to send any DB2 traffic (as in a "connect" request for example...), the socket would get closed.  It turned out that the "smart" firewall was configured to inspect packets and stop any DB2 (yes, it was smart enough to smell out that it was a DB2 conversation) traffic.  It was closing the flow by sending a reset packet to both ends of the connection.  What I saying is that maybe in your case the firewall stops passing the traffic, sends a reset packet to the server, but does not send a reset packet to the client.  This could certainly make it look like the client is "hanging" because it would be waiting for a response from the server (or a reset packet) that will never arrive because the server got a reset packed ("disconnect") and the firewall black-holed client's side of conversation.  

It may be hard to prove this without running a packet capture tool on both sides of the connection.  But you could inspect the network connections on both sides of the conversation:

  1. When establishing a telnet (or netcat) connection from the client to the instance port
  2. When attempting to issue a "connect" request from the db2 client to the instance port

If #1 works, and you see a connection established on both ends, you do have network connectivity.

If for #2 you see a connection opened on the client, but not on the server (or you may see it opened and then immediately closed), then a network device in between the two ends is closing the flow.

If for #2 you see the connection opened on both ends, and it stays open on both ends, but traffic still does not flow, the firewall may be black-holing the flow without bothering to send a reset packet to either end.  Generally, that is not good, as each un-terminated connection will consume a portion of server's resources.  You could DOS a server with that... Of course, timeouts exist for a reason and should prevent that from happening.

Jorg Lueke

RE: LUW to LUW Firewall schematics
(in response to Luke Numrych)

Thanks Luke,

I think it was the return packets that were still being blocked. I updated a request I stole from another database group to include a small range of ports to include response ports and allow for bidirectional communication. This seems to have done the trick

Db2 Dba, Sysprog, Architect

https://www.linkedin.com/in/jorg-lueke-8b391b4/