Peter H. Thomas

Unexpected Use for NAT/PAT

Published April 6, 2025, 9:17 p.m. in 'Tech'

As an MSP, our techs often have occasion to connect to some service at our customers over the internet that's limited only to our office's IP addresses. We recently changed internet connections at our offices and, along with that, our IP addresses. We ran our old and new internet connections side by side for a bit while we worked out any issues. This allowed us to implement an interesting use for NAT, or more appropriately, PAT (port address translation), combined with routing to give our techs time and the ability to access one such service and update the list of allowed IPs before removing our old internet connection.

We wanted to have our new internet connection set as the primary, but we needed to allow this other traffic without building a simple route policy that said to send that traffic out the old internet connection because in this case it was HTTPS. We wanted to find bugs and fix them, not just sweep them under the rug and make chaos for ourselves the day the old connection goes away.

SonicWall

The firewall at our main office is a SonicWall so I'll be using that as the first example. In SonicWall's case, routing takes place before outbound NAT does, so can we use that to make the firewall pick out just these packets? The destination service we want to connect to at the customer is HTTPS (TCP 443), but we can use a different port to trigger this temporary workaround. I just picked port 61443 for this because I didn't think anything else would be using that.

X1 is the interface for our old internet connection, the placement of the default WAN interface in SonicWall world. The service is a custom service defined as TCP 61443. So, we're pushing traffic for that destination port number out our old connection whose IP is already in the allow list on the customer side for the application we need to access. Our metric for this route needs to be 1 so this sits at the top of the evaluation order. But, 61443 is the wrong port number. So, the next step is to change that. We use an outbound NAT rule to do this.

The left side ("Original") is the settings to match traffic, so we want to match using the Service, our custom TCP 61443 object. Routing has already taken care of setting the outbound interface for us so we can match using that, X1. We then, on the right side ("Translated"), set the source IP to the X1 interface IP and the service (destination port) to HTTPS. Now, we're where we need to be.

Other Firewalls

At home I use the OpenBSD PF firewall which has worked for me quite well for most things, even some odd things I've had to do, however, it does not appear that it can do this. As of OpenBSD 7.6 (current as of the time of this writing) the rdr-to translation option can change the destination address or the destination address and port number, but not only the destination port number.

At a previous job I used Watchguard firewalls and I knew from memory this couldn't be done, but I confirmed this in their documentation. Their NAT configuration is significantly less capable than SonicWall's.

In the past I also have worked with the iptables firewall in various Linux distributions and it's fairly flexible as well, but it also appears not to be able to do this by itself. It seems to be able to do the same thing as OpenBSD PF, change both destination address and port, but not only the port. It looks like you can do this using iptables to classify the packets (match temporary destination port) and set a "mark" on the traffic, then use a couple of ip route commands to make a new routing table for this traffic, setting the default route in the separate table to the desired gateway and finally an ip rule command to place the "marked" traffic in the separate routing table. This is loosely based on The LARTC HOWTO.

I found a loose suggestion that nftables (also built on the Linux netfilter system like iptables) might be able to do this by itself, but I didn't do extensive research on this or any testing. I also can't seem to find the article I read on this now that I'm looking back at all the tabs I had open.