RE: PREROUTING DNAT *inconsistent* behavior

["Alec Matusis" <matusis@matusis.com>]

> Do you mean that REDIRECT did not alter the destination address when it
> was different from the primary address on eth0 ?

I cannot confirm or deny this, since currently all our production servers
run with:
-A PREROUTING -d server.ip -p tcp --dport 443 -j DNAT --to-destination
server.ip:5228
The REDIRECT rule is something we tried in the past, to see if these strange
packets from port 5228 would go away.

> As I suggested, DROP packets in the INVALID state. If you don't see
> them
> any more, you'll know.

I added the following logging rules:
-I OUTPUT 1 -p tcp --sport 5228 -m state --state INVALID -j LOG
and
-I INPUT 1 -p tcp -m state --state INVALID -j LOG

It turns out, that every strange packet that we see in tcpdump, that goes
out from port 5228, e.g.
17:34:05.147063 IP server.ip.5228 > client.ip.35263: F 65950323:65950323(0)
ack 4249584466 win 5840
is in the INVALID state as you suggested, since that client IP is found in
the INVALID state output log, and has the same timestamp:
#grep client.ip /var/log/messages
Dec 17 17:32:22 serv6 kernel: [9021890.300104] IN= OUT=eth0 SRC=server.ip
DST=client.ip LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=13916 DF PROTO=TCP
SPT=5228 DPT=35263 WINDOW=5840 RES=0x00 ACK FIN URGP=0 
Dec 17 17:32:30 serv6 kernel: [9021898.213417] IN= OUT=eth0 SRC=server.ip
DST=client.ip LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=45133 DF PROTO=TCP
SPT=5228 DPT=35312 WINDOW=5840 RES=0x00 ACK FIN URGP=0 
Dec 17 17:33:41 serv6 kernel: [9021968.570562] IN= OUT=eth0 SRC=server.ip
DST=client.ip LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=45134 DF PROTO=TCP
SPT=5228 DPT=35312 WINDOW=5840 RES=0x00 ACK FIN URGP=0 
Dec 17 17:34:05 serv6 kernel: [9021992.637769] IN= OUT=eth0 SRC=server.ip
DST=client.ip LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=13917 DF PROTO=TCP
SPT=5228 DPT=35263 WINDOW=5840 RES=0x00 ACK FIN URGP=0

What is strange however, is that even though I am also logging all incoming
packets in the INVALID state, there are no such packets with this client.ip.
This suggests that the server responds to a *normal* packet from this
client.ip with a packet in the INVALID state? Is there any way to track down
the reason why these INVALID state packets are generated in the server?


> -----Original Message-----
> From: netfilter-owner@vger.kernel.org [mailto:netfilter-
> owner@vger.kernel.org] On Behalf Of Pascal Hambourg
> Sent: Friday, December 17, 2010 4:15 PM
> To: Alec Matusis
> Cc: netfilter@vger.kernel.org
> Subject: Re: PREROUTING DNAT *inconsistent* behavior
> 
> Alec Matusis a écrit :
> >> I would have used DNAT instead to make sure
> >> the destination address is not changed.
> >
> > Instead of REDIRECT, we used:
> > -A PREROUTING -d server.ip -p tcp --dport 443 -j DNAT --to-
> destination
> > server.ip:5228
> > The result is exactly the same.
> 
> Do you mean that REDIRECT did not alter the destination address when it
> was different from the primary address on eth0 ?
> 
> >> What are the other 5% then ?
> >
> > They are mostly RST packets from various clients:
> 
> Sure, RSTs are sent in reply to the bogus packets from the servers.
> 
> >> They are probably packets classified in the INVALID state by the
> >> connection tracking, which are ignored by the nat table. In a NAT
> >> setup,
> >> INVALID packets should be dropped because of this. Now the real
> >> question
> >> is : why are they classified in the INVALID state ?
> >
> > How can I verify that  these packets have been classified as in the
> INVALID
> > state? That may be the key to this problem.
> 
> As I suggested, DROP packets in the INVALID state. If you don't see
> them
> any more, you'll know.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html