Source NAT on Linux

Had a request come in to try and do a source-based NAT.

The reason for this is that the customer had a ISP router that they presumably could not log in and configure to do NAT with. Behind this router, was a Switch - apparently an L3 Switch that had some intelligence, but apparently it could not do NAT. It could have actually been related to change control, also.

I found this website here, which discussed how to do SNAT.

http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html

Since websites tend to die an move, I will clip the excerpt of text I was interested in:
----------------------------------------------------------------------------------------------------------
You want to do Source NAT; change the source address of connections to something different. This is done in the POSTROUTING chain, just before it is finally sent out; this is an important detail, since it means that anything else on the Linux box itself (routing, packet filtering) will see the packet unchanged. It also means that the `-o' (outgoing interface) option can be used.
Source NAT is specified using `-j SNAT', and the `--to-source' option specifies an IP address, a range of IP addresses, and an optional port or range of ports (for UDP and TCP protocols only).

## Change source addresses to 1.2.3.4.
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4

## Change source addresses to 1.2.3.4, 1.2.3.5 or 1.2.3.6
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6

## Change source addresses to 1.2.3.4, ports 1-1023
# iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023

Masquerading

There is a specialized case of Source NAT called masquerading: it should only be used for dynamically-assigned IP addresses, such as standard dialups (for static IP addresses, use SNAT above).
You don't need to put in the source address explicitly with masquerading: it will use the source address of the interface the packet is going out from. But more importantly, if the link goes down, the connections (which are now lost anyway) are forgotten, meaning fewer glitches when connection comes back up with a new IP address.

## Masquerade everything out ppp0.
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

----------------------------------------------------------------------------------------------------------
Since I used FirewallD, I had to put the NAT rule into the direct.xml rule of FirewallD (I considered trying to put it in a zone-based rule, but decided to use direct.xml).

In testing this, I found some very interesting things. I did not have an IP to NAT "to", since I don't run the networks here, and everything is set up for DHCP. But - I did have two NICs on two separate networks, so I decided to SNAT the IPs of NIC A (10.1.x.y) to NIC B (172.31.x.y).

I used tcpdump to examine packets that typically came out of NIC A as 10.1.x.y, to see if they would come out as 172.31.x.y: tcpdump -A -n -i NICA grep "172.31.x.y"

This seemed to work as long as I had ONE rule for ONE Nic. But if I tried to use TWO rules for the TWO Nics, nothing seemed to NAT at all.