Question: I have a Windows 2008 server and an application that connects over Internet to it. 
From time to time I see that I receive a TCP [RST, ACK] that is ignored by my application. 
Using TCPViewer I still can see that connection is still up.
I did different Wireshark captures and I can see that in case of the RST ignore, another packet is send back, and the connection is never dropped.

```
269037  72.5.42.235 172.16.1.138    TCP 60  9003?54020 [RST, ACK] Seq=2655287284 Ack=371936778 Win=0 Len=0
269038  172.16.1.138    72.5.42.235 TCP 66  [TCP Dup ACK 268965#33] 54020?9003 [ACK] Seq=371936778 Ack=2655238984 Win=2097120 Len=0 SLE=2655243124 SRE=2655287284

```

This usually happens when the connection is bad and I get a lot of latency, delayed packets and retransmissions.
Can somebody explain the situation when a [RST, ACK] may be ignored by an application or operating system?

Answer: 
First: What you describe is NAT, not firewalling. A firewall just filters what can go through, a NAT device changes addresses in packets.

You almost answer the first question yourself. Yes, a NAT device needs to keep track of every session going through it. Most communication on the internet uses TCP or UDP. Both of these protocols use port numbers. A session is defined by source address, source port number, destination address and destination port number. The NAT device needs to maintain a mapping between which numbers on the inside correspond to which numbers on the outside. And then it has to match every packet to an entry in its mapping table and adjust the packet accordingly.

This is also why NAT devices are less than optimal: a normal router is stateless. It doesn't need to keep track of what happened previously and it doesn't need to adjust the numbers and addresses in the packet. If a router fails another router can take over immediately. When a NAT device fails the device that takes over doesn't have the same mapping table and all sessions break and have to be re-established.

Your second question is more complex. One option is to configure port forwarding in one of the NAT devices. Then you let A send a packet to the forwarded port on C. B will change the source address and port to one of its own. When the packet arrives at C it then adjusts the destination address and port so the packet is forwarded to D. Reply packets do exactly the same in the opposite direction.

If there is no port forwarding then it gets more difficult. You need to have the assistance of an external server E. Both A and D have to initiate connections to E. Then E has to coordinate setting up the session between A and D. A and D both send outbound packets to trick B and C into adding entries to their mapping tables. Once those mappings are in place they can communicate directly.

To summarise: the way things usually work is that for outbound packets you have a device that performs source NAT. It changes the source address and port of the internal device to one of its own. For inbound packets you have a device that performs destination NAT. It changes the destination address and port to what is in its mapping table. The mapping table is filled either by manual configuration, by a protocol that lets internal systems request a mapping (didn't talk about those, look up UPNP and PCP) or automatically when the NAT device creates an entry for an outbound packet.
This is one of the problems [Azure service bus relay](http://azure.microsoft.com/en-us/documentation/articles/service-bus-dotnet-how-to-use-relay/) is supposed to solve. It works in case both computers can access the internet. They both connect to azure which then handles the communication between them.