Packets ending up in wrong chain after DNAT

I have a DNAT to an address behind the box, like this

Chain PREROUTING (policy ACCEPT 743K packets, 49M bytes)
pkts bytes target prot opt in out source
destination
1572 94320 DNAT tcp -- eth2 * 1.1.1.1
0.0.0.0/0 tcp dpt:25 to:172.20.8.217

I expect to see all packets from source 1.1.1.1 to tcp/25 ending up exclusively in the FORWARD chain. However a fraction of these packets end up in both FORWARD and INPUT chains.

The following log lines show the problem:

Mar  2 02:03:50 erouter kernel: [527920.547039] LOG 25 Correct  IN=eth2
OUT=eth0 SRC=1.1.1.1 DST=172.20.8.217 LEN=60 TOS=0x00 PREC=0x00 TTL=48
ID=6919 DF PROTO=TCP SPT=53800 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0
Mar  2 02:03:55 erouter kernel: [527925.562582] LOG 25 Correct  IN=eth2
OUT=eth0 SRC=1.1.1.1 DST=172.20.8.217 LEN=60 TOS=0x00 PREC=0x00 TTL=48
ID=26610 DF PROTO=TCP SPT=53803 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0
Mar  2 02:03:55 erouter kernel: [527925.765439] LOG 25 Wrong  IN=eth2

OUT= MAC=00:16:3e:78:4a:72:00:1d:45:8a:1b:2e:08:00 SRC=1.1.1.1 DST=2.2.2.2 LEN=40 TOS=0x00 PREC=0x00 TTL=49 ID=0 DF PROTO=TCP SPT=53803 DPT=25 WINDOW=0 RES=0x00 RST URGP=0

The first entry is fine. The next two lines show the problem. The second line comes from the FORWARD chain and a fraction later in time, another entry is logged in the INPUT chain. Note the different LEN and other values in the last log line.

I used the following to create the log lines (addresses are fake)

IPTABLES=/usr/sbin/iptables
xs1=eth2
lan=eth0

$IPTABLES -t nat -A PREROUTING -i $xs1 -p tcp -s 1.1.1.1 --dport 25 -j DNAT --to-destination 172.20.8.217

$IPTABLES -N inet-fw
$IPTABLES -A INPUT -i $xs1 -j inet-fw
$IPTABLES -A inet-fw -p tcp --dport 25 -j LOG --log-prefix 'LOG 25 Wrong '

$IPTABLES -N inet-lan
$IPTABLES -A FORWARD -i $xs1 -o $lan -j inet-lan $IPTABLES -A inet-lan -p tcp --dport 25 -j LOG --log-prefix 'LOG 25 Correct '

I see this problem running openSUSE 11.2 with there kernel

Linux erouter 2.6.31.12-0.1-xen #1 SMP 2010-01-27 08:20:11 +0100 i686 i686 i386 GNU/Linux

running on a Xen domU. I cannot remember I have seen this behaviour before. Does someone have a clue?

Dion.

Do you encounter connection problems/drops?
It could be those 'wrong' packets are classified by conntrack into state 'INVALID'.
Try to LOG, DROP or LOG/DROP with -m state --state INVALID in INPUT and FORWARD chain.
Netfilter NAT predicts the traffic being valid for the conntrack engine.

Hope it helps

Mart

As I understand what you are trying to do is allow access to port 25 on your internal network from an external machine right?

If so that log looks odd - the originator of the connection is sending a RESET flag. The Reset flag is sent by the destination (atleast from my knowledge they are).

In which case that line is going to be classed as invalid state and so won't work with conntrack as Matt points out.

From RFC793 (TCP):-
If the connection does not exist (CLOSED) then a reset is sent in response to any incoming segment except another reset. In particular, SYNs addressed to a non-existent connection are rejected by this means.

If the connection is in any non-synchronized state (LISTEN, SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges something not yet sent (the segment carries an unacceptable ACK), or if an incoming segment has a security level or compartment which does not exactly match the level and compartment requested for the connection, a reset is sent.

If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state.

Richard Horton
Users are like a virus: Each causing a thousand tiny crises until the
host finally dies.
http://www.solstans.co.uk - Solstans Japanese Bobtails and Norwegian Forest Cats
http://www.pbase.com/arimus - My online photogallery

Yes correct.

This does ring a bell to me. I think it is caused by a Postfix "feature". The mail server is a Postfix MTA. If I understand you correctly Postfix opens a connection, "conntracked" correctly as can be seen by the log in the FORWARD chain. Then a bit later, Postfix sends a packet with RST set. This is an error, classified invalid and therefore it ends up in the INPUT chain.

Thanks for explaining this.

Dion.