• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

Tunnel setup: Can't receive packets

Started by rsberzerker, May 19, 2013, 05:33:19 PM

Previous topic - Next topic


I'm trying to set up my first tunnel on Debian Wheezy (7.0), but something is wrong. I can ping my ipv6 address (2001:470:xxxx:878::2), but not the server ipv6 address (2001:470:xxxx:878::1). Looking at the output of my ifconfig, I noticed the RX count is 0.

sit1      Link encap:IPv6-in-IPv4 
          inet6 addr: fe80::xxxx:501/64 Scope:Link
          inet6 addr: fe80::xxxx:ade6/64 Scope:Link
          inet6 addr: 2001:470:xxxx:878::2/64 Scope:Global
          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:2408 (2.3 KiB)

At first I thought it might be my crash attempt at writing an ipv6 firewall (ip6tables), so I took out all the rules and left the default policies at accept (see below), but no joy. Any suggestions???

root@linux:~# ip6tables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain AllowICMPs (0 references)
target     prot opt source               destination


What command did you use to create the tunnel. Did you get the server IPv4 address right?
Does the server know the correct IPv4 address of your tunnel endpoint?
Is there any NAT between your tunnel endpoint and the server, which could mess up the connection?
If you run a tcpdump on the physical interface while trying to ping the server IPv6 address, what do you see?


I used the example configuration in the tunnel details, Linux net-tools. Everything looks right.


So your public ipv4 address is configured on your linux box? Or more than likely, is it actually behind NAT and you didn't change the source IP to the NAT IP when pasting the tunnel commands :D


Yes, my linux box has a public IPv4 address. I turned off NATing on my DSL modem. This, 99.XXX.173.230, is my Client IPv4 Address in the details page. From ifconfig:

eth1      Link encap:Ethernet  HWaddr 00:XX:5a:64:86:c7 
          inet addr:99.XXX.173.230  Bcast:99.XXX.173.255  Mask:
          inet6 addr: fe80::XXX:5aff:fe64:86c7/64 Scope:Link
          RX packets:15361 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16649 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6034134 (5.7 MiB)  TX bytes:3586688 (3.4 MiB)
          Interrupt:21 Base address:0xc000

I'll do the tcpdump tomorrow when I get home from work.


anything in iptables? (not ip6tables)


Quote from: rsberzerker on May 19, 2013, 08:51:08 PM99.XXX.173.230
How are we supposed to help you, with only that information? is rejecting protocol 41 packets with ICMP port unreachable. Usually that means the receiving tunnel endpoint has been configured to only allow incoming packets from a specific source IPv4 address. I can see how such filtering makes sense, if the packets would be forwarded onto the IPv6 backbone. But if they are just being delivered to the LAN, I know of no harm done by allowing arbitrary source IPv4 addresses in the header, which is going to be removed anyway. The possibility of filtering legitimate packets is however a real concern. is accepting the protocol 41 packets, but after decapsulation it applies filtering rules to the IPv6 packets. It is rejecting the packets with type=1, code=1. Also, it is using a spurious source IP address on the ICMPv6 errors. Those are sent with source :: This is a known behaviour of some 6rd implementations. is forwarding protocol 41 packets to on the LAN, but no host on the LAN is responding to ARP requests for that IP address.



Habit is to remove personal info. I suppose in this case, I should include it. MY address is None of those you listed belongs to me. At the *moment*, I've got my tunnel end down, since with it up, lots of sites are inaccessible, like this one. But with some ideas, I'll happily bring it up again, but this evening. I post right before I do this. It looks like you have access to the info I'll need to fix the problem.


As for iptables, I used my test script which is essentially a mirror of the ip6tables I used above. No rules, default policies, both filter and nat, are accept. That didn't work either. I was thinking something there might be blocking tho incoming packets, and that something was iptables. No joy there either.


Quote from: rsberzerker on May 20, 2013, 04:57:26 AMMY address is
I can get no packets through to that IP. Traceroute ends at That is true for both ordinary traceroute as well as protocol 41 packets.

Could you try this from your end: traceroute -P 41


Sorry for the delay in getting back to you. Real life keeps imposing on my free time...

traceroute -P 41

Could it be my provider, AT&T, is blocking this protocol??? The traceroute reaches my modem (, but dies after that.

traceroute to (, 30 hops max, 60 byte packets
1 (  0.162 ms  0.176 ms  0.109 ms
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *
11  * * *^C

I'll leave the tunnel up, since I figured out how to work around the websites don't work because the tunnel doesn't work. If anyone is searching this thread, I setup squid, then added the directive dns_v4_first on so that my web browsers ignore ipv6 sites.

BTW, my address has changed. Now I'm


This a 2wire "modem"? There are threads about those devices here, maybe they'll help if it is.


No, my modem is a speedstream, not a 2wire.


Quote from: rsberzerker on May 21, 2013, 08:36:36 PMThe traceroute reaches my modem (, but dies after that.
Modems do not show up in a traceroute, routers do. But often you will find a router and a modem to be built into a single box. This particular router appears to be doing NAT, which is probably what is causing problems. Only some NAT devices can handle protocol 41 in the default configuration. Some need an explicit forwarding to be configured for protocol 41. Some NAT devices do not support protocol forwarding at all. If you cannot get the NAT to behave, you might be able to completely turn off the router and use just the modem.

Ideally you don't run protocol 41 through a NAT at all. Rather you configure the device doing NAT to be the endpoint for the 6in4 tunnel. But you may come across some NAT devices without support for 6in4 tunnelling, in which case you have to come up with something else.