On Monday 24 June 2002 11:46 pm, George Garvey wrote: > On Mon, Jun 24, 2002 at 09:42:35PM +0100, Antony Stone wrote: > > > Any chance you can put another machine running ethereal or similar on the > > eth1 interface and see what's really coming out of the box ? > > Yes. It will take me a bit of time, but I'll do it. > > > > I was really, really, wrong, fortunately. The outgoing NAT is > working. I tried, on a computer connected by LAN, "telnet 152.2.210.81 > ftp". It hung. I did "cat /proc/net/ip_conntrack|grep 152.2.21.18": > > tcp 6 55 SYN_RECV src=192.168.2.3 dst=152.2.210.81 sport=32807 > dport=21 src=152.2.210.81 dst=66.123.115.210 sport=21 dport=32807 use=1 > > So, I guess it is the input chain that's giving me the problems. Does > that seem right?
No, and this comment makes me wonder if you've made a common mistake in changing from ipchains to iptables ? In ipchains, packets going from one side of the firewall to the other had to go through the input, forward and output chains; packets going into the firewall just went through the input chain. However, in iptables, the input chain is *only* for packets going in to the firewall itself; packets going through it go through the forward chain, but not the input or output chains. If that wasn't your understanding of how packets go through iptables, it might be worth you going back to your original ruleset and see if you have all the rules you need for packets going through the machine, in your forward chain, because that's the only one they'll go through (as well as prerouting and postrouting nat chains, of course). The conntrack entry you've shown above simply tells us that an initial packet was received from 192.168.2.3 going to 152.2.210.81 port 21 (ftp control port). It doesn't actually confirm whether that packet left the firewall or not, or if it did, how it tried to get to the outside world. It does confirm that no reply came back (syn_recv means first syn packet seen, second syn-ack packet expected), but we still don't know why. I'd still like to see an ethereal output from the eth1 cable, I'm afraid, because that's a sure way to know what packets actually go out to the Internet. Antony.
