Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Pages: 1 2 [3] 4 5 ... 10
 21 
 on: October 07, 2020, 04:11:58 AM 
Started by ajyip6 - Last post by tomkep
I'll just comment to one observation you made:

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

The fact that you have "empty" tcp packets through and not seeing the ones carrying payload may indicate problems with either incorrect MTU setting somewhere in your setup or PATH MTU DISCOVERY along the way.

Please make sure MTU on your WAN interface is correct (for whatever media end encapsulation you use) and that the tunnel interface MTU is correctly calculated from the previous one (usually this means it should be 20 bytes smaller to account for encapsulating IPv4 header). Please also make sure that MTU setting on tunnel server (you have it in advanced settings) is matching or smaller than your MTU.

PATH MTU DISCOVERY problems usually indicate overzealous FW dropping ICMPv6 packet too big messages somewhere. This may be you - which you should be able to fix after inspecting FW rules, or someone else - then forcing PMTU to lower value (you may have to experiment) for specific network(s) in Linux MANGLE tables is probably the only cure you have at hand (short of complaining to relevant network administrator if you can identify the offending node).

Of course you can also try to lower MTU on your IPv6 interfaces to 1280 bytes (mandated by RFC) and this is the shortest path to solution for abovementioned issues - at some performance cost.

 22 
 on: October 06, 2020, 04:27:23 PM 
Started by ajyip6 - Last post by ajyip6
An observation in the attached image (which HE won't let me attach, but I hope you get the drift)...

  • I did nc -6lp 8989 on a server that is LAN-side of the endpoint
  • I did wget http://test6a.pcpki.com:8989/test on a Vultr VM on the Internet
  • The wget end outputed its normal audit trail until "HTTP request sent, awaiting response..."
  • Nothing appeared on the screen of the nc end until I pressed control-C on the wget end. The http request appears on the nc's terminal as soon as the client wget terminates.
  • If I do the same with IPv4, the http request appears immediately
  • Similarly, normal nc-to-nc pipes work normally for IPv4 (output appears when I press return) but for IPv6 the output doesn't appear at the server end until the client terminates

So I do have two way traffic. But something is wrong and it is driving me potty. Does this observation mean anything to anyone?

Andy

 23 
 on: October 06, 2020, 02:52:17 PM 
Started by ajyip6 - Last post by ajyip6
Good question. My local ip[6]tables log everything before they do their stuff, so I am confident it is not them.

The Smarthub security was set to "allow outgoing, block unsolicited incoming" with the endpoint in the DMZ where (I thought) everything else incoming was sent and I could filter it. I have changed it to "disabled", and the first problem above seems to have gone away. So this means that something that wasn't getting in to the DMZ with the first settings is getting through with the second. Not sure what. So as long as I pay extra attention to security of my endpoint then fingers crossed that is OK.

To eliminate variables, I went back to having a virtual Slax in the DMZ as the endpoint, and configured it exactly as before (I had screenshotted it) when it had worked. The second problem still exists - the TCP connection is made but nothing application layer can then be sent along it. The smarthub now appears to be the only difference.

My suspicion is that it is a timing issue rather than a routing issue, but I can't think how to diagnose it

Andy

 24 
 on: October 06, 2020, 05:22:21 AM 
Started by ajyip6 - Last post by cholzhauer
I have no specific suggestions for you, other than to ask if there's a firewall in play here? If so, could you turn off for testing and see what you get?

 25 
 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

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

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

 28 
 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.)

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

 30 
 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 ;)

Pages: 1 2 [3] 4 5 ... 10