Ephemeral Ports and Badly Behaved Software

A recent application issue pointed out what happens when a developer doesn't implement a normal TCP/IP port usage model.

In this case, the application doesn't appear to do what a normal application should: pick an ephemeral TCP port over 1024, then use that as the source port. Instead, the application binds to a specific source and destination port.

This might not be as much of an issue if the application didn't also suffer from a bad habit of not using keepalives for very long TCP sessions, necessitating a firewall rule that allows extremely long TCP sessions - over 18 hours to allow daily jobs to run.

When combined, this means that any TCP session that isn't properly closed will fail to re-start on a stateful firewall - and the application then breaks. The solution? Non-stateful firewall rules allowing host A to talk to host B, sourced from port X to port Y. You lose state tracking, protocol awareness, and any sort of application awareness, but you do get a working firewall rule even if bad things happen.

In the long term, we'll be asking the vendor about their take on how TCP/IP communications should be implemented...