Re: firewall rules for NAT

On 1 Jul 2017 7:13 am, "Pascal Hambourg" <pascal@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 <pascal@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