Port forwarding with iptables on tunnel interface

Port forwarding with iptables on tunnel interface

[Guido Trentalancia]

Hello !

I have the following problem. I need to forward/redirect all connections
to port 25 (smtp) from one host (192.168.3.64) to another host on the
same network (192.168.3.69).

I am using the following iptables rules:

-A PREROUTING -p tcp --dport 25 -j DNAT --to-destination 192.168.3.69
-A POSTROUTING -p tcp -d 192.168.1.65 --dport 25 -j MASQUERADE

and I have also tried the following alternative rules:

-A PREROUTING -p tcp --dport 25 -j DNAT --to-destination 192.168.3.69
-A POSTROUTING -p tcp -d 192.168.1.65 --dport 25 -j SNAT --to-source
192.168.3.64

The connections come from an IP-IP tunnel and they are allowed by the
following iptables rules:

-A INPUT -p 4 -i eth0 -j ACCEPT
-A OUTPUT -p 4 -o eth0 -j ACCEPT

It used to work until a few days ago. But now it only works from within
the LAN and not from the tunnel. I have not changed any iptables rules
and I have only upgraded the system to the latest kernel (2.6.32.8).

The version of iptables that I am using is 1.4.3.1.

Any idea on how to get it back working ?

Regards,

Guido

Re: Port forwarding with iptables on tunnel interface

[Patrick McHardy]

Guido Trentalancia wrote:
> Hello !
> 
> I have the following problem. I need to forward/redirect all connections
> to port 25 (smtp) from one host (192.168.3.64) to another host on the
> same network (192.168.3.69).
> 
> I am using the following iptables rules:
> 
> -A PREROUTING -p tcp --dport 25 -j DNAT --to-destination 192.168.3.69
> -A POSTROUTING -p tcp -d 192.168.1.65 --dport 25 -j MASQUERADE
> 
> and I have also tried the following alternative rules:
> 
> -A PREROUTING -p tcp --dport 25 -j DNAT --to-destination 192.168.3.69
> -A POSTROUTING -p tcp -d 192.168.1.65 --dport 25 -j SNAT --to-source
> 192.168.3.64
> 
> The connections come from an IP-IP tunnel and they are allowed by the
> following iptables rules:
> 
> -A INPUT -p 4 -i eth0 -j ACCEPT
> -A OUTPUT -p 4 -o eth0 -j ACCEPT
> 
> It used to work until a few days ago. But now it only works from within
> the LAN and not from the tunnel. I have not changed any iptables rules
> and I have only upgraded the system to the latest kernel (2.6.32.8).
> 
> The version of iptables that I am using is 1.4.3.1.
> 
> Any idea on how to get it back working ?

Try logging the packets coming out of the tunnel to see whats wrong.

Re: Port forwarding with iptables on tunnel interface

[Guido Trentalancia]

Hello Patrick,

thanks very much for your message !

By the way, some IP addresses in the original message are wrong (read
192.168.3.69 instead of 192.168.1.65), but that's just a typo.

Here is the log produced by iptables on 192.168.3.64:

Feb 11 20:09:58 gyokuro kernel: ipencap (in): IN=eth0 OUT=
MAC=macaddressofreceiverandsender SRC=senderipaddress DST=192.168.3.64
LEN=76 TOS=0x00 PREC=0x00 TTL=41 ID=26562 PROTO=4 
Feb 11 20:10:01 gyokuro kernel: ipencap (in): IN=eth0 OUT=
MAC=macaddressofreceiverandsender SRC=senderipaddress DST=192.168.3.64
LEN=76 TOS=0x00 PREC=0x00 TTL=41 ID=28099 PROTO=4 
Feb 11 20:10:07 gyokuro kernel: ipencap (in): IN=eth0 OUT=
MAC=macaddressofreceiverandsender SRC=senderipaddress DST=192.168.3.64
LEN=76 TOS=0x00 PREC=0x00 TTL=41 ID=28322 PROTO=4 

And this is tcpdump on 192.168.3.64:

20:09:58.362266 IP (tos 0x0, ttl 41, id 26562, offset 0, flags [none],
proto IPIP (4), length 76) senderipaddress > 192.168.3.64: IP (tos 0x0,
ttl 35, id 38176, offset 0, flags [DF], proto TCP (6), length 56)
smtppeeripaddress.37441 > localhost.smtp: S, cksum 0x641c (correct),
3101176972:3101176972(0) win 5840 <mss 1460,sackOK,timestamp 547791276
0>

I can't see anything odd in the above logs. IPIP encapsulated packets
are allowed in... Then if you look at the output from tcpdump, you see
that they actually contain a connection request to the port 25 (smtp)
from some host with address smtppeeripaddress. But this connection is
not forwarded to the appropriate host as specified in the DNAT and
MASQUERADE iptables rules.

Any idea ?

Regards,

Guido

On Thu, 2010-02-11 at 19:57 +0100, Patrick McHardy wrote:
> Guido Trentalancia wrote:
> > Hello !
> > 
> > I have the following problem. I need to forward/redirect all connections
> > to port 25 (smtp) from one host (192.168.3.64) to another host on the
> > same network (192.168.3.69).
> > 
> > I am using the following iptables rules:
> > 
> > -A PREROUTING -p tcp --dport 25 -j DNAT --to-destination 192.168.3.69
> > -A POSTROUTING -p tcp -d 192.168.1.65 --dport 25 -j MASQUERADE
> > 
> > and I have also tried the following alternative rules:
> > 
> > -A PREROUTING -p tcp --dport 25 -j DNAT --to-destination 192.168.3.69
> > -A POSTROUTING -p tcp -d 192.168.1.65 --dport 25 -j SNAT --to-source
> > 192.168.3.64
> > 
> > The connections come from an IP-IP tunnel and they are allowed by the
> > following iptables rules:
> > 
> > -A INPUT -p 4 -i eth0 -j ACCEPT
> > -A OUTPUT -p 4 -o eth0 -j ACCEPT
> > 
> > It used to work until a few days ago. But now it only works from within
> > the LAN and not from the tunnel. I have not changed any iptables rules
> > and I have only upgraded the system to the latest kernel (2.6.32.8).
> > 
> > The version of iptables that I am using is 1.4.3.1.
> > 
> > Any idea on how to get it back working ?
> 
> Try logging the packets coming out of the tunnel to see whats wrong.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Port forwarding with iptables on tunnel interface

[Patrick McHardy]

Guido Trentalancia wrote:
> Hello Patrick,
> 
> thanks very much for your message !
> 
> By the way, some IP addresses in the original message are wrong (read
> 192.168.3.69 instead of 192.168.1.65), but that's just a typo.
> 
> Here is the log produced by iptables on 192.168.3.64:
> 
> Feb 11 20:09:58 gyokuro kernel: ipencap (in): IN=eth0 OUT=
> MAC=macaddressofreceiverandsender SRC=senderipaddress DST=192.168.3.64
> LEN=76 TOS=0x00 PREC=0x00 TTL=41 ID=26562 PROTO=4 
> Feb 11 20:10:01 gyokuro kernel: ipencap (in): IN=eth0 OUT=
> MAC=macaddressofreceiverandsender SRC=senderipaddress DST=192.168.3.64
> LEN=76 TOS=0x00 PREC=0x00 TTL=41 ID=28099 PROTO=4 
> Feb 11 20:10:07 gyokuro kernel: ipencap (in): IN=eth0 OUT=
> MAC=macaddressofreceiverandsender SRC=senderipaddress DST=192.168.3.64
> LEN=76 TOS=0x00 PREC=0x00 TTL=41 ID=28322 PROTO=4 

I don't see any decapsulated packets.

Re: Port forwarding with iptables on tunnel interface

[Guido Trentalancia]

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

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 !

Regards,

Guido

On Fri, 2010-02-12 at 06:29 +0100, Patrick McHardy wrote:
> Guido Trentalancia wrote:
> > Hello Patrick,
> > 
> > thanks very much for your message !
> > 
> > By the way, some IP addresses in the original message are wrong (read
> > 192.168.3.69 instead of 192.168.1.65), but that's just a typo.
> > 
> > Here is the log produced by iptables on 192.168.3.64:
> > 
> > Feb 11 20:09:58 gyokuro kernel: ipencap (in): IN=eth0 OUT=
> > MAC=macaddressofreceiverandsender SRC=senderipaddress DST=192.168.3.64
> > LEN=76 TOS=0x00 PREC=0x00 TTL=41 ID=26562 PROTO=4 
> > Feb 11 20:10:01 gyokuro kernel: ipencap (in): IN=eth0 OUT=
> > MAC=macaddressofreceiverandsender SRC=senderipaddress DST=192.168.3.64
> > LEN=76 TOS=0x00 PREC=0x00 TTL=41 ID=28099 PROTO=4 
> > Feb 11 20:10:07 gyokuro kernel: ipencap (in): IN=eth0 OUT=
> > MAC=macaddressofreceiverandsender SRC=senderipaddress DST=192.168.3.64
> > LEN=76 TOS=0x00 PREC=0x00 TTL=41 ID=28322 PROTO=4 
> 
> I don't see any decapsulated packets.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Port forwarding with iptables on tunnel interface

[Patrick McHardy]

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.

Re: Port forwarding with iptables on tunnel interface

[Guido Trentalancia]

Hello Patrick !

You are very kind to offer your help and advice...

My reply follows your quoted text.

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?

Yes the IP for tunl0 is
theipaddressoftheiptablesmachineonthetunnelinterface that I referenced
elsewhere. Without getting into numbers it's a valid and unique public
IP address. I prefer not to post public IP addresses on the mailing
list.

> > 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

ip link list:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
    link/ether 00:02:3f:0b:79:a8 brd ff:ff:ff:ff:ff:ff
3: wmaster0: <UP,LOWER_UP> mtu 0 qdisc pfifo_fast state UNKNOWN qlen
1000
    link/ieee802.11 00:07:40:dd:9c:88 brd 00:00:00:00:00:00
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
    link/ether 00:07:40:dd:9c:88 brd ff:ff:ff:ff:ff:ff
5: pan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN 
    link/ether 8e:03:0e:7c:f8:28 brd ff:ff:ff:ff:ff:ff
6: mon.wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN qlen 1000
    link/ieee802.11/radiotap 00:07:40:dd:9c:88 brd ff:ff:ff:ff:ff:ff
7: tunl0: <NOARP,UP,LOWER_UP> mtu 512 qdisc noqueue state UNKNOWN 
    link/ipip 0.0.0.0 brd 0.0.0.0

ip addr show (only relevant entries):

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
    link/ether 00:02:3f:0b:79:a8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.64/24 brd 192.168.3.255 scope global eth0
    inet6 fe80::202:3fff:fe0b:79a8/64 scope link 
       valid_lft forever preferred_lft forever
7: tunl0: <NOARP,UP,LOWER_UP> mtu 512 qdisc noqueue state UNKNOWN 
    link/ipip 0.0.0.0 brd 0.0.0.0
    inet theipaddressoftheiptablesmachineonthetunnelinterface/8 scope
global tunl0

ip route show (only relevant entries):

192.168.3.0/24 dev eth0  proto kernel  scope link  src 192.168.3.64

tunl0 has 248 entries, I cannot post all of them here and also I don't
want to expose the public IP addresses of my peers for privacy and
security reasons. It's basically 248 entries from the same network of
theipaddressoftheiptablesmachineonthetunnelinterface routed via public
Internet addresses of other machines.

> and all iptables rules.
> 
> You can also  try tracing the packet's flow through the ruleset
> using the TRACE target.

I look forward to hearing from you.

Regards,

Guido

Re: Port forwarding with iptables on tunnel interface

[Guido Trentalancia]

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.
> 

Re: Port forwarding with iptables on tunnel interface

[Mike Wright]

Guido Trentalancia wrote:
> 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

<snip />

Salve, Guido.  I gave this a verrrry quick glance and off the top of my 
head I think something looks fishy in the POSTROUTING rules.

In the PREROUTING you are selecting based on the *destination* port.  On 
the return trip shouldn't POSTROUTING use *source* port?

Hope that helps,
Mike Wright

Re: Port forwarding with iptables on tunnel interface

[Guido Trentalancia]

Ciao Mike !

On Fri, 2010-02-12 at 11:01 -0800, Mike Wright wrote:
> Guido Trentalancia wrote:
> > 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
> 
> <snip />
> 
> Salve, Guido.  I gave this a verrrry quick glance and off the top of my 
> head I think something looks fishy in the POSTROUTING rules.
> 
> In the PREROUTING you are selecting based on the *destination* port.  On 
> the return trip shouldn't POSTROUTING use *source* port?

Hold on a second. The originating caller expects a reply on *its 25
port*. Therefore my originating port could be everything and usually is
an high port (> 1024) different than 25, but the important is that the
destination port is 25 because there is the caller waiting a reply. 

Therefore even in the case of SNAT, I am selecting the destination port.

Do you convene with me now ?

Regards,

Guido

> Hope that helps,
> Mike Wright
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Port forwarding with iptables on tunnel interface

[Mike Wright]

Guido Trentalancia wrote:
> Ciao Mike !
> 
> On Fri, 2010-02-12 at 11:01 -0800, Mike Wright wrote:
>> Guido Trentalancia wrote:
>>> 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
>> <snip />
>>
>> Salve, Guido.  I gave this a verrrry quick glance and off the top of my 
>> head I think something looks fishy in the POSTROUTING rules.
>>
>> In the PREROUTING you are selecting based on the *destination* port.  On 
>> the return trip shouldn't POSTROUTING use *source* port?
> 
> Hold on a second. The originating caller expects a reply on *its 25
> port*. Therefore my originating port could be everything and usually is
> an high port (> 1024) different than 25, but the important is that the
> destination port is 25 because there is the caller waiting a reply. 
> 
> Therefore even in the case of SNAT, I am selecting the destination port.
> 
> Do you convene with me now ?

Yes, indeed.  It seems I have my brain in backwards ;D

Buona fortuna !

Re: Port forwarding with iptables on tunnel interface

[Guido Trentalancia]

Hello again Mike,

On Fri, 2010-02-12 at 11:56 -0800, Mike Wright wrote:
> >> Salve, Guido.  I gave this a verrrry quick glance and off the top of my 
> >> head I think something looks fishy in the POSTROUTING rules.
> >>
> >> In the PREROUTING you are selecting based on the *destination* port.  On 
> >> the return trip shouldn't POSTROUTING use *source* port?
> > 
> > Hold on a second. The originating caller expects a reply on *its 25
> > port*. Therefore my originating port could be everything and usually is
> > an high port (> 1024) different than 25, but the important is that the
> > destination port is 25 because there is the caller waiting a reply. 
> > 
> > Therefore even in the case of SNAT, I am selecting the destination port.
> > 
> > Do you convene with me now ?
> 
> Yes, indeed.  It seems I have my brain in backwards ;D
> 
> Buona fortuna !

You were actually right. The SNAT needs to be done with --sport 25 and
not with --dport 25. But still I cannot get the mail delivered and
actually I cannot see POSTROUTING but only untranslated reply packets...

Any other idea ?

Regards,

Guido

Re: Port forwarding with iptables on tunnel interface

[Guido Trentalancia]

And for the sack of completeness, here is the log produced by iptables
for the PRE and POST ROUTING rules (DNAT and MASQUERADING):

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 
Feb 11 20:50:18 gyokuro kernel: PREROUTING: IN=tunl0 OUT=
MAC=45:00:00:4c:d5:e1:00:00:29:04:0d:01:a9:e4:42:fb:c0:a8:01:44:45:00:00:38:55:75:40:00:24:06:62:2f:51:58:30:3c:2c:86:f1:01:d7:dc:00:19:a6:fe:a2:4b:00:00:00:00:90:02:16:d0:88:22:00:00:02:04:05:b4:04:02:08:0a:04:54:f8:6b: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=21877 DF PROTO=TCP SPT=55260 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 
Feb 11 20:50:24 gyokuro kernel: PREROUTING: IN=tunl0 OUT=
MAC=45:00:00:4c:d6:de:00:00:29:04:0c:04:a9:e4:42:fb:c0:a8:01:44:45:00:00:38:55:76:40:00:24:06:62:2e:51:58:30:3c:2c:86:f1:01:d7:dc:00:19:a6:fe:a2:4b:00:00:00:00:90:02:16:d0:85:ca:00:00:02:04:05:b4:04:02:08:0a:04:54:fa:c3: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=21878 DF PROTO=TCP SPT=55260 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 

What I see from here is that the POSTROUTING did not produce any log.
But it doesn't give me any hint...

Actually I don't see any connection request on the destination smtp
server, so it has nothing to reply and that's probably why there is no
log output for the POSTROUTING table.

But if it does not get any connection is because the address
theipaddressoftheiptablesmachineonthetunnelinterface is not DNAT'ed to
192.168.3.69 as requested by the rule itself. I can't see the DNAT
translation being logged anywhere, not even in the PREROUTING log output
it does mention about it explicitly...

On Thu, 2010-02-11 at 19:57 +0100, Patrick McHardy wrote:
> Guido Trentalancia wrote:
> > Hello !
> > 
> > I have the following problem. I need to forward/redirect all connections
> > to port 25 (smtp) from one host (192.168.3.64) to another host on the
> > same network (192.168.3.69).
> > 
> > I am using the following iptables rules:
> > 
> > -A PREROUTING -p tcp --dport 25 -j DNAT --to-destination 192.168.3.69
> > -A POSTROUTING -p tcp -d 192.168.1.65 --dport 25 -j MASQUERADE
> > 
> > and I have also tried the following alternative rules:
> > 
> > -A PREROUTING -p tcp --dport 25 -j DNAT --to-destination 192.168.3.69
> > -A POSTROUTING -p tcp -d 192.168.1.65 --dport 25 -j SNAT --to-source
> > 192.168.3.64
> > 
> > The connections come from an IP-IP tunnel and they are allowed by the
> > following iptables rules:
> > 
> > -A INPUT -p 4 -i eth0 -j ACCEPT
> > -A OUTPUT -p 4 -o eth0 -j ACCEPT
> > 
> > It used to work until a few days ago. But now it only works from within
> > the LAN and not from the tunnel. I have not changed any iptables rules
> > and I have only upgraded the system to the latest kernel (2.6.32.8).
> > 
> > The version of iptables that I am using is 1.4.3.1.
> > 
> > Any idea on how to get it back working ?
> 
> Try logging the packets coming out of the tunnel to see whats wrong.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>