Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #182649 > unrolled thread

firewall rules for NAT

Back to article view | Back to linux.debian.user

Contents

  firewall rules for NAT Lucio Crusca <lucio@sulweb.org> - 2017-06-25 23:10 +0200
    Re: firewall rules for NAT Dan Purgert <dan@djph.net> - 2017-06-26 11:50 +0200
      Re: firewall rules for NAT Lucio Crusca <lucio@sulweb.org> - 2017-06-27 13:30 +0200
        Re: firewall rules for NAT Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-06-27 23:40 +0200
          Re: firewall rules for NAT Lucio Crusca <lucio@sulweb.org> - 2017-06-29 10:40 +0200
            Re: firewall rules for NAT Igor Cicimov <icicimov@gmail.com> - 2017-06-30 00:40 +0200
              Re: firewall rules for NAT Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-06-30 08:00 +0200
                Re: firewall rules for NAT Igor Cicimov <icicimov@gmail.com> - 2017-06-30 15:20 +0200
                  Re: firewall rules for NAT Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-06-30 23:20 +0200
                    Re: firewall rules for NAT Igor Cicimov <icicimov@gmail.com> - 2017-07-01 03:30 +0200
                      Re: firewall rules for NAT Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-07-01 11:40 +0200
                        Re: firewall rules for NAT Brad Rogers <brad@fineby.me.uk> - 2017-07-01 13:10 +0200
                          Re: firewall rules for NAT Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-07-01 13:30 +0200
                            Re: firewall rules for NAT Brad Rogers <brad@fineby.me.uk> - 2017-07-01 13:40 +0200
                            Re: firewall rules for NAT Brad Rogers <brad@fineby.me.uk> - 2017-07-01 13:50 +0200
                        Re: firewall rules for NAT Igor Cicimov <icicimov@gmail.com> - 2017-07-01 16:40 +0200
        Re: firewall rules for NAT Igor Cicimov <icicimov@gmail.com> - 2017-06-29 01:10 +0200

#182649 — firewall rules for NAT

I have a server with Debian GNU/Linux as host system.

The host runs several guest virtual machines, but it has only one public 
IP address.

Each virtual machine is a QEMU/KVM Debian GNU/Linux system that runs 
some specific service (so I have one for websites, one for mail, one for 
database, one for ssh connections, and so on).

One of the virtual machines is the router: the host system forwards any 
incoming connection to it and the router forwards the connection to the 
correct VM based on the TCP destination port.

The host system forwards connections to the router with these iptables 
rules (1.2.3.4 stands for the public IP address):

# Generated by iptables-save v1.4.21 on Sun Jun 25 22:33:39 2017
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [86517:5472157]
:OUTPUT ACCEPT [32635:3750271]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 31222 --tcp-flags FIN,SYN,RST,ACK SYN -m 
conntrack --ctstate NEW -j ACCEPT
-A INPUT -i virbr10 -p udp -m udp -m multiport --dports 53,67 -j ACCEPT
-A INPUT -i virbr10 -p tcp -m tcp -m multiport --dports 53,67 -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p tcp -m tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -d 10.7.33.0/24 -o virbr10 -m conntrack --ctstate 
RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.7.33.0/24 -i virbr10 -j ACCEPT
-A FORWARD -i virbr10 -o virbr10 -j ACCEPT
-A FORWARD -d 10.7.33.100/32 -o virbr10 -p tcp -m tcp --dport 1:31221 
--tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -i virbr10 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -o virbr10 -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Sun Jun 25 22:33:39 2017
# Generated by iptables-save v1.4.21 on Sun Jun 25 22:33:39 2017
*nat
:PREROUTING ACCEPT [265547:18746839]
:INPUT ACCEPT [7946:621443]
:OUTPUT ACCEPT [44:3768]
:POSTROUTING ACCEPT [737574:41994020]
-A PREROUTING -d 1.2.3.4/32 -p tcp -m tcp --dport 1:31221 --tcp-flags 
FIN,SYN,RST,ACK SYN -j DNAT --to-destination 10.7.33.100
-A POSTROUTING -s 10.7.33.0/24 -d 224.0.0.0/24 -j RETURN
-A POSTROUTING -s 10.7.33.0/24 -d 255.255.255.255/32 -j RETURN
-A POSTROUTING -s 10.7.33.0/24 ! -d 10.7.33.0/24 -p tcp -j MASQUERADE 
--to-ports 1024-65535
-A POSTROUTING -s 10.7.33.0/24 ! -d 10.7.33.0/24 -p udp -j MASQUERADE 
--to-ports 1024-65535
-A POSTROUTING -s 10.7.33.0/24 ! -d 10.7.33.0/24 -j MASQUERADE
COMMIT
# Completed on Sun Jun 25 22:33:39 2017
# Generated by iptables-save v1.4.21 on Sun Jun 25 22:33:39 2017
*mangle
:PREROUTING ACCEPT [32568589:28152102128]
:INPUT ACCEPT [65809:5372699]
:FORWARD ACCEPT [32502779:28146729377]
:OUTPUT ACCEPT [56541:5855271]
:POSTROUTING ACCEPT [32535420:28150481592]
-A POSTROUTING -o virbr10 -p udp -m udp --dport 68 -j CHECKSUM 
--checksum-fill
COMMIT
# Completed on Sun Jun 25 22:33:39 2017

Then the router has its own set of iptables rules (I report only a few 
here):

# Generated by iptables-save v1.4.21 on Sun Jun 25 22:41:19 2017
*filter
:INPUT ACCEPT [114664:5730467]
:FORWARD ACCEPT [20388771:18133798388]
:OUTPUT ACCEPT [112664:4594474]
-A INPUT -s 10.7.33.101/32 -p tcp -m tcp --sport 29101 -j LOG
COMMIT
# Completed on Sun Jun 25 22:41:19 2017
# Generated by iptables-save v1.4.21 on Sun Jun 25 22:41:19 2017
*nat
:PREROUTING ACCEPT [108899:5217224]
:INPUT ACCEPT [108899:5217224]
:OUTPUT ACCEPT [2734:162786]
:POSTROUTING ACCEPT [2734:162786]
-A PREROUTING -p tcp -m tcp --dport 29101 -j DNAT --to-destination 
10.7.33.101
-A PREROUTING -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.7.33.101
-A PREROUTING -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.7.33.101
-A PREROUTING -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.7.33.109
-A POSTROUTING -d 10.7.33.101/32 -p tcp -m tcp --dport 29101 -j SNAT 
--to-source 10.7.33.100
-A POSTROUTING -d 10.7.33.101/32 -p tcp -m tcp --dport 80 -j SNAT 
--to-source 10.7.33.100
-A POSTROUTING -d 10.7.33.101/32 -p tcp -m tcp --dport 443 -j SNAT 
--to-source 10.7.33.100
-A POSTROUTING -d 10.7.33.109/32 -p tcp -m tcp --dport 25 -j SNAT 
--to-source 10.7.33.100
COMMIT
# Completed on Sun Jun 25 22:41:19 2017

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.

Is there a way to forward packets from the host to the router and from 
the router to the correct virtual server keeping the original source IP 
address?

[toc] | [next] | [standalone]

#182670

Lucio Crusca wrote:
>[...]
> 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.

That shouldn't be happening -- you may have an errant rule you didn't
show from one of the hosts in there that's doing this to you (perhaps
NAT Hairpin).

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#182742

Il 26/06/2017 11:35, Dan Purgert ha scritto:
> That shouldn't be happening -- you may have an errant rule you didn't
> show

I think I did show that rule:

-A POSTROUTING -d 10.7.33.109/32 -p tcp -m tcp --dport 25 -j SNAT 
--to-source 10.7.33.100

The problem is that without that rule things do not work at all 
(connections time out).

For example, I've tried adding only the DNAT rule for TCP port 26, 
without the SNAT rule above, forwarded to the same mail server.

Then from the client I've tried to open a TCP connection on port 26:

echo hello | netcat 1.2.3.4 26

In the phisycal host system I get:

Jun 27 13:21:09 hostmachine kernel: [2479354.931255] IN=eth0 OUT= 
MAC=74:d0:2b:99:a1:f5:2c:21:31:28:a6:fb:08:00 SRC=217.61.166.36 
DST=1.2.3.4 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=18186 DF PROTO=TCP 
SPT=51600 DPT=26 WINDOW=29200 RES=0x00 SYN URGP=0

In the router virtual machine I get:

Jun 27 13:21:34 router kernel: [2479319.331492] IN=eth0 OUT= 
MAC=52:54:00:02:90:d2:52:54:00:f0:37:ba:08:00 SRC=217.61.166.36 
DST=10.7.33.100 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=18186 DF PROTO=TCP 
SPT=51600 DPT=26 WINDOW=29200 RES=0x00 SYN URGP=0

In the mail server virtual machine I get

Jun 27 13:21:09 mx kernel: [2479308.578043] IN=ens2 OUT= 
MAC=52:54:00:8d:4c:2a:52:54:00:02:90:d2:08:00 SRC=217.61.166.36 
DST=10.7.33.109 LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=18186 DF PROTO=TCP 
SPT=51600 DPT=26 WINDOW=29200 RES=0x00 SYN URGP=0

So the packet actually reaches the mail server as expected. However the 
client never gets a reply.

[toc] | [prev] | [next] | [standalone]

#182761

Le 27/06/2017 à 13:29, Lucio Crusca a écrit :
>
> -A POSTROUTING -d 10.7.33.109/32 -p tcp -m tcp --dport 25 -j SNAT
> --to-source 10.7.33.100
>
> The problem is that without that rule things do not work at all
> (connections time out).

If this rule is required, then your routing setup is wrong.
What is the routing table on the router and the server ?

[toc] | [prev] | [next] | [standalone]

#182813

Il 27/06/2017 23:35, Pascal Hambourg ha scritto:
> Le 27/06/2017 à 13:29, Lucio Crusca a écrit :
>>
>> -A POSTROUTING -d 10.7.33.109/32 -p tcp -m tcp --dport 25 -j SNAT
>> --to-source 10.7.33.100
>>
>
> If this rule is required, then your routing setup is wrong.

Thank you very much, that was the problem. My VMs were using the host 
system as gateway instead of the router VM.

[toc] | [prev] | [next] | [standalone]

#182835

[Multipart message — attachments visible in raw view] — view raw

On 29 Jun 2017 6:32 pm, "Lucio Crusca" <lucio@sulweb.org> wrote:

Il 27/06/2017 23:35, Pascal Hambourg ha scritto:

> Le 27/06/2017 à 13:29, Lucio Crusca a écrit :
>
>>
>> -A POSTROUTING -d 10.7.33.109/32 -p tcp -m tcp --dport 25 -j SNAT
>> --to-source 10.7.33.100
>>
>>
> If this rule is required, then your routing setup is wrong.
>

Thank you very much, that was the problem. My VMs were using the host
system as gateway instead of the router VM.


Ok, not sure though how does that change anything. As you said the email vm
was receiving traffic with the ip of the router vm as source and since they
are both on the same lan and connected to the same bridge I dont see how
the default gateway can make any difference? The return traffic was already
going through the router vm hence the need of the SNAT rule on it.

[toc] | [prev] | [next] | [standalone]

#182841

Le 30/06/2017 à 00:38, Igor Cicimov a écrit :
> On 29 Jun 2017 6:32 pm, "Lucio Crusca" <lucio@sulweb.org> wrote:
>>
>> Il 27/06/2017 23:35, Pascal Hambourg ha scritto:
>>
>>> Le 27/06/2017 à 13:29, Lucio Crusca a écrit :
>>>
>>>> -A POSTROUTING -d 10.7.33.109/32 -p tcp -m tcp --dport 25 -j SNAT
>>>> --to-source 10.7.33.100
>>>>
>>> If this rule is required, then your routing setup is wrong.
>>
>> Thank you very much, that was the problem. My VMs were using the host
>> system as gateway instead of the router VM.
>
> Ok, not sure though how does that change anything. As you said the email vm
> was receiving traffic with the ip of the router vm as source and since they
> are both on the same lan and connected to the same bridge I dont see how
> the default gateway can make any difference? The return traffic was already
> going through the router vm hence the need of the SNAT rule on it.

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.
The SNAT rule is a way to force reply traffic through the router VM, 
making the routing symmetric :
client -> router VM (DNAT+SNAT) -> server VM
server VM -> router VM (un-DNAT+un-SNAT) -> client

Making the router VM the default gateway for the server VM also makes 
routing symmetric without the need of SNAT :
client -> router VM (DNAT) -> server VM
server VM -> router VM (un-DNAT) -> client

[toc] | [prev] | [next] | [standalone]

#182855

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jun 30, 2017 at 3:50 PM, Pascal Hambourg <pascal@plouf.fr.eu.org>
wrote:

> Le 30/06/2017 à 00:38, Igor Cicimov a écrit :
>
>> On 29 Jun 2017 6:32 pm, "Lucio Crusca" <lucio@sulweb.org> wrote:
>>
>>>
>>> Il 27/06/2017 23:35, Pascal Hambourg ha scritto:
>>>
>>> Le 27/06/2017 à 13:29, Lucio Crusca a écrit :
>>>>
>>>> -A POSTROUTING -d 10.7.33.109/32 -p tcp -m tcp --dport 25 -j SNAT
>>>>> --to-source 10.7.33.100
>>>>>
>>>>> If this rule is required, then your routing setup is wrong.
>>>>
>>>
>>> Thank you very much, that was the problem. My VMs were using the host
>>> system as gateway instead of the router VM.
>>>
>>
>> Ok, not sure though how does that change anything. As you said the email
>> vm
>> was receiving traffic with the ip of the router vm as source and since
>> they
>> are both on the same lan and connected to the same bridge I dont see how
>> the default gateway can make any difference? The return traffic was
>> already
>> going through the router vm hence the need of the SNAT rule on it.
>>
>
> 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. As if there was
maybe a routing rule on the host like:

10.7.33.0/24 dev virbr10 scope host src 10.7.33.100

Something does not add up ...

The SNAT rule is a way to force reply traffic through the router VM, making
> the routing symmetric :
> client -> router VM (DNAT+SNAT) -> server VM
> server VM -> router VM (un-DNAT+un-SNAT) -> client
>
> Making the router VM the default gateway for the server VM also makes
> routing symmetric without the need of SNAT :
> client -> router VM (DNAT) -> server VM
> server VM -> router VM (un-DNAT) -> client
>
>

[toc] | [prev] | [next] | [standalone]

#182884

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.

[toc] | [prev] | [next] | [standalone]

#182891

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#182892

Le 01/07/2017 à 03:25, Igor Cicimov a écrit :
>
> You know what, i just checked the iptables rules the op sent again and
> realized this:
>
> -A POSTROUTING -d 10.7.33.109/32 <http://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 <http://10.7.33.109/32> -p tcp -m tcp -
> -j SNAT --to-source 10.7.33.100

These two rules do not have the same purpose at all.

The OP's rule applies to incoming SMTP connections forwarded to the 
server, in order to workaround the routing flaw (wrong gateway).

Your rule applies to outgoing connexions from the server, so 1) is 
useless for incoming connections and 2) would be ignored in the original 
setup because the server did not use the router as its default gateway.

PS. Igor, the plain text version of your posts does not properly mark 
the quoted text from the message you reply to : it appears as if it was 
your text, without any quotation marks.

[toc] | [prev] | [next] | [standalone]

#182895

[Multipart message — attachments visible in raw view] — view raw

On Sat, 1 Jul 2017 11:30:41 +0200
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

Hello Pascal,

>PS. Igor, the plain text version of your posts does not properly mark 
>the quoted text from the message you reply to : it appears as if it was 
>your text, without any quotation marks.

It's fine here.

-- 
 Regards  _
         / )           "The blindingly obvious is
        / _)rad        never immediately apparent"
Loaded like a freight train flyin' like an aeroplane
Nightrain - Guns 'N' Roses

[toc] | [prev] | [next] | [standalone]

#182897

Le 01/07/2017 à 12:54, Brad Rogers a écrit :
> On Sat, 1 Jul 2017 11:30:41 +0200
> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>
> Hello Pascal,
>
>> PS. Igor, the plain text version of your posts does not properly mark
>> the quoted text from the message you reply to : it appears as if it was
>> your text, without any quotation marks.
>
> It's fine here.

Are you sure that your mailer displays the plain text version, not the 
HTML version ?
The HTML version is fine but in the plain text version, the only 
quotation marks ">" are the ones that were already present in the quoted 
message.

[toc] | [prev] | [next] | [standalone]

#182898

[Multipart message — attachments visible in raw view] — view raw

On Sat, 1 Jul 2017 13:25:30 +0200
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

Hello Pascal,

>Are you sure that your mailer displays the plain text version, not the 
>HTML version ?

Positive.  I use Claws Mail *without* any HTML plugin.

-- 
 Regards  _
         / )           "The blindingly obvious is
        / _)rad        never immediately apparent"
He signed up for just three years, it seemed a small amount
Tin Soldiers - Stiff Little Fingers

[toc] | [prev] | [next] | [standalone]

#182899

[Multipart message — attachments visible in raw view] — view raw

On Sat, 1 Jul 2017 13:25:30 +0200
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

Hello Pascal,

>Are you sure that your mailer displays the plain text version, not the 
>HTML version ?

I'll change my answer;  I only looked at a couple of Igor's messages and
they were fine.  However, further study shows that in some posts, quoted
text isn't quoted.

-- 
 Regards  _
         / )           "The blindingly obvious is
        / _)rad        never immediately apparent"
Walking through town is quite scary
I Predict A Riot - Kaiser Chiefs

[toc] | [prev] | [next] | [standalone]

#182912

[Multipart message — attachments visible in raw view] — view raw

On 1 Jul 2017 7:31 pm, "Pascal Hambourg" <pascal@plouf.fr.eu.org> wrote:

Le 01/07/2017 à 03:25, Igor Cicimov a écrit :

>
> You know what, i just checked the iptables rules the op sent again and
> realized this:
>
> -A POSTROUTING -d 10.7.33.109/32 <http://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 <http://10.7.33.109/32> -p tcp -m tcp -
> -j SNAT --to-source 10.7.33.100
>

These two rules do not have the same purpose at all.

The OP's rule applies to incoming SMTP connections forwarded to the server,
in order to workaround the routing flaw (wrong gateway).

Your rule applies to outgoing connexions from the server,

so 1) is useless for incoming connections


That's my point, i misread his rule and thought it was the one I posted.

and 2) would be ignored in the original setup because the server did not
use the router as its default gateway.


Yep, but not if the source ip was being changed to the one of the router in
which case the reply would not go to the dgw.


PS. Igor, the plain text version of your posts does not properly mark the
quoted text from the message you reply to : it appears as if it was your
text, without any quotation marks.

[toc] | [prev] | [next] | [standalone]

#182805

[Multipart message — attachments visible in raw view] — view raw

On 27 Jun 2017 9:29 pm, "Lucio Crusca" <lucio@sulweb.org> wrote:

Il 26/06/2017 11:35, Dan Purgert ha scritto:

> That shouldn't be happening -- you may have an errant rule you didn't
> show
>

I think I did show that rule:


-A POSTROUTING -d 10.7.33.109/32 -p tcp -m tcp --dport 25 -j SNAT
--to-source 10.7.33.100


Yes you do need that rule, in case when not using MASQUERADE you have to
use SNAT or you'll get timeouts as you found out.

Your problem is that something changes the source ip of the packets sent
from the router vm to the mail server one NOT the other way around. The
only candidate i can see in your config, assuming you have shown us the
full configs, are these rules:

-A POSTROUTING -s 10.7.33.0/24 ! -d 10.7.33.0/24 -p tcp -j MASQUERADE
--to-ports 1024-65535
-A POSTROUTING -s 10.7.33.0/24 ! -d 10.7.33.0/24 -p udp -j MASQUERADE
--to-ports 1024-65535
-A POSTROUTING -s 10.7.33.0/24 ! -d 10.7.33.0/24 -j MASQUERADE

but they look ok to me to be honest, they change the source ip of the
packets but only if the destination is not 10.7.33.0/24 subnet which should
not cause the issue you are seeing.


The problem is that without that rule things do not work at all
(connections time out).

For example, I've tried adding only the DNAT rule for TCP port 26, without
the SNAT rule above, forwarded to the same mail server.

Then from the client I've tried to open a TCP connection on port 26:

echo hello | netcat 1.2.3.4 26

In the phisycal host system I get:

Jun 27 13:21:09 hostmachine kernel: [2479354.931255] IN=eth0 OUT=
MAC=74:d0:2b:99:a1:f5:2c:21:31:28:a6:fb:08:00 SRC=217.61.166.36 DST=1.2.3.4
LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=18186 DF PROTO=TCP SPT=51600 DPT=26
WINDOW=29200 RES=0x00 SYN URGP=0

In the router virtual machine I get:

Jun 27 13:21:34 router kernel: [2479319.331492] IN=eth0 OUT=
MAC=52:54:00:02:90:d2:52:54:00:f0:37:ba:08:00 SRC=217.61.166.36
DST=10.7.33.100 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=18186 DF PROTO=TCP
SPT=51600 DPT=26 WINDOW=29200 RES=0x00 SYN URGP=0

In the mail server virtual machine I get

Jun 27 13:21:09 mx kernel: [2479308.578043] IN=ens2 OUT=
MAC=52:54:00:8d:4c:2a:52:54:00:02:90:d2:08:00 SRC=217.61.166.36
DST=10.7.33.109 LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=18186 DF PROTO=TCP
SPT=51600 DPT=26 WINDOW=29200 RES=0x00 SYN URGP=0

So the packet actually reaches the mail server as expected. However the
client never gets a reply.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web