> 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@xxxxxxxxxxxxxxx [mailto:netfilter- > owner@xxxxxxxxxxxxxxx] On Behalf Of Pascal Hambourg > Sent: Friday, December 17, 2010 4:15 PM > To: Alec Matusis > Cc: netfilter@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
