Alec Matusis a écrit : >> 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. Ok. Note that you can skip the server address and use a single rule for all the server addresses : -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination :5228 > 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 [...] > 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? Maybe these packets belong to closed or lost TCP connections. You can see that most of them have the FIN flag set. So the reason could be that conntrack has forgotten about these connections. -- 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
