Hello again ! There are two things that look odd to me: 1) packets on port 25 are correctly forwarded (after decapsulation) to the redirected host on the 192.168.3.0 network *but* nothing goes back on the same network on port 25 (i.e. from interface eth0 to tunl0); 2) there is a very strange and very long MAC entry in the PREROUTING log for IN=tunl0. I have tried using the target TRACE, but it doesn't help much. I've got plenty of LOG targets disseminated everywhere that TRACE doesn't add anything. But again, I can't see POSTROUTING from the host where packets are being forwarded and I can't see replies going back on eth0 from that same machine (the sendmail machine) to the iptables machine. I also forgot to attach the iptables rules in my previous message, but here you go: *raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A PREROUTING -p tcp --dport 25 -j TRACE -A PREROUTING -p tcp --dport 25 -j TRACE COMMIT *nat :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A PREROUTING -p tcp --dport 25 -j LOG --log-prefix "PREROUTING: " -A PREROUTING -p tcp --dport 25 -j DNAT --to-destination 192.168.3.69 -A PREROUTING -p tcp --dport 587 -j DNAT --to-destination 192.168.3.69 -A OUTPUT -p tcp --dport 25 -j LOG --log-prefix "OUTPUT: " -A OUTPUT -p tcp --dport 25 -j DNAT --to-destination 192.168.3.69 # The following rule is not related, it's masquerading for another network... -A POSTROUTING -o eth0 -s 192.168.4.0/24 -j MASQUERADE -A POSTROUTING -p tcp --dport 25 -j LOG --log-prefix "POSTROUTING: " -A POSTROUTING -o eth0 -p tcp --dport 25 -j MASQUERADE -A POSTROUTING -o eth0 -p tcp --dport 587 -j MASQUERADE #-A POSTROUTING -o eth0 -p tcp --dport 25 -j SNAT --to-source 192.168.3.64 #-A POSTROUTING -o eth0 -p tcp --dport 587 -j SNAT --to-source 192.168.3.64 COMMIT *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT -A INPUT -p tcp --dport 25 -j LOG --log-prefix "SMTP (in): " -A OUTPUT -p tcp --dport 25 -j LOG --log-prefix "SMTP (out): " -A FORWARD -p tcp --dport 25 -j LOG --log-prefix "SMTP (fwd): " ## ##-A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT ## ##-A INPUT -m state --state NEW -m tcp -p tcp --dport 587 -j ACCEPT -A FORWARD -i tunl0 -o eth0 -p tcp --dport 25 -j LOG --log-prefix "SMTP (fwd tunl0-eth0): " -A FORWARD -i tunl0 -o eth0 -p tcp --dport 25 -j ACCEPT -A FORWARD -i eth0 -o tunl0 -p tcp --dport 25 -j LOG --log-prefix "SMTP (fwd eth0-tunl0): " -A FORWARD -i eth0 -o tunl0 -p tcp --dport 25 -j ACCEPT -A INPUT -p 4 -j LOG --log-prefix "ipencap (in): " -A INPUT -p 4 -i eth0 -j ACCEPT -A OUTPUT -p 4 -j LOG --log-prefix "ipencap (out): " -A OUTPUT -p 4 -o eth0 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT Note that I have also tried with a default ACCEPT policy instead of default DROP and it doesn't help. Also, I have tried with SNAT instead of MASQUERADING (and which probably is more precise) but it didn't help either. I am beginning to think there is something wrong with the tunnel interface, but I can't think of a possible mistake in its configuration as it's just "ifconfig tunl0 theipaddressoftheiptablesmachineonthetunnelinterface up". Once again, I can get sendmail on the forwarded host to respond to connections originating from the internal 192.168.3.0/24 network, so sendmail is up and running and forwarding works within the internal network. The problem arise for connection originating from the tunnel interface. I hope that some light on the problem can be shed now that I have posted full details ! Thanks again very much for offering to help out. Appreciated. Regards, Guido On Fri, 2010-02-12 at 15:41 +0100, Patrick McHardy wrote: > Guido Trentalancia wrote: > > Hello again Patrick, > > > > and thanks for your kind reply. > > > > The decapsulated packets are shown in the PREROUTING log output that I > > attached in another message and that I am quoting here again: > > > > Feb 11 20:50:15 gyokuro kernel: PREROUTING: IN=tunl0 OUT= > > MAC=45:00:00:4c:d5:6a:00:00:29:04:0d:78:a9:e4:42:fb:c0:a8:01:44:45:00:00:38:55:74:40:00:24:06:62:30:51:58:30:3c:2c:86:f1:01:d7:dc:00:19:a6:fe:a2:4b:00:00:00:00:90:02:16:d0:89:4e:00:00:02:04:05:b4:04:02:08:0a:04:54:f7:3f:00:00:00:00:00:00:00:00:02:00:00:00:00:00:00:00:00:b0:05:08:00:00:00:00:00:00:00:00:00:e0:82:09:00:00:00:00:00:00:00:00:00:00:00:00 SRC=smtppeeripaddress DST=theipaddressoftheiptablesmachineonthetunnelinterface LEN=56 TOS=0x00 PREC=0x00 TTL=36 ID=21876 DF PROTO=TCP SPT=55260 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 > > > > So, because we have smtppeeripaddress (the host that originally > > requested a connection on port 25 smtp), then they are decapsulated. > > > > Consider the log output you are talking about is produced with: > > > > -A INPUT -p 4 -j LOG --log-prefix "ipencap (in): " > > > > therefore I was expecting it to only print packets with the IPIP > > encapsulation protocol and not the decapsulated IP packets. > > > > However, after further investigation I discovered that the problem lies > > in the tunnel itself and perhaps in the way the iptables machine deals > > with the packets from the tunnel interface. This is because even > > connection directed to the iptables machine and not being redirected > > anywhere are not working. > > > > The point is that everything from the tunnel is allowed: > > > > -A INPUT -p 4 -i eth0 -j ACCEPT > > -A OUTPUT -p 4 -o eth0 -j ACCEPT > > > > Despite that, I can't see decapsulated packets directed to port 25 (even > > not considering host redirection with DNAT) using : > > > > -A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j LOG > > --log-prefix "SMTP: " > > > > or using: > > > > -A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j LOG > > --log-prefix "SMTP: " > > > > The only way I can see decapsulated packets, as already mentioned, is > > through the PREROUTING log output. And in general I can see IPIP packets > > using tcpdump or with the above mentioned "-p 4 -j LOG" rule. > > > > How can I debug this decapsulation issue further. There might be > > something wrong with the tunnel itself, perhaps not related to > > iptables ? > > > > I configure the tunnel using: > > > > /sbin/ip tunnel add mode ipip local > > theipaddressoftheiptablesmachineonthetunnelinterface dev tunl0 > > /sbin/ifconfig tunl0 > > theipaddressoftheiptablesmachineonthetunnelinterface mtu 512 up > > So there's no IP address on tunl0? > > > One thing that I have observed is that when rp_filter is set to 0 for > > the tunnel, then something appears in the log: > > > > Feb 12 14:21:25 gyokuro kernel: SMTP (in): IN=tunl0 OUT= > > MAC=45:00:00:4c:d2:2a:00:00:2a:04:0f:b8:a9:e4:42:fb:c0:a8:01:44:45:00:00:38:5f:e2:40:00:24:06:57:c2:51:58:30:3c:2c:86:f1:01:a2:12:00:19:eb:82:6c:3f:00:00:00:00:90:02:16:d0:73:a2:00:00:02:04:05:b4:04:02:08:0a:04:b5:33:dd:00:00:00:00:00:00:00:00:02:00:00:00:00:00:00:00:02:f4:0e:24:00:00:00:00:00:00:00:00:00:f0:7b:08:00:00:00:00:00:00:00:00:00:00:00:00 SRC=smtppeeripaddress DST=theipaddressoftheiptablesmachineonthetunnelinterface LEN=56 TOS=0x00 PREC=0x00 TTL=36 ID=24546 DF PROTO=TCP SPT=41490 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 > > > > Still smtppeeripaddress doesn't get a connection and anyway I am not > > sure at all that rp_filter should be set to 0... > > > > Any idea ? Thanks for your help ! > > Please post the full output of > > ip link list > ip addr show > ip route show > > and all iptables rules. > > You can also try tracing the packet's flow through the ruleset > using the TRACE target. > -- 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
