Packets ending up in wrong chain after DNAT

Packets ending up in wrong chain after DNAT

[Dion Kant]

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.

Re: Packets ending up in wrong chain after DNAT

[Mart Frauenlob]

On 02.03.2010 02:50, netfilter-owner@vger.kernel.org wrote:
> 
> 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

Re: Packets ending up in wrong chain after DNAT

[Richard Horton]

On 2 March 2010 01:29, Dion Kant <msn@concero.nl> wrote:

> 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

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

Re: Packets ending up in wrong chain after DNAT

[Dion Kant]

Richard Horton wrote:
> On 2 March 2010 01:29, Dion Kant <msn@concero.nl> wrote:
>
>   
>> 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
>>     
>
> As I understand what you are trying to do is allow access to port 25
> on your internal network from an external machine right?
>   
Yes correct.
> 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).
>   
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.