In an enterprise network, it's very, very unlikely that an edge router is doing any firewalling. They can do it, but it's not only cumbersome to do it there, but also a massive resource drain.
Often they do basic stateless packet filtering, but definitely nothing akin to stateful, connection-oriented firewalling. It's important to make the distinction, because filtering in this case is completely uni-directional and if you want bi-directional equivalence you have to write an inverse rule for it. Filtering polices are applied per interface, so generally you apply them on the outside only.
Think of it as sort of a reverse of an inbound Internet policy - you write all the drop stuff first (e.g. drop any any eq snmp) and the last rule is a permit ip any any. Next hop is your firewall which does the rest.
For site-tos-site b2b connections, we performed NAT (of the untrusted network space) on the border/edge b2b router, and then the traffic was immediately routed to the firewall. So in this instance, NAT was happening on the router for the customer IP range, and on the firewall for our enterprise IP range.
As a convenience to our customers/partners we always presented ourselves as one of our public IP blocks that wasn't Internet-routed. This prevented them from having any overlapping IP space.
Otherwise, NAT is simply a question of configuring it. And at least in the cisco IOS world (I'm a dinosaur) the two features (NAT vs. firewall) are utterly independent.
> but definitely nothing akin to stateful, connection-oriented firewalling
This is where my confusion comes in, I think.
Surely the variety of NAT that significantly improves the IPv4 address starvation problem (IP Masq by its various names) requires a connection oriented approach to be effective? Maybe not as far as more advanced conntrack rules (trying to get connect-back based protocols to work) but even just a basic stream-over-one port protocol needs basic connection tracking so return packets get back to the right host? If you have enough resource to do that then you have more than enough resource to do the basic “block all external apart from these configured addr+port->addr+port combinations” for IPv6 that is all the protection NAT affords you by accident for IPv4.
> Surely the variety of NAT that significantly improves the IPv4 address starvation problem (IP Masq by its various names) requires a connection oriented approach to be effective?
Actually it doesn't. Well, not really.
With NAT you're generally talking about either 1:1 or 1:many (Masquerading).
In all cases the device doing the NAT maintains a table which is referenced for every matching packet that arrives or leaves.
In 1:1 NAT, the IP in the packet header (Layer-3) is simply rewritten from one address to the other whenever a packet matching both addresses in the NAT table leaves or arrives.
In 1:many NAT, the source port is randomized because you can run into collisions when multiple clients are connecting to the same server:port. So in that case the NAT table contains IP addresses as well as ports. When a return packet arrives, it checks the NAT table and rewrites both the L3 and L4 (port) info before passing it along.
Often times firewalls will randomize the source port when doing 1:1 NAT as a security measure, but after all these years I don't really remember why that's helpful. :-\
But that's really the extent of tracking connections with NAT.
Now when you're talking about firewalling, there's a lot more to track, such as connection start/stop/timeouts/lifetimes, total throughput, TCP state (handshakes, sequence numbers, etc.), closing open sessions when seeing things like TCP RSTs or FINs or ICMP unreachables. The amount of data and CPU is dramatically higher, and tailored to the software doing the firewalling. I believe in many cases simple L3/L4 rewrites can happen in hardware.
I haven't talked about any of this in several years so I hope I'm making sense.
Often they do basic stateless packet filtering, but definitely nothing akin to stateful, connection-oriented firewalling. It's important to make the distinction, because filtering in this case is completely uni-directional and if you want bi-directional equivalence you have to write an inverse rule for it. Filtering polices are applied per interface, so generally you apply them on the outside only.
Think of it as sort of a reverse of an inbound Internet policy - you write all the drop stuff first (e.g. drop any any eq snmp) and the last rule is a permit ip any any. Next hop is your firewall which does the rest.
For site-tos-site b2b connections, we performed NAT (of the untrusted network space) on the border/edge b2b router, and then the traffic was immediately routed to the firewall. So in this instance, NAT was happening on the router for the customer IP range, and on the firewall for our enterprise IP range.
As a convenience to our customers/partners we always presented ourselves as one of our public IP blocks that wasn't Internet-routed. This prevented them from having any overlapping IP space.
Otherwise, NAT is simply a question of configuring it. And at least in the cisco IOS world (I'm a dinosaur) the two features (NAT vs. firewall) are utterly independent.
https://community.cisco.com/legacyfs/online/legacy/0/8/0/600... https://www.cisco.com/c/en/us/support/docs/ip/network-addres...