Wow, more than a week later and silence from everyone - am I on my own with this problem? Why would NATing in both PREROUTING and POSTROUTING work **only** when I watch it with tcpdump and not work otherwise? Surely I can't be the only one seeing this problem? - Greg Scott -----Original Message----- From: netfilter-owner@xxxxxxxxxxxxxxx [mailto:netfilter-owner@xxxxxxxxxxxxxxx] On Behalf Of Greg Scott Sent: Tuesday, June 14, 2011 9:04 PM To: netfilter@xxxxxxxxxxxxxxx Cc: Lynn Hanson; Joe Whalen Subject: Bizarre NAT behavior I ran into a bizarre NAT problem recently. I have a firewall with eth0 and eth1 bridged using device br0. This site hosts a few publicly visible web and ftp sites. These are all accessible across the Internet as they should be. For internal users accessing these sites using public IP Addresses, I MASQUERADE the request and also DNAT it. This has worked for several years - but broke recently when I put in a firewall upgrade using kernel 2.6.35.6-48.fc14.i686.PAE. Identical ruleset from the old and new, just a newer kernel with Fedora 14. Here's the really weird part - it all works when I watch it with tcpdump. The website has a public IP Address (obfuscated here) of 1.2.115.121. This NATs to private IP Address 192.168.10.8. When a user in the 192.168.10.nnn subnet tries to access the website at its public IP Address, nothing happens. But when I do this: [root@ehac-fw2011 ~]# /usr/sbin/tcpdump -i br0 host 1.2.115.151 -nn Now that user can see the website. This works for a few minutes after I terminate tcpdump until the TCP connection goes away. I can reproduce the problem at will - am I looking a kernel bug? How weird is that when the problem stops when I watch the packets. Some kind of timing glitch? Thanks - Greg Scott -- 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