Print

[Azendale]

I must being doing something stupid. I used to have this working, and now, no matter how much I try to simplify the situation, I can't seem to get any imcoming traffic on my tunnel.

I have an Ubuntu 12.04 box that does PPPoE to my ISP. Over that, it runs a HE tunnel. I can see packets going out like they should, but nothing comes in.

The Settings I should have from my tunnel page:
Server IPv4 Address:216.218.226.238
Server IPv6 Address:2001:470:a:29f::1/64
Client IPv4 Address:65.38.57.123 <- Automatically updated, I did check to make sure this is actually my IP
Client IPv6 Address:2001:470:a:29f::2/64
Routed IPv6 Prefixes
Routed /64:2001:470:b:29f::/64
Routed /48:2001:470:e89d::/48


/etc/network/interfaces entry:

Code: [Select]

auto he-ipv6
iface he-ipv6 inet6 v4tunnel
     endpoint 216.218.226.238
#     address  2001:470:e89d::1
#     netmask  128
     address 2001:470:a:29f::2
     netmask 64
     ttl 64
#     up ip -6 route add 2001:470:a:29f::/64 dev he-ipv6
     up ip -6 route add default dev he-ipv6
     down ip -6 route del default dev he-ipv6
#     down ip -6 route del 2001:470:a:29f::/64 dev he-ipv6
(The commented lines are what I had before. Before, I did not have the 2001:470:a:29f::2 address on the tunnel, I just set up a route for that block to the tunnel, and used an address from my /48. I changed that to what it should be to try to simplify it, but it still did not work).

Routing table:

Code: [Select]

ip -6 route show
2001:470:a:29f::/64 via :: dev he-ipv6  proto kernel  metric 256
2001:470:e89d:9ab6::/64 dev eth7  proto kernel  metric 256
2001:470:e89d:a272::/64 dev wlan2  proto kernel  metric 256
2001:470:e89d:d000::/64 dev virts  proto kernel  metric 256
2001:470:e89d:e83c::/64 dev wlan1  proto kernel  metric 256
fe80::/64 dev wlan1  proto kernel  metric 256
fe80::/64 dev wlan2  proto kernel  metric 256
fe80::/64 dev eth7  proto kernel  metric 256
fe80::/64 dev virts  proto kernel  metric 256
fe80::/64 dev vboxnet1  proto kernel  metric 256
fe80::/64 dev vboxnet0  proto kernel  metric 256
fe80::/64 dev eth0  proto kernel  metric 256
fe80::/64 via :: dev he-ipv6  proto kernel  metric 256
default dev he-ipv6  metric 1024
ip6tables-save output:

Code: [Select]

# Generated by ip6tables-save v1.4.12 on Tue Oct  9 22:48:08 2012
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [3024:253440]
:OUTPUT ACCEPT [10911:934608]
:ufw6-after-forward - [0:0]
:ufw6-after-input - [0:0]
:ufw6-after-logging-forward - [0:0]
:ufw6-after-logging-input - [0:0]
:ufw6-after-logging-output - [0:0]
:ufw6-after-output - [0:0]
:ufw6-before-forward - [0:0]
:ufw6-before-input - [0:0]
:ufw6-before-logging-forward - [0:0]
:ufw6-before-logging-input - [0:0]
:ufw6-before-logging-output - [0:0]
:ufw6-before-output - [0:0]
:ufw6-logging-allow - [0:0]
:ufw6-logging-deny - [0:0]
:ufw6-reject-forward - [0:0]
:ufw6-reject-input - [0:0]
:ufw6-reject-output - [0:0]
:ufw6-skip-to-policy-forward - [0:0]
:ufw6-skip-to-policy-input - [0:0]
:ufw6-skip-to-policy-output - [0:0]
:ufw6-track-input - [0:0]
:ufw6-track-output - [0:0]
:ufw6-user-forward - [0:0]
:ufw6-user-input - [0:0]
:ufw6-user-limit - [0:0]
:ufw6-user-limit-accept - [0:0]
:ufw6-user-logging-forward - [0:0]
:ufw6-user-logging-input - [0:0]
:ufw6-user-logging-output - [0:0]
:ufw6-user-output - [0:0]
-A INPUT -j ufw6-before-logging-input
-A INPUT -j ufw6-before-input
-A INPUT -j ufw6-after-input
-A INPUT -j ufw6-after-logging-input
-A INPUT -j ufw6-reject-input
-A INPUT -j ufw6-track-input
-A FORWARD -j ufw6-before-logging-forward
-A FORWARD -j ufw6-before-forward
-A FORWARD -j ufw6-after-forward
-A FORWARD -j ufw6-after-logging-forward
-A FORWARD -j ufw6-reject-forward
-A OUTPUT -j ufw6-before-logging-output
-A OUTPUT -j ufw6-before-output
-A OUTPUT -j ufw6-after-output
-A OUTPUT -j ufw6-after-logging-output
-A OUTPUT -j ufw6-reject-output
-A OUTPUT -j ufw6-track-output
-A ufw6-after-input -p udp -m udp --dport 137 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p udp -m udp --dport 138 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p tcp -m tcp --dport 139 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p tcp -m tcp --dport 445 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p udp -m udp --dport 67 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p udp -m udp --dport 68 -j ufw6-skip-to-policy-input
-A ufw6-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw6-before-forward -i vpner -j REJECT --reject-with icmp6-addr-unreachable
-A ufw6-before-forward -o vpner -j REJECT --reject-with icmp6-addr-unreachable
-A ufw6-before-forward -j ufw6-user-forward
-A ufw6-before-input -i lo -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 133 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -m state --state RELATED,ESTABLISHED -j ACCEPT
-A ufw6-before-input -m state --state INVALID -j ufw6-logging-deny
-A ufw6-before-input -m state --state INVALID -j DROP
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A ufw6-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw6-before-input -s ff00::/8 -p ipv6-icmp -j ACCEPT
-A ufw6-before-input -d ff00::/8 -p ipv6-icmp -j ACCEPT
-A ufw6-before-input -s ff00::/8 -p ipv6-icmp -j ACCEPT
-A ufw6-before-input -d ff00::/8 -p ipv6-icmp -j ACCEPT
-A ufw6-before-input -j ufw6-user-input
-A ufw6-before-output -o lo -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -m state --state RELATED,ESTABLISHED -j ACCEPT
-A ufw6-before-output -j ufw6-user-output
-A ufw6-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw6-logging-deny -m state --state INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw6-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw6-reject-input -j REJECT --reject-with icmp6-port-unreachable
-A ufw6-skip-to-policy-forward -j ACCEPT
-A ufw6-skip-to-policy-input -j REJECT --reject-with icmp6-port-unreachable
-A ufw6-skip-to-policy-output -j ACCEPT
-A ufw6-track-output -p tcp -m state --state NEW -j ACCEPT
-A ufw6-track-output -p udp -m state --state NEW -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 80 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 8887 -j ACCEPT
-A ufw6-user-input -p udp -m udp --dport 8887 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 53 -j ACCEPT
-A ufw6-user-input -p udp -m udp --dport 53 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 25 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 22 -j ACCEPT
-A ufw6-user-input -s 2001:470:e89d::/48 -p tcp -m tcp --dport 3142 -j ACCEPT
-A ufw6-user-input -s 2001:470:e89d::/48 -p tcp -m multiport --dports 135:139 -j ACCEPT
-A ufw6-user-input -s 2001:470:e89d::/48 -p tcp -m tcp --dport 445 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 3142 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 546 -j ACCEPT
-A ufw6-user-input -p udp -m udp --dport 546 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 547 -j ACCEPT
-A ufw6-user-input -p udp -m udp --dport 547 -j ACCEPT
-A ufw6-user-input -p udp -m udp --dport 67 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 10990 -j ACCEPT
-A ufw6-user-input -p udp -m udp --dport 10990 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 443 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 81 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 444 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 27061 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 27061 -m comment --comment "\'dapp_SymformContribution\'" -j ACCEPT
-A ufw6-user-output -p udp -m udp --sport 5353 --dport 5353 -j DROP
COMMIT
# Completed on Tue Oct  9 22:48:08 2012

ifconfig of all interfaces, he-ipv6 is the tunnel:

Code: [Select]

he-ipv6   Link encap:IPv6-in-IPv4 
          inet6 addr: fe80::c0a8:d01/64 Scope:Link
          inet6 addr: fe80::c0a8:701/64 Scope:Link
          inet6 addr: fe80::c0a8:601/64 Scope:Link
          inet6 addr: fe80::c0a8:901/64 Scope:Link
          inet6 addr: fe80::c0a8:7a01/64 Scope:Link
          inet6 addr: fe80::4126:397b/64 Scope:Link
          inet6 addr: fe80::c0a8:3901/64 Scope:Link
          inet6 addr: 2001:470:a:29f::2/64 Scope:Global
          UP POINTOPOINT RUNNING NOARP  MTU:1472  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1790 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:168900 (168.9 KB)

eth0      Link encap:Ethernet  HWaddr 00:1d:60:0d:7d:32 
          inet6 addr: fe80::21d:60ff:fe0d:7d32/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5174897 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3901144 errors:0 dropped:0 overruns:0 carrier:8
          collisions:0 txqueuelen:1000
          RX bytes:5138513483 (5.1 GB)  TX bytes:472369388 (472.3 MB)

eth7      Link encap:Ethernet  HWaddr 00:02:b3:ea:9a:b6 
          inet addr:192.168.7.1  Bcast:192.168.7.255  Mask:255.255.255.0
          inet6 addr: 2001:470:e89d:9ab6::1/64 Scope:Global
          UP BROADCAST PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth10     Link encap:Ethernet  HWaddr 00:22:b0:70:9e:07 
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:20

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:1310964 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1310964 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:187944008 (187.9 MB)  TX bytes:187944008 (187.9 MB)

mon.wlan1 Link encap:UNSPEC  HWaddr 1C-BD-B9-D5-E8-3C-00-00-00-00-00-00-00-00-00-00 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:433686 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:35568363 (35.5 MB)  TX bytes:0 (0.0 B)

ppp0      Link encap:Point-to-Point Protocol 
          inet addr:65.38.57.123  P-t-P:65.38.57.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:1226715 errors:0 dropped:0 overruns:0 frame:0
          TX packets:899822 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:1156405170 (1.1 GB)  TX bytes:86652021 (86.6 MB)

vboxnet0  Link encap:Ethernet  HWaddr 0a:00:27:00:00:00 
          inet6 addr: fe80::800:27ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:46084 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:2784592 (2.7 MB)

vboxnet1  Link encap:Ethernet  HWaddr 0a:00:27:00:00:01 
          inet addr:192.168.57.1  Bcast:192.168.57.255  Mask:255.255.255.0
          inet6 addr: fe80::800:27ff:fe00:1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:73356 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:4394330 (4.3 MB)

virbr0    Link encap:Ethernet  HWaddr 36:fd:75:be:7f:35 
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

virts     Link encap:Ethernet  HWaddr 0a:00:27:00:00:00 
          inet addr:192.168.13.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::7c12:70ff:fea7:b446/64 Scope:Link
          inet6 addr: 2001:470:e89d:d000::1/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:29933 errors:0 dropped:0 overruns:0 frame:0
          TX packets:30088 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1257403 (1.2 MB)  TX bytes:2762655 (2.7 MB)

wlan1     Link encap:Ethernet  HWaddr 1c:bd:b9:d5:e8:3c 
          inet addr:192.168.9.1  Bcast:192.168.9.255  Mask:255.255.255.0
          inet6 addr: fe80::1ebd:b9ff:fed5:e83c/64 Scope:Link
          inet6 addr: 2001:470:e89d:e83c::1/64 Scope:Global
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:406746 errors:0 dropped:0 overruns:0 frame:0
          TX packets:466314 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:44592140 (44.5 MB)  TX bytes:276449125 (276.4 MB)

wlan2     Link encap:Ethernet  HWaddr 1c:bd:b9:d5:e8:3d 
          inet addr:192.168.6.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::1ebd:b9ff:fed5:e83d/64 Scope:Link
          inet6 addr: 2001:470:e89d:a272::1/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:843193 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1030381 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:132651777 (132.6 MB)  TX bytes:998429566 (998.4 MB)

Not sure what else could/would be of help figuring this out.

[Azendale]

Attached is a wireshark packet capture from my PPPoE interface of me trying to ping the other end of the tunnel.

[kasperd]

I tried to do a traceroute to a 6to4 address derived from your IPv4 address, just to see if it would give any hints.

Code: [Select]

traceroute to 2002:4126:397b::65.38.57.123 (2002:4126:397b::4126:397b), 30 hops max, 80 byte packets
 1  2a01:d0:839a:babe:d33:9af8:143f:b164  0.146 ms  0.136 ms  0.164 ms
 2  ::ffff:65.38.57.123  235.054 ms !H  *  237.877 ms !H

[kasperd]

Attached is a wireshark packet capture from my PPPoE interface of me trying to ping the other end of the tunnel.

What capture filter did you use? There is only protocol 41 packets in the trace, and I would have expected to see some ICMP packets in there as well.

[Azendale]

I used 'not tcp port 27061' as a capture filter, I have a backup program running on 27061 that otherwise would give lots of encrypted traffic. The packet capture is only a few seconds and I tried to minimize other traffic while I was capturing.

I also did one that is a little less careful to avoid being cluttered with other stuff. It is on my ppp0 interface again with the 'not tcp port 27061' filter.

[kasperd]

I used 'not tcp port 27061' as a capture filter, I have a backup program running on 27061 that otherwise would give lots of encrypted traffic.

I don't think those TCP packets would have told us anything anyway.

I also did one that is a little less careful to avoid being cluttered with other stuff.

I noticed that your outgoing packets are from two seemingly unrelated prefixes. Do you have both a /64 and a /48?

I tried traceroute to both addresses, but both ended in the same place (which I think is the tunnel server).

The information you have provided so far provides no clues about which direction packets are being dropped. It could be either or both.

Can you try to ping these two addresses, then I can see if the requests reach me.
2001:470:28:940:a87:1a54:fe06:ea79
2002:50a7:dea9:727a:e66a:3911:c0de:6f98

[shadertest]

I have the same issue you're having. Can't recieve any packets but I can send them. Running traceroute6 to my tunnel shows:

Code: [Select]

traceroute to 2001:470:1c:428::2 (2001:470:1c:428::2) from 2600:3c03::f03c:91ff:fe93:192f, 30 hops max, 24 byte packets
 1  2600:3c03:ffff:0:8a43:e1ff:fea4:4ff (2600:3c03:ffff:0:8a43:e1ff:fea4:4ff)  35.345 ms  21.077 ms  7.428 ms
 2  Vlan479.esd1.mmu.nac.net (2001:518:2800:3::1)  0.702 ms  0.659 ms  0.393 ms
 3  Vlan801.tbr1.mmu.nac.net (2001:518:2001:3::1)  0.436 ms  0.326 ms  0.319 ms
 4  e1.1.tbr1.tl9.nac.net (2001:518:5001:3::1)  1.434 ms  1.409 ms  1.396 ms
 5  2001:518:5001:f::2 (2001:518:5001:f::2)  1.469 ms  1.431 ms  1.405 ms
 6  nyc.ipv6.he.net (2001:504:1::a500:6939:1)  3.05 ms  12.88 ms  1.85 ms
 7  10gigabitethernet4-2.core1.nyc4.he.net (2001:470:0:259::1)  7.071 ms  1.775 ms  2.27 ms
 8  10gigabitethernet1-2.core1.tor1.he.net (2001:470:0:23f::2)  12.745 ms  18.823 ms  12.982 ms
 9  ordns.he.net (2001:470:20::2)  14.116 ms  20.304 ms  14.214 ms

traceroute6 2001:470:a:29f::2 also ends with ordns.he.net.

[Azendale]

I noticed that your outgoing packets are from two seemingly unrelated prefixes. Do you have both a /64 and a /48?

Yes, I have a /48 routed to me in addition to the routed /64 you get with the tunnel and the /64 assigned to the tunnel.
So,
2001:470:a:29f::/64 Assigned to the tunnel, 2001:470:a:29f::1 is the server side, 2001:470:a:29f::2 is my end,
2001:470:b:29f::/64 Routed /64, mostly unused
2001:470:e89d::/48 Routed /48, used for most everything, 2001:470:e89d::1 used to be used as my end of the tunnel

Can you try to ping these two addresses, then I can see if the requests reach me.
2001:470:28:940:a87:1a54:fe06:ea79
2002:50a7:dea9:727a:e66a:3911:c0de:6f98

Sure. I just left ping running at a 15 second interval for both, hopefully that is fine.

[cholzhauer]

I didn't read real far back in this thread, but you did put a route for your /48 in your router, right?

[Azendale]

I didn't read real far back in this thread, but you did put a route for your /48 in your router, right?

I don't think I quite understand your question. But I'll try to answer it anyway. I put 2001:470:e89d::1/128 on my tunnel interface. The Ubuntu box the tunnel terminates on is my router, so I have put various /64's from the /48 on other interfaces.

Let me know if you need more info.

[cholzhauer]

Again, I may be on the wrong path here, but let me explain what I mean

You have 2001:db8:1234:5678::2 assigned to the tunnel interface on your router.  2001:db8:1234:5678::1 is assigned to the HE side of the tunnel.  

You then assign 2001:db8:abcd:ef::1 to your local interface on your router (this is taken from your 2001:db8:abcd/48 allotment from HE).  This tells the router about 2001:db8:abcd:ef::/64, but if you use 2001:db8:abcd:1::/64 somewhere behind your router, your router will have no idea where that subnet is and traffic intended for that network will never make it anywhere.

[kasperd]

Can you try to ping these two addresses, then I can see if the requests reach me.
2001:470:28:940:a87:1a54:fe06:ea79
2002:50a7:dea9:727a:e66a:3911:c0de:6f98

Sure. I just left ping running at a 15 second interval for both, hopefully that is fine.

The packets that you send do in fact reach me:

Code: [Select]

Received echo request from 2001:470:a:29f::2 via 216.66.80.90 to 2001:470:28:940:a87:1a54:fe06:ea79 ttl=53 len=56
Received echo request from 2001:470:a:29f::2 via 216.218.226.238 to 2002:50a7:dea9:727a:e66a:3911:c0de:6f98 ttl=62 len=56
I looked on tcpdump output as well, but that only showed me, that I was receiving ICMPv6 echo requests and that I send ICMPv6 echo replies back.

So with that I say it is confirmed that you can send IPv6 packets, but IPv6 packets from the tunnel server doesn't reach your tunnel endpoint. Did you already do an IPv4 traceroute from your computer to the tunnel server to verify that it was not a problem with the IPv4 connectivity?

It will help narrow down the problem, if you try to do some other protocol 41 traffic. Either try a tunnel through another tunnel server (possibly a different provider), or try to setup 6to4, to verify if the problem affects those as well.

[trmentry]

Hello

I'm having the same issue.  My tunnel was allowing me to get to v6 sites yesterday with no issues.  However this morning my router rebooted (openwrt).  Power loss.

Now my tunnel will pin up, but can't pass v6 traffic.   I see my traffic leave and head to HE, but I get nothing back.

This appears to be a HE issue.  As I can see my packets leave, but I don't get anything back.   But I had a friend sned me Proto41 packets to my wan address and they were accepted.

6in4 interface showing packets coming in from my desktop and going to www.google.com

Code: [Select]

root@geonosis /root# tcpdump -vvi 6in4-HE6in4 -n host  2001:470:d:d6a:b498:f5d1:af69:f9c4
tcpdump: WARNING: 6in4-HE6in4: no IPv4 address assigned
tcpdump: listening on 6in4-HE6in4, link-type RAW (Raw IP), capture size 65535 bytes
13:40:13.996690 IP6 (hlim 127, next-header ICMPv6 (58) payload length: 40) 2001:470:d:d6a:b498:f5d1:af69:f9c4 > 2001:4860:4007:801::1014: [icmp6 sum ok] ICMP6, echo request, seq 45
13:40:18.603856 IP6 (hlim 127, next-header ICMPv6 (58) payload length: 40) 2001:470:d:d6a:b498:f5d1:af69:f9c4 > 2001:4860:4007:801::1014: [icmp6 sum ok] ICMP6, echo request, seq 46
13:40:23.604202 IP6 (hlim 127, next-header ICMPv6 (58) payload length: 40) 2001:470:d:d6a:b498:f5d1:af69:f9c4 > 2001:4860:4007:801::1014: [icmp6 sum ok] ICMP6, echo request, seq 47
13:40:28.603641 IP6 (hlim 127, next-header ICMPv6 (58) payload length: 40) 2001:470:d:d6a:b498:f5d1:af69:f9c4 > 2001:4860:4007:801::1014: [icmp6 sum ok] ICMP6, echo request, seq 48
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

showing that i'm sending those packets to the LAX tserv15 .

Code: [Select]


root@geonosis /root# tcpdump -vvi pppoe-wan host 66.220.18.42 -n
tcpdump: listening on pppoe-wan, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
13:40:13.235172 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPv6 (41), length 162)
    174.26.213.93 > 66.220.18.42: IP6 (hlim 64, next-header UDP (17) payload length: 102) 2001:470:c:d6a::2.2706 > 2002:3ecb:2bc4:0:2c1d:a255:dbf4:aeaf.51413: [udp sum ok] UDP, length 94
13:40:13.996747 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPv6 (41), length 100)
    174.26.213.93 > 66.220.18.42: IP6 (hlim 127, next-header ICMPv6 (58) payload length: 40) 2001:470:d:d6a:b498:f5d1:af69:f9c4 > 2001:4860:4007:801::1014: [icmp6 sum ok] ICMP6, echo request, seq 45
13:40:16.012196 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPv6 (41), length 100)
    174.26.213.93 > 66.220.18.42: IP6 (hlim 127, next-header ICMPv6 (58) payload length: 40) 2001:470:d:d6a::6 > 2001:4860:4007:801::1014: [icmp6 sum ok] ICMP6, echo request, seq 51198
13:40:18.603910 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPv6 (41), length 100)
    174.26.213.93 > 66.220.18.42: IP6 (hlim 127, next-header ICMPv6 (58) payload length: 40) 2001:470:d:d6a:b498:f5d1:af69:f9c4 > 2001:4860:4007:801::1014: [icmp6 sum ok] ICMP6, echo request, seq 46
13:40:22.263528 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPv6 (41), length 100)
    174.26.213.93 > 66.220.18.42: IP6 (hlim 127, next-header ICMPv6 (58) payload length: 40) 2001:470:d:d6a::6 > 2001:4860:4007:801::1014: [icmp6 sum ok] ICMP6, echo request, seq 51199
13:40:22.305958 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPv6 (41), length 162)
    174.26.213.93 > 66.220.18.42: IP6 (hlim 64, next-header UDP (17) payload length: 102) 2001:470:c:d6a::2.2706 > 2002:3ecb:2bc4:0:2c1d:a255:dbf4:aeaf.51413: [udp sum ok] UDP, length 94
13:40:23.604261 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPv6 (41), length 100)
    174.26.213.93 > 66.220.18.42: IP6 (hlim 127, next-header ICMPv6 (58) payload length: 40) 2001:470:d:d6a:b498:f5d1:af69:f9c4 > 2001:4860:4007:801::1014: [icmp6 sum ok] ICMP6, echo request, seq 47
13:40:28.371768 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPv6 (41), length 100)
    174.26.213.93 > 66.220.18.42: IP6 (hlim 127, next-header ICMPv6 (58) payload length: 40) 2001:470:d:d6a::6 > 2001:4860:4007:801::1014: [icmp6 sum ok] ICMP6, echo request, seq 51200
13:40:28.603692 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPv6 (41), length 100)
    174.26.213.93 > 66.220.18.42: IP6 (hlim 127, next-header ICMPv6 (58) payload length: 40) 2001:470:d:d6a:b498:f5d1:af69:f9c4 > 2001:4860:4007:801::1014: [icmp6 sum ok] ICMP6, echo request, seq 48
13:40:34.439390 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto IPv6 (41), length 100)
    174.26.213.93 > 66.220.18.42: IP6 (hlim 127, next-header ICMPv6 (58) payload length: 40) 2001:470:d:d6a::6 > 2001:4860:4007:801::1014: [icmp6 sum ok] ICMP6, echo request, seq 51201
^C
10 packets captured
11 packets received by filter
0 packets dropped by kernel


and my buddy sending me proto41 packets and me accepting them.  his command that he ran from his side
sudo nmap -PO41 -p80 174.26.213.93

Code: [Select]

root@geonosis /root# tcpdump -vvi pppoe-wan "proto ipv6 && host 70.176"
tcpdump: listening on pppoe-wan, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
14:18:46.906088 IP (tos 0x0, ttl 34, id 13489, offset 0, flags [none], proto IPv6 (41), length 20)
    ip70-176-.ph.ph.cox.net > 174-26-213-93.phnx.qwest.net: [|ip6]
14:18:47.905629 IP (tos 0x0, ttl 41, id 46683, offset 0, flags [none], proto IPv6 (41), length 20)
    ip70-176-.ph.ph.cox.net > 174-26-213-93.phnx.qwest.net: [|ip6]

I have emailed support, but was curious if there is a known issue with the LAX tserv15 currently.   My friend is using Freemont and not having issues.

THanks

[trmentry]

Just got a reply from Support.

They rebuilt my tunnel and now things are working.   Unclear if something was wedged on the server or not.  They told me that my v4 address didn't make it to the tunnel server.  But tunnelbroker.net showed it being updated by my router. 

Things are working now without issue since the rebuild.

Code: [Select]

$ ping6 www.google.com -c4
PING www.google.com(lax04s09-in-x10.1e100.net) 56 data bytes
64 bytes from lax04s09-in-x10.1e100.net: icmp_seq=1 ttl=58 time=33.7 ms
64 bytes from lax04s09-in-x10.1e100.net: icmp_seq=2 ttl=58 time=34.0 ms
64 bytes from lax04s09-in-x10.1e100.net: icmp_seq=3 ttl=58 time=35.0 ms
64 bytes from lax04s09-in-x10.1e100.net: icmp_seq=4 ttl=58 time=35.0 ms

--- www.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3017ms
rtt min/avg/max/mdev = 33.735/34.458/35.044/0.590 ms


[kasperd]

They told me that my v4 address didn't make it to the tunnel server.  But tunnelbroker.net showed it being updated by my router. 

Things are working now without issue since the rebuild.

And I can ping 2001:470:a:29f::2 now, so it looks like you were both affected by the same problem.

Just before your update I did write a followup suggesting to try changing the IPv4 address back and forth to see if that would help, but somehow that comment got lost. (WIFI dropped my connection while sending it, and when I resubmitted the forum told me it had been submitted already).