• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

I can ping IPv6 addresses over my tunnel, but I am unable to browse websites

Started by ravenscroft, November 10, 2013, 03:27:49 PM

Previous topic - Next topic

ravenscroft

I have configured and setup an IPv6 tunnel using the HE tunnelbroker service.

I have a static public IP and followed these instructions:
http://wiki.mikrotik.com/wiki/Setting_up_an_IPv6_tunnel_via_a_tunnel_broker
http://wiki.mikrotik.com/wiki/Manual:My_First_IPv6_Network

I am able to ping websites via IPv6 on my Windows 8.1 workstation:

QuotePinging ipv6.he.net [2001:470:0:64::2] with 32 bytes of data:
Reply from 2001:470:0:64::2: time=298ms
Reply from 2001:470:0:64::2: time=302ms
Reply from 2001:470:0:64::2: time=294ms
Reply from 2001:470:0:64::2: time=309ms

Ping statistics for 2001:470:0:64::2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 294ms, Maximum = 309ms, Average = 300ms

Testing on http://test-ipv6.com/ gives me a score of 9/10 and shows that I have IPv6 connectivity.

I can browse to http://ipv6.google.com without problems.  http://www.ipv6chicken.com/ loads and shows that I have IPv6.

However, when I browse other IPv6 enabled sites, it takes extremely long and then I get a timeout error in my browser.

Examples of sites that will not load:
http://www.opendns.com
http://ipv6.he.net/
http://www.whatismyipv6.com/

(The latter site sometimes loads, but it does not load completely.)

When I ping the above it resolves to an IPv6 address, so DNS is working.

I am able to ping myself (my workstation) using my IPv6 address from services such as the HE Looking Glass.

I have tried Internet Explorer, FireFox and Chrome.

I have run out of troubleshooting ideas and would appreciate any suggestions / feedback.

kasperd

My gut feeling says this is probably because PMTU discovery is somehow broken in your setup.

Did I understand correctly, that your tunnel endpoint is on a router, which talks native IPv6 with the computer, where your browser is running? What sort of connectivity do you have between the router and the internet?

If your router can be configured to reduce the MSS on all SYN packets going through the router, then that should solve the majority of MTU problems.

ravenscroft

Thanks kasperd.

I think your gut feeling is correct.

QuoteDid I understand correctly, that your tunnel endpoint is on a router, which talks native IPv6 with the computer, where your browser is running? What sort of connectivity do you have between the router and the internet?

Yes - your understanding is correct.  I have a 4Mbps 1:1 symmetric connection via a local WISP.

QuoteIf your router can be configured to reduce the MSS on all SYN packets going through the router, then that should solve the majority of MTU problems.

NOTE: I am a complete noob when it comes to mtu...  I did the following, but I'm not sure if this is 100% correct.

Using ping on a workstation I determined that the largest packet I can reliably send via ipv6 is 1232:
Quote
C:\Users>ping www.google.com -l 1232

Pinging www.google.com [2607:f8b0:4000:803::1014] with 1232 bytes of data:
Reply from 2607:f8b0:4000:803::1014: time=302ms
Reply from 2607:f8b0:4000:803::1014: time=289ms
Reply from 2607:f8b0:4000:803::1014: time=303ms
Reply from 2607:f8b0:4000:803::1014: time=307ms

Ping statistics for 2607:f8b0:4000:803::1014:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 289ms, Maximum = 307ms, Average = 300ms

C:\Users>ping www.google.com -l 1233

Pinging www.google.com [2607:f8b0:4000:803::1014] with 1233 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 2607:f8b0:4000:803::1014:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users>ping ipv6.he.net -l 1280

Pinging ipv6.he.net [2001:470:0:64::2] with 1280 bytes of data:
Reply from 2001:470:0:64::2: time=313ms
Reply from 2001:470:0:64::2: time=305ms
Reply from 2001:470:0:64::2: time=308ms
Reply from 2001:470:0:64::2: time=305ms

Ping statistics for 2001:470:0:64::2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 305ms, Maximum = 313ms, Average = 307ms

C:\Users>

Based on that, I did the following in the mangle section of my IPv6 firewall on the router:


/ipv6 firewall mangle
add action=change-mss chain=forward in-interface=sit1 new-mss=1232 protocol=\
    tcp tcp-flags=syn tcp-mss=1411-65535
add action=change-mss chain=forward new-mss=1232 out-interface=sit1 protocol=\
    tcp tcp-flags=syn tcp-mss=1421-65535


Again - I'm a noob, so I don't understand all of this 100%, nor I am 100% sure that it is correct, but after having done this, I am now able to browse website via IPv6 on my workstation without issues.

kasperd

Quote from: ravenscroft on November 11, 2013, 03:08:42 AMYes - your understanding is correct.  I have a 4Mbps 1:1 symmetric connection via a local WISP.
The interesting question about the WAN connection is what the MTU is. Typical connections would either use IP on Ethernet, which gives you a 1500 byte MTU, or put a PPP layer between, which reduces the MTU by 8 bytes. The IPv6 tunnel layer reduces the MTU by another 20 bytes, resulting in a typical MTU of either 1472 or 1480 bytes.

Quote from: ravenscroft on November 11, 2013, 03:08:42 AMUsing ping on a workstation I determined that the largest packet I can reliably send via ipv6 is 1232:
Quote
C:\Users>ping www.google.com -l 1232

Pinging www.google.com [2607:f8b0:4000:803::1014] with 1232 bytes of data:
Reply from 2607:f8b0:4000:803::1014: time=302ms
Reply from 2607:f8b0:4000:803::1014: time=289ms
Reply from 2607:f8b0:4000:803::1014: time=303ms
Reply from 2607:f8b0:4000:803::1014: time=307ms

Ping statistics for 2607:f8b0:4000:803::1014:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 289ms, Maximum = 307ms, Average = 300ms

C:\Users>ping www.google.com -l 1233

Pinging www.google.com [2607:f8b0:4000:803::1014] with 1233 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 2607:f8b0:4000:803::1014:
   Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users>ping ipv6.he.net -l 1280

Pinging ipv6.he.net [2001:470:0:64::2] with 1280 bytes of data:
Reply from 2001:470:0:64::2: time=313ms
Reply from 2001:470:0:64::2: time=305ms
Reply from 2001:470:0:64::2: time=308ms
Reply from 2001:470:0:64::2: time=305ms

Ping statistics for 2001:470:0:64::2:
   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
   Minimum = 305ms, Maximum = 313ms, Average = 307ms

C:\Users>
The above suggests you can send and receive packets larger than 1280 bytes, but Google is limiting echo requests to a maximum of 1280 bytes. IPv6 requires 1280 bytes to be supported on every link. The difference between 1232 and 1280 matches the size of IPv6 and ICMPv6 headers, which add up to 48.

Quote from: ravenscroft on November 11, 2013, 03:08:42 AMBased on that, I did the following in the mangle section of my IPv6 firewall on the router:


/ipv6 firewall mangle
add action=change-mss chain=forward in-interface=sit1 new-mss=1232 protocol=\
   tcp tcp-flags=syn tcp-mss=1411-65535
add action=change-mss chain=forward new-mss=1232 out-interface=sit1 protocol=\
   tcp tcp-flags=syn tcp-mss=1421-65535


Again - I'm a noob, so I don't understand all of this 100%, nor I am 100% sure that it is correct, but after having done this, I am now able to browse website via IPv6 on my workstation without issues.
You did not get all the details exactly right, but you got close enough to get your configuration more reliable.

If you need to communicate over links with an MTU of 1280 bytes and broken PMTU discovery, the MSS you need is actually 1220 (1280 minus IPv6 and TCP headers). That 1232 works is probably because the links you encountered so far has an MTU of 1472 or 1480 bytes.

I don't know the exact firewall you are using, but if I read your rules correctly, you are only reducing the MSS, if it is 1411 or larger (1421 in the other direction). To improve reliability a little bit more, I think you want to use new-mss=1220 and tcp-mss=1221-65535.

kaspik

Hello guys,
thank you for this thread. I had the same issue (PPoE O2.cz connection) with mikrotik routerboard router.

Those 2 lines helped me!
/ipv6 firewall mangle add action=change-mss chain=forward in-interface=HE.net new-mss=1220 protocol=\ tcp tcp-flags=syn tcp-mss=1221-65535
/ipv6 firewall mangle add action=change-mss chain=forward new-mss=1220 out-interface=HE.net protocol=\ tcp tcp-flags=syn tcp-mss=1221-65535