mnathani: install? it was already included with my weechat-plugins package, so very easy :P Loading was easy too: /python load /path/to/blah.py Aaaaand that's all it took I configured it a bit, set a static port number, a prefix, but otherwise nothing fancy and it worked right out of gthe box. neat. i'll give it a shot when i have a sec to mess with it. (been chatting via ssh on my eyepahd) I am having issues with my he.net ipv6 tunnel configured on an Ubuntu box I can ping6 google.com, but traceroute6 to the same host results in 0.654 ms !H 0.679 ms !H 0.708 ms !H ipv6 forwarding is enabled and I can traceroute to a machine using the ubuntu box as its ipv6 router How can I determine if its a firewall issue or perhaps a misconfiguration? hm that looks weird. do you have the full traceroute6 output? how far does it get before it stops? meingtsla: >> http://pastebin.com/eWmehyqH but ping6 works though, right? hmmm.... are you doing any udp blocking in ip6tables? don't think so ping6 does work root@x61:~# ping6 -n google.com mnathani: Just to check - disable ip6tables entirely PING google.com(2404:6800:4002:802::1001) 56 data bytes 64 bytes from 2404:6800:4002:802::1001: icmp_seq=1 ttl=50 time=346 ms awfully high pings though root@x61:~# ufw disable Firewall stopped and disabled on system startup brycec: I ran iptables -F and iptables -F -t nat what about ip6tables iptables is ipv4 no dice I flushed ip6tables rules also this is one of the clients behind the ubuntu box >> 2001:470:1d:76e::2:2 I can mtr to that IP about 70ms I think it might have something to do with the ubuntu box using a private IP that is not getting translated correctly through the NAT / ipv6 tunnel What's a private IPv6 IP? link-local? I mean my private ipv4 ip the packets go out, but get lost in translation on the way back is my theory I must not have understood your original problem... Thought we were talking v6-v6 he.net ipv6 tunnel protocol 41, 6in4 mnathani: if I can mtr to that v6 address, then your tunnel is good Assuming that v6 address was on your end of the tunnel Then the tunnel and its v4 underpinnings are working, packets in both directions. that v6 was actually part of a routed /64 behind the tunnel not sure why the traceroute6 was not working As far as v6 clients behind the tunnel, they never see the tunnel packets themselves, so private IPs have no bearing. Your "LAN" for lack of a better description is pure IPv6, it's just the router that takes the pure v6 and stuffs it over a tunnel. (pure IPv6/dualstack) (That IP is still being mtr'd too, so tcpdump and you'll see the traffic from an a650 address) 17:15:18.163599 IP6 vps3.cobryce.com > 2001:470:1d:76e::2:2: ICMP6, echo request, seq 59572, length 64 Yep 1. 2001:470:1d:76e::10:62 84.6% 14 0.3 0.3 0.3 0.3 0.0 mtr back to you http://sprunge.us/OTTB (it's wide, sorry) http://pastebin.com/yMCrE9Gg mnathani: so you're dropping 85% of your packets on your first hop alone? down to 30% now but yes for some reason mnathani: so that's an mtr running on ::2:2 right? [root@compaq capture]# ping6 2001:470:1d:76e::10:62 PING 2001:470:1d:76e::10:62(2001:470:1d:76e::10:62) 56 data bytes 64 bytes from 2001:470:1d:76e::10:62: icmp_seq=1 ttl=64 time=0.175 ms yes mnathani: So why is ::10:62 the gateway for ::2:2? Based on my inbound mtr, :;2:2 is routeable directly from ::2 (your endpoint) Server IPv6 Address:2001:470:1c:76e::1/64 Client IPv6 Address:2001:470:1c:76e::2/64 Routed /64:2001:470:1d:76e::/64 1c vs 1d you mean 1d/1e? nevermind ^ Anyways, my question stands, my inbound mtr hits 2001:470:1c:76e::2 and then the destination 2001:470:1d:76e::2:2 There's no 2001:470:1d:76e::10:62 anywhere in the inbound mtr So I presume you've set that as ::2:2's gateway, hence why its outbound mtr tries to route through it (badly) Destination Next Hop Flags Metric Ref Use Iface */0 2001:470:1d:76e::10:62 UG 1 10608 0 eth0 10:62 is the ubuntu box terminating the tunnel that route is on 2:2 So somehow inbound traffic skips that ubuntu box well that box has 2 ips it has :2001:470:1c:76e::2 on the tunnel end It has both ::2:2 and ::10:62? Oh okay (I meant to write ::2, not ::2:2) and 10:62 on th LAN end The same subnet on two interfaces? different subnets 470:1c vs 470:1d don't know why he.net chose such close /64s Heh, okay I can see the picture clearly now and fwiw I can mtr 2001:470:1d:76e::10:62 just fine too I am using a bridge interface for ipv6, does that change anything? Should be fine And if it were an MTU issue, small pings should still be fine 23411.808529fe80::21d:72ff:fe8c:c519ff02::1:ff00:1ICMPv686Neighbor Solicitation for 2001:470:1d:76e::1 from 00:1d:72:8c:c5:19 it got kinda squished there http://pastebin.com/W512MDZj I seem to be missing a next hop Is x61 the ubuntu router? it is You do. Gotta love when stuff works (or half-works) when it doesn't seem like it should work at all... [root@compaq capture]# ping6 google.com PING google.com(pd-in-x71.1e100.net) 56 data bytes 64 bytes from pd-in-x71.1e100.net: icmp_seq=1 ttl=53 time=69.8 ms 64 bytes from pd-in-x71.1e100.net: icmp_seq=2 ttl=53 time=70.1 ms 64 bytes from pd-in-x71.1e100.net: icmp_seq=3 ttl=53 time=69.2 ms I mean how can we explain that ^ MAGIC Clearly x61 put the packets on the wire, and somehow, by magic, HE slurped them up and routed them Oh right, MAGIC == ICMP6 router solicitation Your box was even doing an ND request │14:41:16 mnathani | 23411.808529fe80::21d:72ff:fe8c:c519ff02::1:ff00:1ICMPv686Neighbor Solicitation for 2001:470:1d:76e::1 from 00:1d:72:8c:c5:19 Granted, you might think such a route would show in the kernel routing table... finally!!! root@x61:~# traceroute6 google.com traceroute to google.com (2800:3f0:4002:801::1007) from 2001:470:1c:76e::2, 30 hops max, 24 byte packets 1 mnathani-1.tunnel.tserv21.tor1.ipv6.he.net (2001:470:1c:76e::1) 13.642 ms 12.51 ms 12.374 ms 2 ge2-5.core1.tor1.he.net (2001:470:0:c0::1) 12.204 ms 20.327 ms 9.21 ms 3 2001:478:245:1::6 (2001:478:245:1::6) 10.333 ms 10.331 ms 11.015 ms 4 2001:4860::1:0:28 (2001:4860::1:0:28) 11.455 ms 28.471 ms 15.783 ms 5 2001:4860::8:0:4398 (2001:4860::8:0:4398) 23.643 ms 26.754 ms 23.326 ms 6 2001:4860::8:0:6375 (2001:4860::8:0:6375) 30.327 ms 30.09 ms 29.767 ms 7 2001:4860::1:0:9ff (2001:4860::1:0:9ff) 38.428 ms 31.84 ms 40.867 ms 8 2001:4860::1:0:69e7 (2001:4860::1:0:69e7) 180.457 ms 186.376 ms 178.459 ms 9 2001:4860::1:0:e (2001:4860::1:0:e) 208.799 ms 198.93 ms 197.848 ms 10 2001:4860:0:1::d8 (2001:4860:0:1::d8) 199.453 ms 196.398 ms 199.431 ms 11 2800:3f0:4002:801::4 (2800:3f0:4002:801::4) 197.8 ms 196.636 ms 195.845 ms If only I had noticed and used the provided configuration from he.net directly