2023-10-16
The two places firewall NAT can happen in our network
In our network setup, we have internal 'sandbox' networks in RFC 1918 IP address space, then our public networks that can talk directly to these sandbox networks, and then the university's broader networks and the Internet. In order to talk to these outside networks, the sandbox networks must be NAT'd to public IP addresses (in our public networks). There are firewalls directly in front of each sandbox, and a further perimeter firewall between all of our networks and the outside. In this environment there are two places that you can do NAT, and we've done both of them over time.
The obvious and appealing place to do NAT is on the internal sandbox firewalls that are directly connecting the RFC 1918 networks. It feels correct that when internal traffic passes through these firewalls, either we know it's going to our networks (and needs no NAT, because those networks know how to route it back to the firewall), or it's got a public IP that's guaranteed to work right no matter where the traffic goes. If we slip up and forget some piece of our internal network, there's no harm done; the traffic will be NAT'd to one of the firewall's public NAT Is, and everything inside can reach those anyway (more or less).
The other place to do NAT is on the perimeter firewall. The internal firewalls don't try to do any NAT'ing and just let all of those RFC 1918 addresses fly right through, regardless of where they may be going. Only when the RFC 1918 addresses are going to the outside world does the perimeter firewall see them and then NAT them. The obvious drawback of this is that if we forget to add the NAT configuration for some new internal network to the perimeter firewall, we'll be leaking RFC 1918 addresses out to the world until we realize why it can't talk to the Internet.
In exchange for that, however, you get some nice advantages. The first advantage is that all of your NAT'ing is in one place, in one set of firewall rules and one set of firewall state tables. This can make it easier to keep track of what NAT you have, and it also likely puts the NAT'ing at the same place as the firewall rules for machines that get their own individual NAT IPs (using OpenBSD's bidirectional NAT, or BINAT). The other advantage is that the public IP addresses you use for NAT'ing don't have to be on the same network as the internal firewalls (and don't have to be answered by anything on your networks).
When NAT'ing is done directly on the internal firewalls, traffic to the NAT IPs has to wind up on the relevant firewall. This generally means each NAT IP has to be an IP alias on the firewall, on the same network as the firewall itself. When the NAT'ing is done on the perimeter firewall, traffic to the NAT IPs from the outside world just has to go through the perimeter firewall and the NAT IPs are entirely virtual; they can be random IPs on any public networks that will be routed to you through your perimeter firewall. This can give you a lot of flexibility.
(This isn't quite true for all perimeter firewall layouts, but I think it's true for a lot of them. We used to have one of the layouts where this wasn't quite true, but have since moved to one where there's a little touchdown network between the university's backbone router and our router, and the bridging perimeter firewall sits between the two.)
We used to do NAT'ing on the internal sandbox firewalls, but a number of years ago moved to doing it on the perimeter firewall. My view is that the shift has been a definite quality of life improvement for us that's made our NAT environment simpler and easier to follow. There's now a real separation of concerns for our firewalls; our internal firewalls only worry about filtering (internal) traffic, while our perimeter firewall only worries about NAT and filtering external traffic.
Sidebar: Some of our old NAT decisions come from history
We didn't always have either sandbox networks or a perimeter firewall; back in the old days, the department (like lots of other places) had only a set of un-firewalled public networks. As I understand it, the sandbox networks and their firewalls came first; they were added as the department ran out of public IPs for new machines (or talked people into not exposing their new machines to the Internet). These new firewalls had to do NAT themselves, since there was no perimeter firewall yet.