On 1 Jul 2017 7:13 am, "Pascal Hambourg" <pas...@plouf.fr.eu.org> wrote:
Le 30/06/2017 à 15:09, Igor Cicimov a écrit : > On Fri, Jun 30, 2017 at 3:50 PM, Pascal Hambourg <pas...@plouf.fr.eu.org> > wrote: > >> >> Stateful NAT requires symmetric routing, i.e. reply packets go through the >> router that did the NAT operations on original packets and keeps the state >> for these NAT operations. >> >> With the host as gateway and without the SNAT rule, routing is asymmetric >> : >> client -> router VM (DNAT) -> server VM >> server VM -> host -> client >> >> Reply trafic cannot be un-DNATed and communication fails. >> > > I completely agree with that and that's what I would expect to happen. > However, as per OP's initial email (I cite): > > "*It works like a charm*, but there is one problem: my mail server receives > > all the connections from the router, which has its own private IP address > (10.7.33.100), so the mail server can't enforce SPF policies nor DNS RBL > rules on incoming mail connections." > > his setup was working "like a charm" and the only problem was that the > source IP the email server was seeing was the one from the router vm and > not the client one, nothing about failing connections. > In his second mail, after admitting that the problem was caused by the SNAT rule, the OP also wrote : "The problem is that without that rule things do not work at all (connections time out)." This of course rang a bell. As we all know, NAT is most often used to work around routing flaws. But, as we can see again, it also brings its own flaws. You know what, i just checked the iptables rules the op sent again and realized this: -A POSTROUTING -d 10.7.33.109/32 -p tcp -m tcp --dport 25 -j SNAT --to-source 10.7.33.100 is NOT how you would do SNAT with DNAT, you normally would need: A POSTROUTING -s 10.7.33.109/32 -p tcp -m tcp - -j SNAT --to-source 10.7.33.100 *sigh* sorry for the noise
