> My point is that the NAT concept is a transport concept. The security only > results from NAT implementations because/when they need to manage sessions, > and what concidence, stateful filtering is based on sessions. I will admit that the security offered by a NAT solution is as a result of a design coincidence, not necessarily because of an original intent. However, that doesn't negate its existence. > so you configure NAT to map the 10.* class to a global address (1.2.3.10 > for example). This is where my comment about "modern nat" and Linux's IP masquerading in particular come in. In Linux, with masquerading, these mappings are not done on a multi-multi address mapping basis, they are made on a multi-(source IP + port) to a single source IP with a dynamic port. To re-state your scenario, if: a packet comes from 10.0.0.1 to the NAT, it is sent as being from 1.2.3.4, the address of the nat device, and assigned a dynamic source port number > now, when a packet comes from the internet, your NAT will check whether it > corresponds to a NAT session The packet must be destined for the NAT itself, and it must be to a specific port, and (if so configured) be from the address that the original mapping was to. This establishes a session very similar to a stateful inspector (except that "intelligent" stateful firewalls often have more options as well). > This means NAT should not reject packets just because they are not part of a > mapping. As a result, NAT does not filter flow. How do you mean that the NAT does not filter flow? > Besides, there is no modern NAT (NAT is NAT). What you are referring to is > a "suit" [sic] that does both NAT and filtering. so it is a solution that implements All the IP masquerading code does is a _modern_ version of NAT. Old NAT (to me) is internal source IP to dynamic/static external source IP mapping, on a multi-multi basis. Modern NATs allow multiple internal source IPs to all be mapped to one external IP and do so by keeping some state information. This makes the internal network machines effectively invisible* * There are still ways to gather some information ... see insecure.org -- Michael T. Babcock CTO, FibreSpeed - [To unsubscribe, send mail to majordomo@lists.gnac.net with "unsubscribe firewalls" in the body of the message.]