Source NAT in POSTROUTING chain for locally generated packets

Source NAT in POSTROUTING chain for locally generated packets

[Michael Schwartzkopff]

[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

Hi,

For some special reasons I want to alter the IP address of outgoing packets 
that are generated locally to a secondary IP address on my machine. For a test 
I use the udp/echo service. Without any rules a tcpdump looks like this:

192.168.56.101 is the primary address of the echo server and 192.168.56.16 is 
the secondary address of the interface.

08:24:04.063987 IP 192.168.56.1.48462 > 192.168.56.16.echo: UDP, length 6
08:24:04.064522 IP 192.168.56.101.echo > 192.168.56.1.48462: UDP, length 6

So I add the iptables rule:

iptables -t nat -I POSTROUTING -p udp -s 192.168.56.101 --sport 7 \
  -j SNAT --to-source 192.168.56.16

now tcpdump shows that no answer packet is sent out any more:

08:24:16.851095 IP 192.168.56.1.55362 > 192.168.56.16.echo: UDP, length 6


With iptables -t nat -L POSTROUTING I can see that the rule is hit since the 
counter increases. Also a iptables TRACE shows me that the rule is hit. No 
filter appears in the TRACE log.

Any ideas where the packet vanished?


Mit freundlichen Grüßen,

Michael Schwartzkopff

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64, +49 (162) 165 0044
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: Source NAT in POSTROUTING chain for locally generated packets

[Pascal Hambourg]

Hello,

Michael Schwartzkopff a écrit :
> 
> For some special reasons I want to alter the IP address of outgoing packets 
> that are generated locally to a secondary IP address on my machine. For a test 
> I use the udp/echo service. Without any rules a tcpdump looks like this:
> 
> 192.168.56.101 is the primary address of the echo server and 192.168.56.16 is 
> the secondary address of the interface.
> 
> 08:24:04.063987 IP 192.168.56.1.48462 > 192.168.56.16.echo: UDP, length 6
> 08:24:04.064522 IP 192.168.56.101.echo > 192.168.56.1.48462: UDP, length 6
> 
> So I add the iptables rule:
> 
> iptables -t nat -I POSTROUTING -p udp -s 192.168.56.101 --sport 7 \
>   -j SNAT --to-source 192.168.56.16
> 
> now tcpdump shows that no answer packet is sent out any more:
> 
> 08:24:16.851095 IP 192.168.56.1.55362 > 192.168.56.16.echo: UDP, length 6
> 
> 
> With iptables -t nat -L POSTROUTING I can see that the rule is hit since the 
> counter increases. Also a iptables TRACE shows me that the rule is hit. No 
> filter appears in the TRACE log.
> 
> Any ideas where the packet vanished?

Clash with an existing connection entry (the one created by the incoming
packet) -> source port changed or packet dropped.
What was the full tcpdump command used ? Any filters ?

Re: Source NAT in POSTROUTING chain for locally generated packets

[Michael Schwartzkopff]

[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

Am Freitag, 29. August 2014, 00:08:38 schrieb Pascal Hambourg:
> Hello,
> 
> Michael Schwartzkopff a écrit :
> > For some special reasons I want to alter the IP address of outgoing
> > packets
> > that are generated locally to a secondary IP address on my machine. For a
> > test I use the udp/echo service. Without any rules a tcpdump looks like
> > this:
> > 
> > 192.168.56.101 is the primary address of the echo server and 192.168.56.16
> > is the secondary address of the interface.
> > 
> > 08:24:04.063987 IP 192.168.56.1.48462 > 192.168.56.16.echo: UDP, length 6
> > 08:24:04.064522 IP 192.168.56.101.echo > 192.168.56.1.48462: UDP, length 6
> > 
> > So I add the iptables rule:
> > 
> > iptables -t nat -I POSTROUTING -p udp -s 192.168.56.101 --sport 7 \
> > 
> >   -j SNAT --to-source 192.168.56.16
> > 
> > now tcpdump shows that no answer packet is sent out any more:
> > 
> > 08:24:16.851095 IP 192.168.56.1.55362 > 192.168.56.16.echo: UDP, length 6
> > 
> > 
> > With iptables -t nat -L POSTROUTING I can see that the rule is hit since
> > the counter increases. Also a iptables TRACE shows me that the rule is
> > hit. No filter appears in the TRACE log.
> > 
> > Any ideas where the packet vanished?
> 
> Clash with an existing connection entry (the one created by the incoming
> packet) -> source port changed or packet dropped.

Since I so not filter on existing state, the packet should not be dropped 
anyway.


> What was the full tcpdump command used ?

Yes. tcpdump should have captured the package.


> Any filters ?

No filters at all.

Mit freundlichen Grüßen,

Michael Schwartzkopff

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64, +49 (162) 165 0044
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: Source NAT in POSTROUTING chain for locally generated packets

[Michael Schwartzkopff]

[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]

Am Freitag, 29. August 2014, 00:08:38 schrieb Pascal Hambourg:
> Hello,
> 
> Michael Schwartzkopff a écrit :
> > For some special reasons I want to alter the IP address of outgoing
> > packets
> > that are generated locally to a secondary IP address on my machine. For a
> > test I use the udp/echo service. Without any rules a tcpdump looks like
> > this:
> > 
> > 192.168.56.101 is the primary address of the echo server and 192.168.56.16
> > is the secondary address of the interface.
> > 
> > 08:24:04.063987 IP 192.168.56.1.48462 > 192.168.56.16.echo: UDP, length 6
> > 08:24:04.064522 IP 192.168.56.101.echo > 192.168.56.1.48462: UDP, length 6
> > 
> > So I add the iptables rule:
> > 
> > iptables -t nat -I POSTROUTING -p udp -s 192.168.56.101 --sport 7 \
> > 
> >   -j SNAT --to-source 192.168.56.16
> > 
> > now tcpdump shows that no answer packet is sent out any more:
> > 
> > 08:24:16.851095 IP 192.168.56.1.55362 > 192.168.56.16.echo: UDP, length 6
> > 
> > 
> > With iptables -t nat -L POSTROUTING I can see that the rule is hit since
> > the counter increases. Also a iptables TRACE shows me that the rule is
> > hit. No filter appears in the TRACE log.
> > 
> > Any ideas where the packet vanished?
> 
> Clash with an existing connection entry (the one created by the incoming
> packet) -> source port changed or packet dropped.

SNAT indeed alters the source port that is why the client does not recognizes 
the packet now. But I did not find any way not to alter the source port.

Mit freundlichen Grüßen,

Michael Schwartzkopff

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64, +49 (162) 165 0044
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 230 bytes --]

Re: Source NAT in POSTROUTING chain for locally generated packets

[Pascal Hambourg]

Michael Schwartzkopff a écrit :
> Am Freitag, 29. August 2014, 00:08:38 schrieb Pascal Hambourg:
>>
>> Michael Schwartzkopff a écrit :
>>> For some special reasons I want to alter the IP address of outgoing
>>> packets
>>> that are generated locally to a secondary IP address on my machine. For a
>>> test I use the udp/echo service. Without any rules a tcpdump looks like
>>> this:
>>>
>>> 192.168.56.101 is the primary address of the echo server and 192.168.56.16
>>> is the secondary address of the interface.
>>>
>>> 08:24:04.063987 IP 192.168.56.1.48462 > 192.168.56.16.echo: UDP, length 6
>>> 08:24:04.064522 IP 192.168.56.101.echo > 192.168.56.1.48462: UDP, length 6
>>>
>>> So I add the iptables rule:
>>>
>>> iptables -t nat -I POSTROUTING -p udp -s 192.168.56.101 --sport 7 \
>>>
>>>   -j SNAT --to-source 192.168.56.16
>>>
>>> now tcpdump shows that no answer packet is sent out any more:
>>>
>>> 08:24:16.851095 IP 192.168.56.1.55362 > 192.168.56.16.echo: UDP, length 6
>>>
>>> With iptables -t nat -L POSTROUTING I can see that the rule is hit since
>>> the counter increases. Also a iptables TRACE shows me that the rule is
>>> hit. No filter appears in the TRACE log.
>>>
>>> Any ideas where the packet vanished?
>>
>> Clash with an existing connection entry (the one created by the incoming
>> packet) -> source port changed or packet dropped.
> 
> SNAT indeed alters the source port that is why the client does not recognizes 
> the packet now. But I did not find any way not to alter the source port.

The situation is unclear. In your previous reply, you wrote :
> 
> Since I so not filter on existing state, the packet should not be dropped 
> anyway.

The NAT table can drop the packet by itself when the clash with an
existing connection cannot be avoided (usually by changing the source
port automatically). Here, the existing connection is the one created by
the incoming packet. However, the SNAT rule does not force the source
port, this should not happen.

>> What was the full tcpdump command used ?
> 
> Yes. tcpdump should have captured the package.
> 
>> Any filters ?
> 
> No filters at all.

If you did not set any filters in tcpdump, it should indeed have
captured the outgoing packet. What have you changed ?

What is your real goal ?
My guess is that you want to SNAT the outgoing packet so that it looks
like the expected reply for the client. IMO this is the wrong way of
doing things. Instead you should consider using DNAT (or maybe REDIRECT)
on the original request packet to redirect it to the  primary address of
the server, 192.168.56.101, so that the reply packet from that same
address is considered as part of the same connection and is
automatically de-NATed with the original address.

A better fix would be that the server sends the reply from the same
address as the one it received the request on. If the echo service is
part of inetd, that can be done in inetd.conf by specifying the local
address to use.

192.168.56.16:echo     dgram   udp     wait    root    internal

Re: Source NAT in POSTROUTING chain for locally generated packets

[Michael Schwartzkopff]

[-- Attachment #1: Type: text/plain, Size: 3836 bytes --]

Am Sonntag, 31. August 2014, 17:33:11 schrieben Sie:
> Michael Schwartzkopff a écrit :
> > Am Freitag, 29. August 2014, 00:08:38 schrieb Pascal Hambourg:
> >> Michael Schwartzkopff a écrit :
> >>> For some special reasons I want to alter the IP address of outgoing
> >>> packets
> >>> that are generated locally to a secondary IP address on my machine. For
> >>> a
> >>> test I use the udp/echo service. Without any rules a tcpdump looks like
> >>> this:
> >>> 
> >>> 192.168.56.101 is the primary address of the echo server and
> >>> 192.168.56.16
> >>> is the secondary address of the interface.
> >>> 
> >>> 08:24:04.063987 IP 192.168.56.1.48462 > 192.168.56.16.echo: UDP, length
> >>> 6
> >>> 08:24:04.064522 IP 192.168.56.101.echo > 192.168.56.1.48462: UDP, length
> >>> 6
> >>> 
> >>> So I add the iptables rule:
> >>> 
> >>> iptables -t nat -I POSTROUTING -p udp -s 192.168.56.101 --sport 7 \
> >>> 
> >>>   -j SNAT --to-source 192.168.56.16
> >>> 
> >>> now tcpdump shows that no answer packet is sent out any more:
> >>> 
> >>> 08:24:16.851095 IP 192.168.56.1.55362 > 192.168.56.16.echo: UDP, length
> >>> 6
> >>> 
> >>> With iptables -t nat -L POSTROUTING I can see that the rule is hit since
> >>> the counter increases. Also a iptables TRACE shows me that the rule is
> >>> hit. No filter appears in the TRACE log.
> >>> 
> >>> Any ideas where the packet vanished?
> >> 
> >> Clash with an existing connection entry (the one created by the incoming
> >> packet) -> source port changed or packet dropped.
> > 
> > SNAT indeed alters the source port that is why the client does not
> > recognizes the packet now. But I did not find any way not to alter the
> > source port.
> The situation is unclear. In your previous reply, you wrote :
> > Since I so not filter on existing state, the packet should not be dropped
> > anyway.
> 
> The NAT table can drop the packet by itself when the clash with an
> existing connection cannot be avoided (usually by changing the source
> port automatically). Here, the existing connection is the one created by
> the incoming packet. However, the SNAT rule does not force the source
> port, this should not happen.
> 
> >> What was the full tcpdump command used ?
> > 
> > Yes. tcpdump should have captured the package.
> > 
> >> Any filters ?
> > 
> > No filters at all.
> 
> If you did not set any filters in tcpdump, it should indeed have
> captured the outgoing packet. What have you changed ?
> 
> What is your real goal ?
> My guess is that you want to SNAT the outgoing packet so that it looks
> like the expected reply for the client. IMO this is the wrong way of
> doing things. Instead you should consider using DNAT (or maybe REDIRECT)
> on the original request packet to redirect it to the  primary address of
> the server, 192.168.56.101, so that the reply packet from that same
> address is considered as part of the same connection and is
> automatically de-NATed with the original address.

Yeah. DNAT works. Thanks.

> A better fix would be that the server sends the reply from the same
> address as the one it received the request on. If the echo service is
> part of inetd, that can be done in inetd.conf by specifying the local
> address to use.
> 
> 192.168.56.16:echo     dgram   udp     wait    root    internal

echo only was an example. The real service does not offer that possibilility 
to bind to a single IP address. That also was max first idea.

Mit freundlichen Grüßen,

Michael Schwartzkopff

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64, +49 (162) 165 0044
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 230 bytes --]