Re: Source NAT in POSTROUTING chain for locally generated packets

[Michael Schwartzkopff <ms@sys4.de>]

[-- 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 --]