On Wednesday, January 05, 2011 07:51:19 pm Michael H. Warfield wrote: > On Wed, 2011-01-05 at 17:26 -0500, Lamar Owen wrote: > > I refer in particular to Cisco IOS NAT, IOS 12.4(23) mainline on a > > 7206/NPE-G1, using NAT pools and overloading. Incoming packets > > addressed to the outside interface that don't match the flows that the > > router knows about get dropped.
> What you say is true but is equally true if you retain the stateful > firewall at the heart of the NAT engine and eliminate the NAT. The Cisco NAT is by default stateless; you have to specifically configure stateful NAT (on platforms that support it, and if your IOS feature set has that feature), but that mostly just gets you HSRP resilience for NAT; the packet translation itself is stateless (and hardware accelerated on some platforms, especially those with PXF which can do the IP header rewrites at wire speed). 'Stateful Firewalling' in Cisco-land is 'packet inspection' or even deep packet inspection, and is an additional feature set (and an additional cost for the IOS image), but images which cannot do stateful inspection can do NAT overload. Stateful firewalling in that context is also referred to as CBAC (Context-based Access Control). This inspection is a control-plane activity that writes ACLs, whereas NAT happens in the data (forwarding) plane, as a separate step from the ACL application (also in the forwarding plane). > The NAT > is not what's giving you this protection. It's the stateful nature of > THAT particular NAT which is the same as as a linear stateful firewall. > No difference. And other forms of NAT do not enjoy this. [snip valid NAT config that is set up to not provide that benefit] > NAT, in and of itself, is not providing the security. It's the state > engine at the heart of most (but not all) NAT devices and all stateful > firewalls. It's not the NAT, it's the firewall. NAT in cisco IOS is stateless unless certain features are turned on. The forwarding plane as part of the switching process performs the header translation (if one exists) and then routes; if there is no destination for the route it's blackholed, or hairpinned (depending on configuration). That is, given the NAT translation table snippet: tcp 10.10.10.10:52650 192.168.1.118:52650 74.125.67.99:80 74.125.67.99:80 tcp 10.10.10.10:1769 192.168.1.166:1769 74.125.67.99:80 74.125.67.99:80 And assuming no other translations are in the table, 74.125.67.99 could scan 10.10.10.10 all it wants; only packets to ports 52650 and 1769 will get statelessly translated (bidirectionally; the return packets also get translated for a tcp translation) to the respective addresses on the inside, and only to those ports; all other packets to that 10.10.10.10 address will be left untranslated and routed to the interface with 10.10.10.10 on its subnet. That could be a Null device for blackholing purposes, or it could be a honeynet, or it could even be a real host. Please see the Cisco document entitled 'NAT Order of Operation' (the direct link is long, and can change at seemingly random times for some reason) for more detail and pointers to how NAT works in IOS. The above example table is part of the following example IOS NAT config (both derived from what I have here, with addresses changed): ip nat pool metro-e 10.10.10.1 10.10.10.13 netmask 255.255.255.240 ip nat inside source list 1 pool metro-e mapping-id 10 overload This is not firewalling (nothing is blocked by the NAT itself; but only what's in the table gets translated), and is not stateful. The addresses that get added to the table have an associated access-list, but that's just a convenient way to list addresses; a route-map is also a possible source of addresses for the NAT operation (ip nat inside source route-map ..... ). And I realize that I'm describing what some call port address translation (PAT) or even as NAT-PT (network address translation - port translation), but it's all configured in the common NAT engine. NAT is a far simpler operation than stateful firewalling; packet inspection to overcome some of the broken protocols that are NAT-hostile brings in the stateful firewall engine that makes things like CBAC possible. NAT only has to deal with address and port number translation in the IP header, and, as mentioned, can be done in pattern matching hardware like Cisco's PXF. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
