dslreports logo

    All FAQs Site FAQ DSL FAQ Cable Tech About DSL Distance DSL Hurdles »»


how-to block ads

This is almost always due to the software firewall recognizing the end of a conversation before the NAT device. As described here, the NAT device keeps a table of current conversations to facilitate translation and routing of inbound traffic. Each entry has an associated inactivity timeout. Software firewalls keep a similar table in memory and have the advantage of being able to remove entries when they detect that a program has unbound the port it was using. If a program is killed unexpectedly, this can be before the proper termination of any TCP connections the program had open (at which point the NAT device could clear its entries). The connection may just "hang" and timeout in the OS before the NAT device.

In the case of UDP, there is no "connection," and the NAT device must wait for the preset timeout to elapse before clearing entries. For this reason, the timeout on UDP entries is often much smaller than that on TCP. However, there are often significant differences between the timeout of the NAT device and that of the firewall / OS /program -- the most common inbound traffic alerts behind NAT are delayed DNS responses. Steve described this here. In this case, the reply arrives a period after the sending of the request which is greater than the firewall / OS / program timeout but less than the NAT timeout. NAT translates and routes the packet, but the firewall intercepts it and labels it an "attack" since it's table entry has been cleared.

Similarly, the occasional dribble of non-SYN flagged TCP packets are not the "TCP ACK SCAN" the firewall might insist they are. If you see SYN (just SYN) flagged TCP inbound from the WAN with a software firewall, then you might start to worry (presuming you didn't forward the relevant port and forget about it).

Expand got feedback?

by Nick8 See Profile edited by JMGullett See Profile
last modified: 2007-06-05 16:34:53