Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Pages: 1 ... 3 4 [5] 6 7 ... 10
 41 
 on: October 05, 2020, 02:21:00 PM 
Started by ajyip6 - Last post by ajyip6
My tunnel does work... but not enough to actually be useful!

First problem: outgoing pings often don't work until I've had an incoming ping

I can ping other sites, but the ping doesn't work until I do an incoming ping. So

ajy@seth:~ $ ping6 ip6only.me
PING ip6only.me(2604:90:1:1::69 (2604:90:1:1::69)) 56 data bytes
Nothing happens, until a differennt OS goes to something like https://ip6now.com.au/pingme.pgp and does a ping6 to test6a.pcpki.com. Suddenly ICMPv6 responses received
64 bytes from 2604:90:1:1::69 (2604:90:1:1::69): icmp_seq=56 ttl=58 time=85.1 ms
64 bytes from 2604:90:1:1::69 (2604:90:1:1::69): icmp_seq=57 ttl=58 time=83.7 ms
64 bytes from 2604:90:1:1::69 (2604:90:1:1::69): icmp_seq=58 ttl=58 time=131 ms
64 bytes from 2604:90:1:1::69 (2604:90:1:1::69): icmp_seq=59 ttl=58 time=83.1 ms
64 bytes from 2604:90:1:1::69 (2604:90:1:1::69): icmp_seq=60 ttl=58 time=82.8 ms
^C
--- ip6only.me ping statistics ---
60 packets transmitted, 5 received, 91.6667% packet loss, time 260ms
rtt min/avg/max/mdev = 82.810/93.077/130.612/18.787 ms



Second problem: The TCP handshake works, but not subsequent packets

ajy@seth:~ $ wget -O - ip6only.me
--2020-10-04 22:59:34--  http://ip6only.me/
Resolving ip6only.me (ip6only.me)... 2604:90:1:1::69
Connecting to ip6only.me (ip6only.me)|2604:90:1:1::69|:80... connected.
HTTP request sent, awaiting response... ^C


ajy@seth:~ $ sudo grep "he-ipv6" /var/log/syslog | tail
Oct  4 22:59:34 seth kernel: [1125389.716751] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=80 TC=0 HOPLIMIT=64 FLOWLBL=481646 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821190 ACK=0 WINDOW=65320 RES=0x00 SYN URGP=0
Oct  4 22:59:34 seth kernel: [1125389.798757] 6X: IN=he-ipv6 OUT= TUNNEL=216.66.80.26->192.168.1.132 SRC=2604:0090:0001:0001:0000:0000:0000:0069 DST=2001:0470:1f08:0445:0000:0000:0000:0002 LEN=80 TC=6 HOPLIMIT=58 FLOWLBL=149549 PROTO=TCP SPT=80 DPT=36740 SEQ=3127003181 ACK=1827821191 WINDOW=65535 RES=0x00 ACK SYN URGP=0
Oct  4 22:59:34 seth kernel: [1125389.799060] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=72 TC=0 HOPLIMIT=64 FLOWLBL=481646 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821191 ACK=3127003182 WINDOW=1021 RES=0x00 ACK URGP=0
>>>>TCP handshake complete. The next line is the GET, which is sent four times (ip6tables at the server end of other servers show it is not arriving)
Oct  4 22:59:34 seth kernel: [1125389.805883] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=215 TC=0 HOPLIMIT=64 FLOWLBL=481646 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821191 ACK=3127003182 WINDOW=1021 RES=0x00 ACK PSH URGP=0
Oct  4 22:59:34 seth kernel: [1125390.101358] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=215 TC=0 HOPLIMIT=64 FLOWLBL=481646 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821191 ACK=3127003182 WINDOW=1021 RES=0x00 ACK PSH URGP=0
Oct  4 22:59:34 seth kernel: [1125390.401375] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=215 TC=0 HOPLIMIT=64 FLOWLBL=656684 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821191 ACK=3127003182 WINDOW=1021 RES=0x00 ACK PSH URGP=0
Oct  4 22:59:35 seth kernel: [1125390.991395] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=215 TC=0 HOPLIMIT=64 FLOWLBL=561891 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821191 ACK=3127003182 WINDOW=1021 RES=0x00 ACK PSH URGP=0
Now a FIN is sent - the sending seems to be timing out very aggressively
Oct  4 22:59:36 seth kernel: [1125391.903617] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=72 TC=0 HOPLIMIT=64 FLOWLBL=561891 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821334 ACK=3127003182 WINDOW=1021 RES=0x00 ACK FIN URGP=0
Now the server ACKs the third part of the TCP handshake
Oct  4 22:59:36 seth kernel: [1125391.986074] 6X: IN=he-ipv6 OUT= TUNNEL=216.66.80.26->192.168.1.132 SRC=2604:0090:0001:0001:0000:0000:0000:0069 DST=2001:0470:1f08:0445:0000:0000:0000:0002 LEN=72 TC=0 HOPLIMIT=58 FLOWLBL=149549 PROTO=TCP SPT=80 DPT=36740 SEQ=3127003182 ACK=1827821191 WINDOW=1036 RES=0x00 ACK URGP=0
LEN=215 implies this is the GET sent again, with a PSH
Oct  4 22:59:36 seth kernel: [1125392.181473] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002
DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=215 TC=0 HOPLIMIT=64 FLOWLBL=168171 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821191 ACK=3127003182 WINDOW=1021 RES=0x00 ACK PSH FIN URGP=0
ACK=1827821335 looks like the 215 bytes are being ACKed, so they have got through but we've already sent a FIN, and so the second part of the FIN is sent
Oct  4 22:59:36 seth kernel: [1125392.283874] 6X: IN=he-ipv6 OUT= TUNNEL=216.66.80.26->192.168.1.132 SRC=2604:0090:0001:0001:0000:0000:0000:0069 DST=2001:0470:1f08:0445:0000:0000:0000:0002 LEN=72 TC=0 HOPLIMIT=58 FLOWLBL=149549 PROTO=TCP SPT=80 DPT=36740 SEQ=3127005542 ACK=1827821335 WINDOW=1036 RES=0x00 ACK FIN URGP=0
RST sent...
Oct  4 22:59:36 seth kernel: [1125392.284224] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=60 TC=0 HOPLIMIT=64 FLOWLBL=290854 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821335 ACK=0 WINDOW=0 RES=0x00 RST URGP=0


/etc/network/interfaces.d/he-ipv6 is
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
        address 2001:470:1f08:445::2
        netmask 64
        mtu 1480
        endpoint 216.66.80.26
        local 192.168.1.132
        ttl 255
        gateway 2001:470:1f08:445::1
        dns-nameservers 2001:4860:4860::8888


This all worked OK when I was using a Slax (3.6.11 kernel) endpoint through a standard PlusNet DSL router. Currently I am using a Raspbian (Debian Buster) Paspberry Pi sitting in the DMZ of a BT Hub 6 (I am still with PlusNet, so don't have native IPv6)

It seems to me so close to be working - I have bidirectional traffic - but with some wierdness.

Any suggestions gratefully received.

Andy

 42 
 on: October 04, 2020, 10:52:05 PM 
Started by mclovin - Last post by mclovin
My home router has a public IP and does NAT.

The IPv6 tunnels use protocol 41 which can't be used with (many-to-one) NAT since protocol 41 doesn't use port numbers in the outer packet. (One-to-one NAT should work if it's supported in the router and can be configured for protocol 41.)
I think the router does NAT based only on the (source IP, destination IP) tuple.

Which router do you have?
Inteno EG400. I think it runs a modified OpenWRT.

 43 
 on: October 04, 2020, 06:57:55 PM 
Started by mclovin - Last post by cholzhauer
Which router do you have?

 44 
 on: October 04, 2020, 03:31:48 PM 
Started by mclovin - Last post by mikma
My home router has a public IP and does NAT.

The IPv6 tunnels use protocol 41 which can't be used with (many-to-one) NAT since protocol 41 doesn't use port numbers in the outer packet. (One-to-one NAT should work if it's supported in the router and can be configured for protocol 41.)

 45 
 on: October 04, 2020, 01:43:07 PM 
Started by mclovin - Last post by mclovin
My IPv6 tunnel recently stopped working. I can PING, but TCP connections hangs. The tunnel works if I change the endpoint to my server. If I create a tunnel between my home computer and the server, I get the same problem. Thus I think it's a problem with my ISP provided home router. When I receive TCP packets (usually the SYN-ACK response) thru the tunnel, wireshark complains "Expert Info (Error/Malformed): Bogus IPv6 version" because the first 4 bytes of the IPv6 header have been zeroed! I tracerouted from my server to my home computer with one of the packets that gets corrupted, and all the routers including my home router have the correct header in the ICMP reply, so I think the corruption happens inside my network. My home router has a public IP and does NAT. There is no CGNAT.

Does anyone know why my router would do this? I thought it might be NAT trying to rewrite the TCP checksum, and assuming that the TCP header directly follows the IPv4 header, but it's the wrong offset and size. If the router assumes that the TCP header directly follows the IPv4 header, it tries to set source and destination port to zero, which doesn't make sense?

 46 
 on: October 01, 2020, 03:01:18 PM 
Started by leshniak - Last post by leshniak
Hey,

just for curiousity - do you have any point in the future from which you'll start to think that it's time to sunset the service? For example reaching 90% of the global IPv6 adoption?

I'm very pleased with your services. I want to thank you for your amazing job and being my window to the IPv6 world ;)

 47 
 on: September 26, 2020, 03:54:51 PM 
Started by broquea - Last post by Zane Reick
I'm actually building my own company and want to provide all sorts of technology services, and in order to do that I need to be dual stack enabled (I am, but my ISP, Century Link, is not). So I built out my first tunnel, got it fully working, then completed the IPv6 certification program, and now I am building out Mobile IPv6 routers that can drop onto any network, update their tunnel end-point, and connect to the IPv6 network with their own firewall! I'll have 4 of these and they will be pretty handy for building out our initial POPs!

Thank you HE team for building this amazing tool, and the IPv6 certification program! It has really helped kick-start the back-end mess of Unknown Technology Solutions!

As always, if anyone has any questions, I'd love to answer them, so feel free to ask me however!

 48 
 on: September 25, 2020, 03:21:03 PM 
Started by j296 - Last post by j296
Thanks for the quick reply.  Btw, some of the IPs and names in the original post were anonymized.

I ran mtr from outside in, and it sees losses of 1 to 8% ofver all the hops.  I see 60^ loss on the tserv15.lax1 hop,a dn also 60% at hops near the destination.  Here is tracing to google:

 2. tunnel201234.tunnel.tserv15.lax1 60.0%   336   15.1  30.0  13.5 192.7  33.2
 3. 10ge9-12.core1.lax1.he.net        1.8%   336  128.7  29.1  12.0 172.5  33.7
 4. 100ge14-1.core1.lax2.he.net       2.1%   336   13.3  34.9  12.1 430.9  44.3
 5. 2001:504:13::210:41               2.4%   336   12.4  26.4  12.4 181.5  28.8
 6. 2001:4860:0:110d::1              57.6%   336   54.3  26.4  12.5 161.8  25.4
 7. 2001:4860:0:1::430f              77.3%   336   24.9  28.1  13.4 146.2  30.2
 8. lax31s06-in-x04.1e100.net         2.4%   336   33.5  25.7  11.1 172.9  31.0

vs. in (from a different far side, not google)

 1. 2001:1878:400::                  1.7%   466    0.5   0.3   0.2  13.0   0.6
 2. 2001:1878:18:5::3                 9.9%   466    1.2   1.2   1.1   2.7   0.3
 3. ve338.core1.lax2.he.net           1.7%   466    0.9   3.7   0.9  49.0   8.6
 4. 100ge2-2.core1.lax1.he.net        1.7%   466    1.0   3.3   0.9 453.2  24.0
 5. tserv1.lax1.he.net                2.1%   465    4.7  19.7   3.5 171.9  34.1
 6. ???
 7. me        4.7%   465   55.8  36.7  12.4 181.9  42.4

I'm not really sure how to use mtr to tell which side has the loss, unfortunately.

 49 
 on: September 25, 2020, 03:07:24 PM 
Started by j296 - Last post by broquea
The PL didn't continue next hop, its 0% until the destination. Might have loss on the return path or an issue itself at the destination.

 50 
 on: September 25, 2020, 02:33:41 PM 
Started by j296 - Last post by j296
I'm seeing 60% packet loss at tserv15.lax1.  That's... fairly unpleasant.
Does anyone else see this kind of problem?


                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2001:470:d:aaa::1                 0.0%    30    0.7   0.7   0.6   0.9   0.1
 2. tunnel201234.tunnel.tserv15.lax1 60.0%    30   17.0  30.3  15.2 129.7  32.3
 3. 10ge9-12.core1.lax1.he.net        0.0%    30   30.2  31.6  12.6 141.4  34.5
 4. 100ge14-1.core1.lax2.he.net       0.0%    30  134.0  50.2  12.6 216.5  54.3
 5. 2001:470:1:4a0::2                 0.0%    30   43.8  22.6  12.2 102.6  19.5
 6. 2001:1878:0:2::3                 20.7%    29   16.5  27.3  13.5 115.0  26.8

Pages: 1 ... 3 4 [5] 6 7 ... 10