New iptables Gotchas - SNAT VS MASQUERADE

IT牛人.117 2016-02-02 14:01


As a heavy user ofiptablesNAT rules, (advanced home networking, various VPNs on EC2 and other IaaS providers), I feel it’s time for me to better understand how NAT works under the hood with the help ofiptables.

That’s why I started readingiptablestutorialfor the second time.

NOTE: I personally think it is the bestiptablestutorial freely available (even better than some published books). Look at no others ;-D

The first time I readiptablestutorialback in 2012, I was frustrated because my networking knowledge and skills were not up to the level the tutorial requires. So I ended up cherry-picking the useful parts only ;-(

Now it’s totally different, many thanks toXenServer andcontinuously learning .

I’d like to share some gotchas after readingiptablestutorialfor the 2nd time ;-D



Both targets do source NAT (or SNAT) in thePOSTROUTINGchain in thenattable.


  • MASQUERADEdoes NOT require--to-sourceas it was made to work with dynamically assigned IP addresses.

  • SNATworks with static IP addresses.

  • MASQUERADEhas extra overhead and is slower thanSNATbecause each time theMASQUERADEtarget gets hit by a packet, it has to check for the IP address to use.

IMPORTANT : It is still possible to useMASQUERADEtarget with static IP. Be aware that it will add extra overhead (to compute).

For example, network192.168.100.0/24is used for IPsec (strongSwan) clients, so-called right subnet which is the private subnet behind the left participant (IPsec Server). VPN Clients will be assigned IP addresses within therightsubnetas defined in its connection.

For IPsec VPN clients to be able to access the Internet, NAT MUST be done by usingiptables. Outgoing packets need to have their source IP address rewritten to the router (gateway) IP address in their IP header.

Match packets from the192.168.100.0/24network and are leaving frometh0(interface name can vary based on different hypervisors or Linux distributions - systemd VS sysv init).

# stick to SNAT for static IP
iptables -t nat -A POSTROUTING -s -o eth0 -j SNAT --to-source ELASTIC_IP

# don't be lazy, simple but slower due to more overhead
iptables -t nat -A POSTROUTING -s -o eth0 -j MASQUERADE

NOTE: Don’t have to do DNAT for incoming packets within thePREROUTINGchain in thenattable if we turn on ip forwarding in the kernel byecho 1 | sudo tee /proc/sys/net/ipv4/ip_forwardso as to forward packets between interfaces, cool!

BTW: DO NOT usesudo echo 1 >to make changes toprocfs, it won’t work, why? RTFM ;-D

Security Group Implementation in CloudStack / CloudPlatform

Recently I’ve been looking into CloudStack / CloudPlatform Networking, especially the Virtual Private Cloud (VPC) implementation compared with AWS VPC.

The Hypervisor Configuration Guide it explicitly requires Linux Bridge as network backend plus the following kernel parameters:

# switch from ovs to bridge
xe-switch-network-backend bridge

# persistent the values properly :-`)
# control whether or not packets traversing the bridge are sent to iptables for processing
echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 1 > /proc/sys/net/bridge/bridge-nf-call-arptables

Above indicates that basic zone networking uses Linux Bridge, the Security Group implementation is based on Linux Bridge andiptables.

NOTE: I reckon AWS EC2 / VPC Security Group is the same.

Owner match

Use to match packets based on the identity of the process that created them.

The owner can be specified as the process ID either of the user who issued the command in question, that of the group, the process, the session, or that of the command itself.

NOTE: The owner match only works within the OUTPUT chain, for obvious reasons: It is pretty much impossible to find out any information about the identity of the instance that sent a packet from the other end, or where there is an intermediate hop to the real destination.

Even within the OUTPUT chain it is not very reliable, since certain packets may not have an owner. Notorious packets of that sort are (among other things) the different ICMP responses. ICMP responses will never match.

match options

  • --cmd-owner

  • --uid-owner

  • --gid-owner

  • --pid-owner

  • --sid-owner


iptables -A OUTPUT -m owner --cmd-owner nginx
iptables -A OUTPUT -m owner --uid-owner 500

Last but not least

I started learningiptablessystematically in 2012, soon addicted to it and kept sucking everything that I didn’t know or understand. Countless hours spent…

Plus over 2 years field experience with XenServer (Cloud Infrastructure), I can claim that my Linux networking skill has leaped to a new level ;-D

The leap all started from in-depth learning ofiptables, it’s worth it ;-D

Below is the Traversing of tables and chains diagram, just to pay tribute to the author ofiptables tutorial- Oskar Andreasson ;-D

NOTE: Oskar wrote the excellent in-depth tutorial 10 years ago, imagine how good he (his networking) is now ;-D

iptables - Traversing of tables and chains


[返回] [原文链接]