3

How can I verify that a firewall closes connections on port X to a server after N minutes of inactivity?

Background: I am working on a Java EE application deployed to a Glassfish application server. Clients communicate with the application using RMI-IIOP (TCP). I am seeing connections dropped after 60 minutes of inactivity. I suspect a firewall timeout, so the operations team changed the timeout to 90 minutes to see if it affected behaviour, but I am still seeing connections dropped after 60 minutes of inactivity. I would like to verify that the firewall timeout is working correctly using a simpler mechanism than Java EE and RMI-IIOP.

DavidS
  • 163
  • 1
  • 1
  • 7
  • I suspect this is simple (maybe using SSH, telnet, or a simple TCP client and server), but I'm unfamiliar with basic network behaviour and tools, so I'm hoping you will help me hone in on the right approach. – DavidS Aug 24 '15 at 17:08
  • 1
    Which firewall did they update? The timeout could be in numerous locations (server's firewall, firewall appliance, router, end user's firewall, ISP connection, etc). – Gene Aug 24 '15 at 17:55
  • I'm not sure, @Gene, but I see what you're getting at: they may have forgot something. That's the reason I'd like to verify their work. If I can make a simple(r) connection to the server, and the connection is closed after 1 hour, then I can go to them and say that the infrastructure (whatever it is) is closing inactive connections after 1 hour, and can we please change that. – DavidS Aug 24 '15 at 18:04

2 Answers2

2

If it's available or can be installed, take a look at netcat. You could do something like this.

On the server run:

nc -l 31415

On the client run:

nc -w 5400 <server> 31415

You can change the port number to anything you like, just make sure you can reach it from where you are testing.

A timeout of 90 minutes (-w 5400) is set in the example above. Change that as necessary.

You can test that from multiple locations: On the server itself, on another server/device on the same network, on clients on the other side of any VPN, routers, or firewalls.

More helpful information about netcat:

http://www.thegeekstuff.com/2012/04/nc-command-examples/

Gene
  • 3,663
  • 20
  • 39
  • 2
    Thanks Gene. Actually, if I understand correctly, I will set _no timeout_ for netcat because what I want to test is the firewall timeout. I will run `nc -l 31415` on the server and `nc 31415` on the client, wait some interval (89 minutes, 91 minutes, etc.), and then verify that text is still transferrable. – DavidS Aug 24 '15 at 18:10
  • Cool. I'm not sure if all versions of netcat behave the same (a default of no timeout) so I included it. Just so long as your man page indicates there isn't a default timeout value you'll be fine. – Gene Aug 24 '15 at 18:13
  • I will try this out within a couple days. I need to install netcat and fill out a few forms... :-\ – DavidS Aug 24 '15 at 18:14
  • 1
    My account had insufficient permissions to install Netcat, and rather than obtaining permissions I found it easier to write a [simple TCP client-server in Java](https://docs.oracle.com/javase/tutorial/networking/sockets/readingWriting.html) to copy Netcat's behaviour. I'm marking this answer correct because the principal is identical and I would have rathered use Netcat. – DavidS Aug 27 '15 at 16:54
1

First, start by confirming that it is not any side of the application closing the connection after some idle time period. This can be done by capturing traffic (in Windows use Wireshark and tcpdump in Linux) in both sides and then inspect it looking for closure related packets (e.g. FIN or RST).

Now, if you confirm that none of the application sides is closing the connection, but when you try to send a new packet after a given timeout the connection is not valid anymore (you will observe several retransmission attempts in the traffic log), chances are that this is caused by a stateful firewall removing connections from its state table after a given idle session timeout, for example, the Linux Netfilter idle connection tracking timeout defaults to 5 days as indicated in https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt, nf_conntrack_tcp_timeout_established.

Now for troubleshooting the previous condition, start by shortening the network path between the client and the server (e.g. by using a VPN to put the client and the server in the same subnet) and check that the connection doesn't timeout anymore, just to be sure.

Then, from the regular network path (or incrementally adding nodes to it), open a new connection, wait for X time and try to send a new packet, if it arrives, then double the X value and send the packet again and keep doing this until the packet is not sent anymore, which would provide you a good idea of the configured timeout. Now, of course the previous could be automated with a simple multithreaded client application, otherwise it is just a horrible testing experience.

Jaime Hablutzel
  • 456
  • 5
  • 10