Tunnel setup: Can't receive packets

[rsberzerker]

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.

Code Select Expand


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

Code Select Expand


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


[kasperd]

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?

[rsberzerker]

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

[broquea]

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

[rsberzerker]

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:

Code Select Expand


eth1      Link encap:Ethernet  HWaddr 00:XX:5a:64:86:c7 
          inet addr:99.XXX.173.230  Bcast:99.XXX.173.255  Mask:255.255.255.0
          inet6 addr: fe80::XXX:5aff:fe64:86c7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          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.

[broquea]

anything in iptables? (not ip6tables)

[kasperd]

99.XXX.173.230

How are we supposed to help you, with only that information?

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

99.245.173.230 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 ::99.245.173.230. This is a known behaviour of some 6rd implementations.

99.232.173.230 is forwarding protocol 41 packets to 192.168.1.104 on the LAN, but no host on the LAN is responding to ARP requests for that IP address.

[rsberzerker]

kasperd,

Habit is to remove personal info. I suppose in this case, I should include it. MY address is 99.18.173.230. 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.

[kasperd]

MY address is 99.18.173.230.

I can get no packets through to that IP. Traceroute ends at 12.122.103.113. That is true for both ordinary traceroute as well as protocol 41 packets.

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

[rsberzerker]

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

traceroute -P 41 209.51.181.2

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

Code Select Expand


traceroute to 209.51.181.2 (209.51.181.2), 30 hops max, 60 byte packets
1  192.168.0.1 (192.168.0.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 99.29.14.209.

[broquea]

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

[rsberzerker]

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

[kasperd]

The traceroute reaches my modem (192.168.0.1), 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.