Re: Living with NAT became more important
You are confusing Stateful Packet Inspection (SPI) with Network Address Translation (NAT).
All NAT does is translate one address to another - which is great for IPv4 scarcity. As an example I can configure some switches (Nexus 3k comes to mind) to stateless translate src/dst IP's or Ports from one value to another. There's no firewall, no SPI, and the switch doesn't maintain a NAT/Session table.
SPI (OTOH) monitors network flow pairs (called a session) between two hosts, and creates a session table to track these flow pairs. Most SOHO routers and enterprise firewalls do this by default. And in pretty much in all the stateful firewall deployments when the device receives a packet the logic goes (and apologies for the formatting, I don't have the minimum posts to use HTML tags yet):
* Is this packet part of an existing session? If yes, forward the packet. If no, proceed
* (This varies on platform) - Does the packet match any of my static or destination NAT rules? If yes, perform this NAT operation and proceed. If no, just proceed
* Do I have a route to the source/destination IPs of the packet (located in the IP header)? If no, drop the packet. If yes, proceed
* Do I have a security policy that matches the source/destination IPs, source/destination Ports, and Protocol? If no, drop the packet. If yes, proceed
* (This varies on platform) - Does the packet match any of my source NAT rules? If yes, perform this NAT operation and proceed. If no, just proceed
* Perform other network security functions (IPS/AV/Application Identification/etc)
* Add the flow pair into the session table
* Forward the packet along
You'll notice that NAT operations are done separately from the security functions. This is why I can set public IPs on my hosts and still have full SPI/Firewall functions without the need of NAT.
Now, Source-NAT with Port Address Translation is stateful since we need something like a firewall to track all the translations. But even this stateful inspection can be bypassed with things like NAT Slipstreaming, or NAT busting/punching with a C&C Server. Remember Skype? That's what it did.
A separate service maintains a list of IP addresses used by Skype, and when two hosts want to communicate it would have Host A send a TCP packet to Host B and wait for a response (Host B's firewall will drop this packet). This creates the first flow on Host A's firewall, and leave a TCP session in an Open state for about 30 seconds. Host A tells the service it opened a connection with a specific Source Port.
The service tells Host B to send a TCP packet with the Destination Port of Host A's Source Port. This creates the first flow on Host B's firewall, but it also completes the flow on Host A's firewall, allowing the Skype call to work as expected - without ever having to deal with port forwarding.
Biting the hand that feeds IT
