Timeline for Difference between SNAT and Masquerade
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 9, 2019 at 2:09 | comment | added | pgoetz | SNAT is useful, if for example you have multiple IP addresses assigned to the outgoing interface and want the NAT source to be a particular one of these. | |
| Mar 18, 2018 at 14:50 | comment | added | eel ghEEz | @CarlG, I guess the glitches would occur with the permanently tracked -j SNAT (as opposed to the recycling tracking with -j MASQUERADE) when a new outgoing connection from a LAN node uses the same source port number as the severed outgoing connection from the same LAN node. In that case, I can imagine incoming packets from the old outgoing connection getting sent to the node, confusing its TCP stack. As for the benefit of -j SNAT, what if the NAT box is configured with the same external IP address and the kernel keeps forwarding packets from old connections instead of replying with RST? | |
| Nov 9, 2016 at 12:29 | comment | added | Carl G | I'm having trouble understanding the benefit of SNAT. Why does it matter if the kernel tracks connections or not when the interface goes down? Regarding MASQUERADE, the netfilter docs say "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." Sounds reasonable (although what are the glitches?) Now looking at SNAT, what is the benefit of tracking lost connections? Why not use MASQUERADE every time? | |
| Oct 3, 2011 at 18:06 | vote | accept | Chankey Pathak | ||
| Oct 3, 2011 at 17:56 | history | answered | Shawn J. Goff | CC BY-SA 3.0 |