|
Weird "invisible tunnel" problem with Linux 2.4.21
![[fr]](/s/countries/fr.gif) Shadow Hawkins on Sunday, 21 September 2003 18:19:41
Hi folks!,
I am trying to setup a sixxs tunnel without much success on a regular Debian (Linux kernel 2.4.21) box.
The configuration seems okay, but when pinging an external machine (here, www.6bone.net) nothing happends in the ping output - but the tcpdump traces are looking good:
18:08:30.107538 10.0.0.1 > tunnelserver.concepts-ict.net: cl-167.ams-01.nl.sixxs.net > www.6bone.net: icmp6: echo request (encap)
18:08:30.251056 tunnelserver.concepts-ict.net > 10.0.0.1: www.6bone.net > cl-167.ams-01.nl.sixxs.net: icmp6: echo reply (encap)
www.6bone.net received my icmp echo-request, and replied immediately. but it seems that the local routes did not "see" the packet.
Same weird thing with a 'telnet www.kamenet 80':
18:13:29.732408 10.0.0.1 > tunnelserver.concepts-ict.net: cl-167.ams-01.nl.sixxs.net.55872 > orange.kame.net.www: SWE 1299377475:1299377475(0) win 4880 <mss[|tcp]> (encap)
18:13:30.210468 tunnelserver.concepts-ict.net > 10.0.0.1: orange.kame.net.www > cl-167.ams-01.nl.sixxs.net.55872: S 3895762835:3895762835(0) ack 1299377476 win 57344 <mss[|tcp]> [flowlabel 0x5f] (encap)
orange.kame.net:80 accepts the tcp connection and returns an ACK. but the local machine doesn't seem to "see" the ack, does not returns the regular SYN/ACK, and re-issue a SYN request.
Protocol 41 is being forwarded (NAT) to me by a router and outgoing protocol 41 is authorized ; and the fact that servers seems to reply correctly shows that the tunnel actually work.
(NAT: see http://www.euro6ix.org/documentation/euro6ix_co_upm-consulintel_wp4_ipv6_tunnels_nat_v1_6.pdf)
But the local stack just does not see the replies
I have a sixxs device (which seems to be) correctly configured:
auto sixxs
iface sixxs inet6 v4tunnel
address 2001:838:300:a6::2
netmask 64
endpoint 213.197.27.252
ttl 64
up ip link set mtu 1280 dev sixxs
up ip route add 2000::/3 via 2001:838:300:a6::1 dev sixxs
And my routine tables are looking good:
# ip -6 route
2001:838:300:a6::/64 via :: dev sixxs proto kernel metric 256 mtu 1280 advmss 1220
2000::/3 via 2001:838:300:a6::1 dev sixxs metric 1024 mtu 1280 advmss 1220
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1220
fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1220
fe80::/64 dev eth2 proto kernel metric 256 mtu 1500 advmss 1220
fe80::/64 via :: dev sixxs proto kernel metric 256 mtu 1280 advmss 1220
ff00::/8 dev eth0 proto kernel metric 256 mtu 1500 advmss 1220
ff00::/8 dev eth1 proto kernel metric 256 mtu 1500 advmss 1220
ff00::/8 dev eth2 proto kernel metric 256 mtu 1500 advmss 1220
ff00::/8 dev sixxs proto kernel metric 256 mtu 1280 advmss 1220
unreachable default dev lo proto none metric -1 error -101 advmss 1220
And, at last, the devices (eth1 is the device connected to the NAT router)
eth0 Link encap:Ethernet HWaddr 00:50:FC:48:A5:2C
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::250:fcff:fe48:a52c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5525 errors:0 dropped:0 overruns:0 frame:0
TX packets:7086 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:439501 (429.2 KiB) TX bytes:5347899 (5.1 MiB)
eth1 Link encap:Ethernet HWaddr 00:50:DA:0D:D0:A3
inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::250:daff:fe0d:d0a3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:29902 errors:0 dropped:0 overruns:0 frame:0
TX packets:39634 errors:0 dropped:0 overruns:0 carrier:0
collisions:22 txqueuelen:100
RX bytes:9212959 (8.7 MiB) TX bytes:44270434 (42.2 MiB)
Interrupt:5 Base address:0xa400
eth2 Link encap:Ethernet HWaddr 00:50:DA:07:E5:8D
inet addr:192.168.1.101 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::250:daff:fe07:e58d/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:5
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:422 (422.0 b)
Interrupt:12 Base address:0xa800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:24625 errors:0 dropped:0 overruns:0 frame:0
TX packets:24625 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:9023534 (8.6 MiB) TX bytes:9023534 (8.6 MiB)
lo:0 Link encap:Local Loopback
inet addr:10.99.0.1 Mask:255.255.255.255
UP LOOPBACK RUNNING MTU:16436 Metric:1
sixxs Link encap:IPv6-in-IPv4
inet6 addr: 2001:838:300:a6::2/64 Scope:Global
inet6 addr: fe80::a00:1/64 Scope:Link
inet6 addr: fe80::c0a8:165/64 Scope:Link
inet6 addr: fe80::c0a8:164/64 Scope:Link
inet6 addr: fe80::a63:1/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1280 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:170 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:21056 (20.5 KiB)
This is the first time such weird problem happends.. can anybody see an obvious and stupid mistake I could have commited? I am a bit stuck..
Xavier.
Weird "invisible tunnel" problem with Linux 2.4.21
Your endpoint doesn't ping on IPv6 nor on IPv4.
Note that some NAT's drop packets after the outward connections stay idle.
Check your IPv4 routing tables and specify a local IPv4 endpoint.
That could help.
Weird "invisible tunnel" problem with Linux 2.4.21
Shadow Hawkins on Sunday, 21 September 2003 23:00:11Your endpoint doesn't ping on IPv6 nor on IPv4
ipv4 icmp are filtered by the firewall (I remporarily disabled it during the first connection) - but ipv6 should pass
I definitely suspect something nasty either in the routine tables, or in the local link addresses.
Using tcpdump, I can see the icmp-request going out to the outside worls using through the tunnel, and I can see the icmp-reply coming back to me through the same tunnel, BUT ping6 does not "see" them. And I can also "see" SYN requests going out, and SYN-ACK replies coming back to me.. but telnet is still trying to send SYN requests, as it it did not see the SYN/ACK.
I also see regular ping6 (icmp-requests) from the tunnel, but the machine does not "sees" them.
This is definitely crazy..
I did not see anything wrong in my local link addresses, however:
# ip -6 ad
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
inet6 ::1/128 scope host
14: sixxs@NONE: <POINTOPOINT,NOARP,UP> mtu 1280 qdisc noqueue
inet6 2001:838:300:a6::2/64 scope global
inet6 fe80::a00:1/64 scope link
inet6 fe80::c0a8:165/64 scope link
inet6 fe80::c0a8:164/64 scope link
inet6 fe80::a63:1/64 scope link
15: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
inet6 fe80::250:fcff:fe48:a52c/64 scope link
16: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
inet6 fe80::250:daff:fe0d:d0a3/64 scope link
17: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
inet6 fe80::250:daff:fe07:e58d/64 scope link
Okay, I got 2001:838:300:a6::2 as my endpoint, good.
And I rechecked the routing:
# ip -6 ro
2001:838:300:a6::/64 via :: dev sixxs proto kernel metric 256 mtu 1280 advmss 1220
2000::/3 via 2001:838:300:a6::1 dev sixxs metric 1024 mtu 1280 advmss 1220
fe80::/64 via :: dev sixxs proto kernel metric 256 mtu 1280 advmss 1220
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440
fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440
fe80::/64 dev eth2 proto kernel metric 256 mtu 1500 advmss 1440
ff00::/8 dev sixxs proto kernel metric 256 mtu 1280 advmss 1220
ff00::/8 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440
ff00::/8 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440
ff00::/8 dev eth2 proto kernel metric 256 mtu 1500 advmss 1440
unreachable default dev lo proto none metric -1 error -101 advmss 1220
Okay, default goes to 2001:838:300:a6::1 using the tunnel.
But packets send back to me are just ignored by the ipv6 stack... crazy.
# ping6 www.6bone.net
PING www.6bone.net(www.6bone.net) 56 data bytes
--- www.6bone.net ping statistics ---
1 packets transmitted, 0 received, 100% loss, time 0ms
<no reply here!>
And tcpdump (same machine, of course) still shows correct traces:
22:58:18.451388 10.0.0.1 > tunnelserver.concepts-ict.net: cl-167.ams-01.nl.sixxs.net > www.6bone.net: icmp6: echo request (encap)
22:58:18.594652 tunnelserver.concepts-ict.net > 10.0.0.1: www.6bone.net > cl-167.ams-01.nl.sixxs.net: icmp6: echo reply (encap)
I sent an echo request, and I got an echo reply.
But ping6 definitely did not see it :(
Weird "invisible tunnel" problem with Linux 2.4.21
The IPv6 looks correct.
You quite possibly have to specify the local IPv4 address on the endpoint, this because you have multiple interfaces.
Try something like:
ip tun change local 10.0.0.1 dev sixxs
This let the kernel know that that is the local endpoint of the tunnel.
Another thing to try is without the NAT. Using a linux box for NAT is
much flexible.
Weird "invisible tunnel" problem with Linux 2.4.21
Shadow Hawkins on Sunday, 21 September 2003 23:20:51
I tried:
ip tunnel change sixxs local 10.0.0.1
But noluck (despite the fact the tunnel looks good) :(
# ip -6 tun
tunl0: ip/ip remote any local any ttl inherit nopmtudisc
gre0: gre/ip remote any local any ttl inherit nopmtudisc
sit0: ipv6/ip remote any local any ttl 64 nopmtudisc
sixxs: ipv6/ip remote 213.197.27.252 local 10.0.0.1 ttl 64
This is definitely weird. Maybe another 2.4.21 issue - I'll try to switch to 2.4.20 and see if it is better.
Weird "invisible tunnel" problem with Linux 2.4.21
Shadow Hawkins on Monday, 22 September 2003 00:19:58
Hurray!
I just recompiled a "fresh" 2.4.22 kernel with gre/tunnels compiled as module (not statically), and changed the ipchains script (but it did work well before..), and now everything seems okay. I did not exactly understand where could be the problem exactly anyway.. definitely something locally.
--- www.6bone.net ping statistics ---
139 packets transmitted, 139 received, 0% loss, time 139370ms
rtt min/avg/max/mdev = 140.500/143.819/153.357/1.987 ms
|
![[ch]](/s/countries/ch.gif)
on Sunday, 21 September 2003 21:54:54
Posting is only allowed when you are