I am trying to setup tunneling with the purpose of connecting a private
addressed network to a public addressed one. It appears that the tunneling
node on the private addressed side is corrupting the packets from all the
private addressed nodes which are destined for the tunneling node on the
public addressed side. Packets from a private addressed node to another public
addressed one, behind the one with the tunnel go through unscathed.
The minimal setup with which I can reproduce this is as follows:
Node sparhawk, running either Linux, W95 or WNT, IP address 192.168.1.2
Node ehlana, running Linux 2.0.3[34], has two 3c905's with IP addresses
192.168.1.1 and 192.168.2.1, sparhawk is connected with a crosscable to the
former. The latter is connected to a 10baseT hub. Ehlana contains a Teles 16.3
ISDN board for connection to our provider, on which the permanent address
193.67.90.2 is assigned. ehlana uses ppp over ISDN for the connection. ehlana
runs a standard Linux kernel firewall with masquerading enabled (for the
private addressed nodes)
Node tommie, running Linux 2.0.33, has an AMD 79C970 (lance32) with IP address
193.67.88.3. Tommie contains 2 Teles 16.3 ISDN boards for connection to our
provider, on which the address 193.67.88.3 is assigned. tommie uses rawip for
it's connection, because it's peer on the provider side is also a Linux
machine. tommie runs a standard Linux kernel firewall.
Node ernie, running SCO 3.2.4.2 with IP address 193.67.88.1
Tunnel setup on ehlana:
modprobe ipip; modprobe new_tunnel
ifconfig tunl0 193.67.90.2 pointopoint 193.67.88.3 netmask 255.255.255.255
route add 193.67.88.3 ippp1
route add -net 193.67.88.0 tunl0
Tunnel setup on tommie:
modprobe ipip; modprobe new_tunnel
ifconfig tunl0 193.67.88.3 pointopoint 193.67.90.2 netmask 255.255.255.255
(193.67.90.2 is handled by the default route, but I've tried a static route as
well)
route add -net 192.168.0.0 netmask 255.255.255.252 tunl0
I can now ping from sparhawk to ernie, and the other way around as well. I can
ping from ehlana to ernie, and the other way around. I can ping from ehlana to
tommie, but this is not handled by the tunnel. What I can't do is ping from
sparhawk to tommie or the other way around. If I use tcpdump on both sparhawk
and ehlana I see differences:
Tcpdump on node sparhawk:
21:50:36.084370 0:60:8:74:a4:a5 0:a0:24:d8:d6:9b ip 98: tommie.cypres.nl > sparhawk.cypres.nl: icmp: echo request
4500 0054 9179 0000 3f01 0f3f c143 5803
c0a8 0102 0800 fd6c 6302 5803 8b13 a935
1841 0800 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
21:50:36.084370 0:a0:24:d8:d6:9b 0:60:8:74:a4:a5 ip 98: sparhawk.cypres.nl > tommie.cypres.nl: icmp: echo reply
4500 0054 9afd 0000 4001 04bb c0a8 0102
c143 5803 0000 056d 6302 5803 8b13 a935
1841 0800 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
Tcpdump on node ehlana:
21:50:38.450109 0:60:8:74:a4:a5 0:a0:24:d8:d6:9b ip 98: tommie.cypres.nl > sparhawk.cypres.nl: icmp: echo request
4500 0054 9179 0000 3f01 0f3f c143 5803
c0a8 0102 0800 fd6c 6302 5803 8b13 a935
1841 0800 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
21:50:38.450109 3:0:3d:c0:0:8 0:60:8:74:a4:ff d521 98:
4500 0054 9afd 0000 3f01 05bb c0a8 0102
c143 5803 0000 056d 6302 5803 8b13 a935
1841 0800 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435 3637
The echo replies on ehlana are corrupted in the ethernet and IP headers. I
suspect this happens somewhere in the kernel. I can reproduce the exact same
thing by connecting a different Linux machine to ehlana's other ethernet
interface, so I don't think the problem is hardware or cabling related. The sa
me thing seems to happen when I ping one of ehlana's IP addresses other than
193.67.90.2, though I can't get tcpdump to see these packets, they
(appropriately) never reach the cable. The packets are not blocked by either
firewall, I've checked this with i pfwadm -c.
I have not yet included my entire configuration files to save bandwidth for
those on the list to whom this is not of interest, I have not included our
firewall configuration on this public list for security reasons. As I am not
on the linux kernel list please mail me directly.
I am willing to do work on this myself, but at this moment I need some clues
where to begin looking.
Thanx,
Hugo Van den Berg.
------------------------------------------------
Hugo Van den Berg - hbe@cypres.nl
Hugo.VandenBerg@net.hcc.nl
Phone - +31 (0)30 - 60 25 400
Fax - +31 (0)30 - 60 50 799
------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html