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:
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:
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:
# 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:
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.
Attached is a wireshark packet capture from my PPPoE interface of me trying to ping the other end of the tunnel.
I tried to do a traceroute to a 6to4 address derived from your IPv4 address, just to see if it would give any hints.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
Quote from: Azendale on October 09, 2012, 10:57:36 PMAttached 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.
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.
Quote from: Azendale on October 10, 2012, 06:52:18 AMI 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.
Quote from: Azendale on October 10, 2012, 06:52:18 AMI 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
I have the same issue you're having. Can't recieve any packets but I can send them. Running traceroute6 to my tunnel shows:
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.
Quote from: kasperd on October 10, 2012, 07:17:20 AM
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
Quote from: kasperd on October 10, 2012, 07:17:20 AM
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.
I didn't read real far back in this thread, but you did put a route for your /48 in your router, right?
Quote from: cholzhauer on October 11, 2012, 06:52:00 AM
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.
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.
Quote from: Azendale on October 11, 2012, 06:50:57 AM
Quote from: kasperd on October 10, 2012, 07:17:20 AM
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:
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.
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
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 .
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
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
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.
$ 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
Quote from: trmentry on October 11, 2012, 03:28:20 PMThey 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).
I don't know for sure what happened, but I wrote ipv6@he.net before I left for work this morning, and they wrote me back saying please retest a few hours later. After that, the tunnel just started working.
I did have unassigned parts of my /48 picked up by the default route and therefore going in a routing loop (which was a totally separate problem). Fixed that also. Cholzhauer mentioned this, but I didn't get it at first. So, now not only is my problem fixed, it's working better than before. :)