On Tuesday 11 March 2003 06:44 am, Craig Packard wrote: > > Sounds like a SNAT rule that isn't tied down to just the external > > interface. Including packet traces and sniffs is potentially > > useful, but more useful would be any SNAT and DNAT rules themselves. > > I've already posted my PREROUTING chain to the list. And in the same I've not been able to find it. I found a request for it on Friday from Ralf Spenneberg but if you posted it to the list I didn't receive that post. (not hard to believe - I seem to get a good percentage of this list several days late - not just messages awaiting moderator approval) > message you replied to was several packet captures further down the > message. There is no SNATing anywhere--on any interface. I would be > thankful for any help or info on more places to look to troubleshoot. Sorry, I was aware of the captures in that message, but snipped them from my reply for brevity. My suggestion for further troubleshooting at this point would be to set up a few LOG rules temporarily to try to track the progress of the packets through netfilter. iptables -t nat -I PREROUTING 1 -p udp -s 192.168.25.11 -j LOG --log-prefix "NatPreS:" iptables -I FORWARD 1 -p udp -s 192.168.25.11 -j LOG --log-prefix "FwdS:" iptables -t nat -I POSTROUTING 1 -p udp -d 192.168.25.11 -j LOG --log-prefix NatPostD:" etc. If you have loaded (or can load) mangle table, put the log rules in mangle PREROUTING and POSTROUTING instead of nat. Log both directions, matching the specific source/dest port if possible, else matching source/dest IP of both the local and remote boxes. Make a few connection attempts (then remove the log rules) and then examine the log entries to see what IPs appear where. This may help narrow down what packets are being modified at which stage. By examining packet IDs, src/dest IPs, and the log-prefix to identify which chain logged the entry, you should get a fairly good picture of what is taking place within netfilter regarding these connections. > - Craig j
