TCP With Firewall

What happened the next day

Sure enough, the pattern repeated itself the next morning. Application servers locked up tight as a drum, with the threads inside the JDBC driver.

Absence of traffic

This time, we were able to look at traffic on the databases’ network, but found nothing at all. The utter absence of traffic on that side of the firewall was like Sherlock Holmes’ dog that didn’t bark in the night—the absence of activity was the biggest clue.

Decomposition of the server

We had a hypothesis. Quick decompilation of the application server’s resource pool class confirmed that our hypothesis was plausible.

How long can a connection persist?

We said before that socket connections are an abstraction; they exist only as objects in the memory of the computers at the endpoints. Once established, a TCP connection can exist for days without a single packet being sent by either side. As long as both computers have that socket state in memory, the “connection” is still valid. Routes can change, and physical links can be severed and reconnected. It doesn’t matter. The “connection” persists as long as the two computers at the endpoints think it does.

Need for firewall

In the innocent days of DARPAnet and EDUnet, that all worked beautifully well. Pretty soon after AOL connected to the internet, though, we discovered the need for firewalls. Such paranoid little bastions have broken the philosophy and implementation of the whole Net.

Firewall implementation

A firewall is nothing but a specialized router. It routes packets from one set of physical ports to another. Inside each firewall, a set of access control lists define the rules about which connections it will allow.