[SOLVED] IPv6 pings work, webpage won't load

sb56637 · Wed Aug 22, 2018 5:37 pm

Hi, I have a Mikrotik RB751U-2HnD running the latest firmware, connected to a fiber ONT in bridge mode. My ISP has good support for IPv6, and when using the ONT directly in router mode clients have IPv6 connectivity out of the box.

With the ONT in bridge mode and the Mikrotik obtaining the IPv6 prefix, I can ping IPv6 addresses from the router's ping tool, but clients do not have IPv6 connectivity. I tried with multiple Linux and Windows clients as well as Android, and none of them work. Are there any obvious errors here with my configuration?

1.png

2.png

3.png

4.png

Thanks in advance.

xvo · Wed Aug 22, 2018 5:52 pm

Other than "Accept Router Advertisements" need to be set to "no" or to "yes, if forwarding disabled" everything else looks fine.

sb56637 · Wed Aug 22, 2018 6:47 pm

Other than "Accept Router Advertisements" need to be set to "no" or to "yes, if forwarding disabled" everything else looks fine.

Thanks for the reply. I tried changing that, and it doesn't seem to make any difference.

Does the ip a from a Linux client help at all?

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 6x:xx:xx:xx:xx:x0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.30/24 brd 192.168.1.255 scope global dynamic noprefixroute wlan0
       valid_lft 527sec preferred_lft 527sec
    inet6 fxxx::xxxx:xxxx:xxxx:xxxb/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

xvo · Wed Aug 22, 2018 7:58 pm

Just to clarify: do clients get the addresses but still they have no connectivity, or they don't get any addresses at all?

sb56637 · Wed Aug 22, 2018 8:12 pm

Yes, the clients do get an IPv6 address.

I made some significant progress with neighbor discovery:

5.png

Now clients can ping IPv6 addresses, resolve most domains to their IPv6 address by default, and access most websites. But there is a really weird issue where I can not browse most or all of the IPv6-capable websites that I have been testing with, such as the http://ipv6-test.com and this forum. They hang at the TLS handshake stage. There's also another website that I know supports IPv6 and does NOT have SSL enabled that also fails to load via IPv6 although I can ping it. But if I visit a random website that I do NOT normally visit that supports IPv6 it DOES load. This behavior is the same across all browsers and clients, which I have tried restarting several times and even tried starting with fresh browser profiles to eliminate the possibility of cache problems, as well as restarting the Mikrotik and the ONT.

xvo · Wed Aug 22, 2018 9:37 pm

Try adding some static ipv6 dns servers to /ip dns (for example the ones from google: 2001:4860:4860::8888 and 2001:4860:4860::8844) and check "Advertise DNS"

sb56637 · Wed Aug 22, 2018 11:01 pm

Try adding some static ipv6 dns servers to /ip dns (for example the ones from google: 2001:4860:4860::8888 and 2001:4860:4860::8844) and check "Advertise DNS"

Hmm, I tried that, but unfortunately it's still very erratic.

mducharme · Wed Aug 22, 2018 11:10 pm

Hmm, I tried that, but unfortunately it's still very erratic.

It sounds like it might be MTU related issues. Are your clients allowing all icmpv6 from everywhere? You should be able to ping the clients with IPv6 from anywhere on the Internet.

sb56637 · Wed Aug 22, 2018 11:14 pm

Hmm, I tried that, but unfortunately it's still very erratic.
It sounds like it might be MTU related issues.

Hmm. Should I try setting MTU to something under IPv6 > ND ?

Are your clients allowing all icmpv6 from everywhere? You should be able to ping the clients with IPv6 from anywhere on the Internet.

I haven't specifically blocked anything on the clients. I was wondering if the Mikrotik IPv6 firewall was causing the problem, although I haven't done anything to it, they're all defconf rules.

mducharme · Wed Aug 22, 2018 11:56 pm

Hmm. Should I try setting MTU to something under IPv6 > ND ?

Generally there is no need to do this.

I haven't specifically blocked anything on the clients. I was wondering if the Mikrotik IPv6 firewall was causing the problem, although I haven't done anything to it, they're all defconf rules.

The default MikroTik IPv6 firewall allows ICMPv6 in the forward chain from all to all, so the MikroTik firewall would not block this. It may be blocked by default on a firewall on your devices. I have McAfee installed (it is a freebie that came with my Internet service) and by default it blocks ICMP on IPv6.

Maybe go to this site and see if it can ping your computer's IPv6 address, if it can't, then ICMPv6 is getting blocked. http://www.ipv6now.com.au/pingme.php

sb56637 · Thu Aug 23, 2018 12:03 am

Thanks for the explanation. I don't run any antivirus or device-level firewalls.
I'm a bit confused why I can ping out to domains over IPv6 but can't load the site in the browser.

mducharme · Thu Aug 23, 2018 12:09 am

Thanks for the explanation. I'm a bit confused why I can ping out to domains over IPv6 but can't load the site in the browser.

With IPv6, your computer and the website you are accessing both have to make the packet small enough for the entire path, routers in between cannot fragment the packet. If the website cannot successfully ping your computer, it will probably send a 1500 byte HTTP/IPv6 packet to you, which would be dropped because it cannot make it across your PPPoE with the overhead of 8 bytes.

Did you try going to that site and verifying that your device or computer responds to pings?

sb56637 · Thu Aug 23, 2018 12:42 am

Did you try going to that site and verifying that your device or computer responds to pings?

Hmm, you might be onto something. The ipv6now.com.au website won't load for me, although I can ping it. However https://www.ultratools.com/tools/ping6 was able to ping my device's IPv6 address. So how would I go about changing the MTU?

mducharme · Thu Aug 23, 2018 1:02 am

Hmm, you might be onto something. The ipv6now.com.au website won't load for me, although I can ping it. However https://www.ultratools.com/tools/ping6 was able to ping my device's IPv6 address. So how would I go about changing the MTU?

If pings work in both directions then generally there should be no MTU issue because path MTU discovery should work, unless there is a misconfiguration somewhere. Can you share your PPPoE interface settings? Obscure the user/password.

I occasionally see issues with MTU negotiation between PPPoE client and server, where they have a different understanding of the MTU of the other and this results in silent drops for packets that are too big.

sb56637 · Thu Aug 23, 2018 1:07 am

Sure, here you go:

1.png

And here's the default profile:

2.png

mducharme · Thu Aug 23, 2018 1:12 am

Sure, here you go:

Try setting Max MTU and Max MRU both to 1492, and check the status tab for the PPPoE interface to see what MTU and MRU is being negotiated.

sb56637 · Thu Aug 23, 2018 1:17 am

Try setting Max MTU and Max MRU both to 1492, and check the status tab for the PPPoE interface to see what MTU and MRU is being negotiated.

Done, the status shows it at 1492.

mducharme · Thu Aug 23, 2018 1:19 am

And? any change? Do those sites work now? Do you see any different behavior than before? etc.

If your ISP supports RFC4638 PPP-Max-Payload, then it is possible to increase both to 1500, and require no fragmentation.

sb56637 · Thu Aug 23, 2018 1:23 am

Unfortunately I don't see any difference.

mducharme · Thu Aug 23, 2018 1:28 am

Unfortunately I don't see any difference.

If your ISP supports RFC4638 PPP-Max-Payload, then it is possible to increase both to 1500, and require no fragmentation. This would rule out MTU issues.

Otherwise, at this point you might need to do packet captures to try to figure out what is going on.

Do you maybe have another device on your LAN that is sending IPv6 router advertisements, and your computer is sometimes routing through that device instead of your main router?

sb56637 · Thu Aug 23, 2018 1:33 am

If your ISP supports RFC4638 PPP-Max-Payload, then it is possible to increase both to 1500, and require no fragmentation. This would rule out MTU issues.

It looks like it doesn't. I tried setting them both to 1500 but in the status it still shows MTU at 1492. The original configuration of the ONT that the ISP provided me before I put it in bridge mode had an MTU of 1480.

It looks like I'll have to run a packet trace as you suggest. I hope to do so in the upcoming days, and I'll post any developments here.

Thanks very much for your time!

sb56637 · Fri Aug 24, 2018 5:14 pm

OK, I think I figured it out thanks to @mducharme and these two posts:

- viewtopic.php?t=102502#p509821
- viewtopic.php?t=130501#p640880

I just added that clamp-to-pmtu mangle rule to both the IPv4 and IPv6 firewalls, and it magically fixed everything. I also set the MTU and MRU in the PPP connection settings to 1492 for good measure, but it appears to work with the default (1480) as well.

So why might this have been a problem? Is it something janky with my ISP? Or a Mikrotik bug? Or possibly the fiber ONT is also manipulating MSS / MTU / MRU values even though it's in bridge mode?

Many thanks to @mducharme for pointing me in the right direction, I never would have though to look into MTU issues for IPv6.

R1CH · Fri Aug 24, 2018 6:17 pm

If clamp-to-pmtu solves the problem this probably means there is something in the network path that is dropping ICMPv6 messages. This is pretty bad and you should try and figure out where this is happening and fix it if possible.

mducharme · Fri Aug 24, 2018 11:36 pm

So why might this have been a problem? Is it something janky with my ISP? Or a Mikrotik bug? Or possibly the fiber ONT is also manipulating MSS / MTU / MRU values even though it's in bridge mode?

As R1CH says, something is blocking ICMPv6 so that path MTU discovery is not working. The MikroTik should not block it by default unless you created rules for that. Even though you said before that you did not, go into your IPv6->Firewall and double check that you have rules allowing all lCMPv6 on both input and forward chains, from everywhere to everywhere without restrictions.

Another possibility is that if you have another device on your internal network that is incorrectly configured to send Router Advertisements and has IPv6 forwarding enabled, your computer may be using that device as a default gateway, and it is in turn sending them to the MikroTik. If it is blocking ICMPv6, then you would have these Path MTU discovery issues. Could be a wireless access point or anything similar that allows you to configure it as a router.

sb56637 · Sat Aug 25, 2018 12:16 am

Even though you said before that you did not, go into your IPv6->Firewall and double check that you have rules allowing all lCMPv6 on both input and forward chains, from everywhere to everywhere without restrictions.

Does everything look normal here?

Screenshot from 2018-08-24 16-13-04.png

The defconf: rfc4890 drop hop-limit=1 rule isn't possibly causing problems?

As far as other devices advertising themselves as routers, it's a very small network, I'm sure there's nothing like that on the network.

mducharme · Sat Aug 25, 2018 1:11 am

Does everything look normal here?

It looks fine, but it is hard to tell because you keep sending screenshots instead of config dumps, and not all fields are shown on the screen by default. It is better to post config dumps instead of screen snapshots, they have more info and take up less space.

Please go to the device via command line, make your terminal window large so that the lines don't get abbreviated, and type "/ipv6 firewall export" and press enter, copy and paste the results.

sb56637 · Sat Aug 25, 2018 1:24 am

/ipv6 firewall export 

# aug/24/2018 17:23:25 by RouterOS 6.42.7

# software id = KZAB-HII5

#

# model = 751U-2HnD

# serial number = 2FF2013816F7

/ipv6 firewall address-list

add address=::/128 comment="defconf: unspecified address" list=bad_ipv6

add address=::1/128 comment="defconf: lo" list=bad_ipv6

add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6

add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6

add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6

add address=100::/64 comment="defconf: discard only " list=bad_ipv6

add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6

add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6

add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6

add address=::224.0.0.0/100 comment="defconf: other" list=bad_ipv6

add address=::127.0.0.0/104 comment="defconf: other" list=bad_ipv6

add address=::/104 comment="defconf: other" list=bad_ipv6

add address=::255.0.0.0/104 comment="defconf: other" list=bad_ipv6

/ipv6 firewall filter

add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked

add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid

add action=accept chain=input comment="defconf: accept ICMPv6" protocol=icmpv6

add action=accept chain=input comment="defconf: accept UDP traceroute" port=33434-33534 protocol=udp

add action=accept chain=input comment="defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=udp src-address=fe80::/16

add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 protocol=udp

add action=accept chain=input comment="defconf: accept ipsec AH" protocol=ipsec-ah

add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=ipsec-esp

add action=accept chain=input comment="defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec

add action=drop chain=input comment="defconf: drop everything else not coming from LAN" in-interface-list=!LAN

add action=accept chain=forward comment="defconf: accept established,related,untracked" connection-state=established,related,untracked

add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid

add action=drop chain=forward comment="defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6

add action=drop chain=forward comment="defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6

add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" hop-limit=equal:1 protocol=icmpv6

add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=icmpv6

add action=accept chain=forward comment="defconf: accept HIP" protocol=139

add action=accept chain=forward comment="defconf: accept IKE" dst-port=500,4500 protocol=udp

add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=ipsec-ah

add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=ipsec-esp

add action=accept chain=forward comment="defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec

add action=drop chain=forward comment="defconf: drop everything else not coming from LAN" in-interface-list=!LAN

mducharme · Sat Aug 25, 2018 1:36 am

Yes that is correct. That shouldn't cause problems.

If there is traffic hitting the ICMPv6 hop limit 1 rule then you can try disabling it to see if it helps. Although, I am starting to suspect that your ISP may have a bad configuration and is blocking ICMPv6 somewhere they should not be, perhaps on their PPPoE Concentrator. They may not have enough customers on IPv6 yet with a setup like yours to notice this issue.

Also do a packet capture, in the MikroTik go to Tools->Packet capture, under General, give it a filename with .pcap extension, go to filter tab, set IP protocol to 58 (this is ICMPv6 protocol number), direction any, filter operation or, click apply. Disable the mangle rule you made and click start. Then go to a website that wouldn't load before making the mangle rule. Then click stop, download the file from the router's files folder, then then you can send and attach that (it can also be opened in wireshark). Then re-enable your mangle rule so your service works again.

nostromog · Sat Aug 25, 2018 3:24 am

I have pretty much the same problem, in my case ipv6 is a 6to4 tunnel inside a pppoe interface. Could the problem be coming from some "inherit" in do-not-fragment that makes that the ipv4 tunnel drops the ipv6 big packet, and thus the ipv6 stack never sees the error? (wild guess)

mducharme · Sat Aug 25, 2018 3:32 am

I have pretty much the same problem, in my case ipv6 is a 6to4 tunnel inside a pppoe interface. Could the problem be coming from some "inherit" in do-not-fragment that makes that the ipv4 tunnel drops the ipv6 big packet, and thus the ipv6 stack never sees the error? (wild guess)

If using HE tunnelbroker over PPPoE you need to lower the MTU on the tunnelbroker side, the default on their end is 1480 which is too big if you have PPPoE overhead. If your PPPoE is 1480, decrease that setting to 1460, and then it should be OK. It is done through their web interface under advanced settings tab for your tunnel.

sb56637 · Tue Aug 28, 2018 4:25 pm

Also do a packet capture, in the MikroTik go to Tools->Packet capture, under General, give it a filename with .pcap extension, go to filter tab, set IP protocol to 58 (this is ICMPv6 protocol number), direction any, filter operation or, click apply. Disable the mangle rule you made and click start. Then go to a website that wouldn't load before making the mangle rule. Then click stop, download the file from the router's files folder, then then you can send and attach that (it can also be opened in wireshark). Then re-enable your mangle rule so your service works again.

Sorry for the delay. I am attaching the packet capture as you described. I ran it through TraceWrangler to anonymize it, and now it shows some packets as malformed, in the original capture they're all valid. I don't know if TraceWrangler eliminated any other important information. If it is did, let me know and I can PM you the original.

Thanks a lot!

mducharme · Tue Aug 28, 2018 4:40 pm

The capture did not see a "Packet too big" message, it should be there in Wireshark: https://packetpushers.net/ipv6-and-the- ... g-message/

If you disabled the mangle rule that you had created to work around the problem before taking that capture, chances are good that your ISP is dropping the message, that would be a major configuration issue on their end. You should try to get them to fix that.

sb56637 · Tue Aug 28, 2018 4:48 pm

The capture did not see a "Packet too big" message, it should be there in Wireshark: https://packetpushers.net/ipv6-and-the- ... g-message/

If you disabled the mangle rule that works around the problem, chances are good that your ISP is dropping the message, that would be a major configuration issue on their end. You should try to get them to fix that.

Yep, the capture was with the Mangle / MSS workaround disabled. So it's probably my ISP. The problem is getting them to understand, they generally assume their users are protozoically dumb and will just ask me to update my antivirus software and confirm that I can still logon to Facebook...

The only thing I still wonder about is why IPv6 appeared to work "out of the box" with the ONT that the ISP provided me with its standard configuration running in router mode. I didn't use it too much that way before switching it to bridge mode and connecting the Mikrotik, but it definitely seemed to work without problems.

Thanks a lot for helping me to diagnose this.

nostromog · Tue Aug 28, 2018 7:25 pm

mducharme

If using HE tunnelbroker over PPPoE you need to lower the MTU on the tunnelbroker side, the default on their end is 1480 which is too big if you have PPPoE overhead. If your PPPoE is 1480, decrease that setting to 1460, and then it should be OK. It is done through their web interface under advanced settings tab for your tunnel.

Does not make any difference, I tried all the combinations of values. Additionally I restricted all MTUs (of both the 6to4 and their side) to 1280 as they instruct to do, or left me/them as 1480, 1472, 1460, 1452...

Always the same behaviour. I'm a bit lost. I tried the mangle rules, but no change... The occasional session gets through, but most die. When I do IPv6 packet level tracing of http connections I see the handshake with no problems, and then my client sending the "GET / HTTP/1.1" up to a dozen times; sometimes an answer comes back, but most times it is just RST,FIN after 5 minutes. It is not easy to trace the 6to4 tunnel itself or the pppoe, I think their ONT can be set up to mirror the traffic in one of the ethernet ports, I might try this when I'm back home next week.

sb56637

The only thing I still wonder about is why IPv6 appeared to work "out of the box" with the ONT that the ISP provided me with its standard configuration running in router mode. I didn't use it too much that way before switching it to bridge mode and connecting the Mikrotik, but it definitely seemed to work without problems.

Are we speaking Movistar FTTH here? (this is my case).

sb56637 · Tue Aug 28, 2018 7:45 pm

sb56637

Are we speaking Movistar FTTH here? (this is my case).

No, it's a different ISP.

mducharme · Tue Aug 28, 2018 9:50 pm

Does not make any difference, I tried all the combinations of values. Additionally I restricted all MTUs (of both the 6to4 and their side) to 1280 as they instruct to do, or left me/them as 1480, 1472, 1460, 1452...

Always the same behaviour. I'm a bit lost. I tried the mangle rules, but no change... The occasional session gets through, but most die.

ICMPv6 is allowed on your MikroTik on both forward and input chain? Your MikroTik is acting as the PPPoE client? If the MikroTik is acting as the PPPoE client, you should see the negotiated MTU and MRU and should be able to calculate from that the correct MTU for the hurricane electric side of the tunnel by subtracting 20 more. Your side of the HE tunnel can be 1280 because usually you don't need as much for upload.

nostromog · Wed Aug 29, 2018 12:08 am

Does not make any difference, I tried all the combinations of values. Additionally I restricted all MTUs (of both the 6to4 and their side) to 1280 as they instruct to do, or left me/them as 1480, 1472, 1460, 1452...

Always the same behaviour. I'm a bit lost. I tried the mangle rules, but no change... The occasional session gets through, but most die.
ICMPv6 is allowed on your MikroTik on both forward and input chain?

Yes:

[admin@Mikrotik] > :put [/system resource get uptime ]
4d03:24:04
[admin@Mikrotik] > /ipv6 firewall filter print stats where protocol~"icmpv6"
Flags: X - disabled, I - invalid, D - dynamic 
 #    CHAIN                                                                ACTION                            BYTES         PACKETS
 0    ;;; defconf: accept ICMPv6
      input                                                                accept                              112               2
 1    ;;; defconf: accept ICMPv6
      forward                                                              accept                              824               9

I have the tunnel disabled most of the time, as things stop working as the clients pick up the ipv6 addresses... [I only up it for debugging, but editing after I pasted the above, now after some more experiments the forward rule accepted 131 packets just with some more icmp/tcp experiments.]

Your MikroTik is acting as the PPPoE client? If the MikroTik is acting as the PPPoE client, you should see the negotiated MTU and MRU and should be able to calculate from that the correct MTU for the hurricane electric side of the tunnel by subtracting 20 more. Your side of the HE tunnel can be 1280 because usually you don't need as much for upload.

Yes, my router is the client. I have experimented with those values, but everything is consistent and ipv4 works like a charm. From linux I can ping ipv6.tunnelbroker.net with up to 1360 bytes, ipv6.google.com up to 1232 bytes, more than this (no upper limit) is a blackhole for both:

$ ping -c 1 -s 1360 ipv6.tunnelbroker.net
PING ipv6.tunnelbroker.net(tunnelbroker.net (2001:470:0:63::2)) 1360 data bytes
1368 bytes from tunnelbroker.net (2001:470:0:63::2): icmp_seq=1 ttl=56 time=301 ms

--- ipv6.tunnelbroker.net ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 301.014/301.014/301.014/0.000 ms
$ ping -c 1 -s 1361 ipv6.tunnelbroker.net
PING ipv6.tunnelbroker.net(tunnelbroker.net (2001:470:0:63::2)) 1361 data bytes

--- ipv6.tunnelbroker.net ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
$ ping -c 1 -s 1232 ipv6.google.com
PING ipv6.google.com(dh-in-x8b.1e100.net (2a00:1450:400b:c03::8b)) 1232 data bytes
72 bytes from dh-in-x8b.1e100.net (2a00:1450:400b:c03::8b): icmp_seq=1 ttl=47 (truncated)

--- ipv6.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 143.711/143.711/143.711/0.000 ms
$ ping -c 1 -s 1233 ipv6.google.com
PING ipv6.google.com(dub08s01-in-x0e.1e100.net (2a00:1450:400b:801::200e)) 1233 data bytes

--- ipv6.google.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

mducharme · Sat Sep 08, 2018 1:52 am

Yes, my router is the client. I have experimented with those values, but everything is consistent and ipv4 works like a charm. From linux I can ping ipv6.tunnelbroker.net with up to 1360 bytes, ipv6.google.com up to 1232 bytes, more than this (no upper limit) is a blackhole for both:

Have you tried a different tunnel server on the HE side? I wonder if maybe they have a previously unnoticed configuration issue with one of their tunnelbroker servers that might explain your issue. Trying a different tunnelbroker server would allow you to identify if that is the case. This really sounds like it might be an HE problem.

nostromog · Sat Sep 08, 2018 3:19 am

Yes, my router is the client. I have experimented with those values, but everything is consistent and ipv4 works like a charm. From linux I can ping ipv6.tunnelbroker.net with up to 1360 bytes, ipv6.google.com up to 1232 bytes, more than this (no upper limit) is a blackhole for both:
Have you tried a different tunnel server on the HE side? I wonder if maybe they have a previously unnoticed configuration issue with one of their tunnelbroker servers that might explain your issue. Trying a different tunnelbroker server would allow you to identify if that is the case. This really sounds like it might be an HE problem.

I tried the Frankfurt and London endpoints, which are the closest to home. I also got puzzled and tend to think that this is their problem, but I have no clear ways to further diagnose. My country (Spain) is in a very sorry situation as the ex-monopoly and main provider (Telefonica/Movistar) refuses to route IPv6, even now that google is reporting almost 25% of their traffic is IPv6, so it allows us little space for keeping up to date with technology in practice.

mducharme · Sat Sep 08, 2018 8:01 am

I tried the Frankfurt and London endpoints, which are the closest to home. I also got puzzled and tend to think that this is their problem, but I have no clear ways to further diagnose. My country (Spain) is in a very sorry situation as the ex-monopoly and main provider (Telefonica/Movistar) refuses to route IPv6, even now that google is reporting almost 25% of their traffic is IPv6, so it allows us little space for keeping up to date with technology in practice.

They have a forum, and their top engineers go on that forum. If you explain that your router is configured to allow all ICMPv6 and you have lowered the MTU on the tunnel (since you are on PPPoE) and yet you are unable to use IPv6 because of missing packet-too-big messages, I'm sure they will look into what is happening.

From the sounds of it, the HE tunnelbroker server itself is not sending back the packet-too-big based on your configured MTU for the tunnel, which is resulting in your issue. It must be sending packet-too-big based on the default tunnel MTU of 1480 instead of your selected MTU. This would result in a problem only for customers with an HE IPv6 tunnel with < 1500 IPv4 MTU, which is probably a minority of HE customers, so they might not have noticed such an issue.

lilw · Wed Dec 11, 2019 7:07 pm

I got the same problem here in my country, Using FTTH from Viettel. I noted them with the issue that some sites I can ping but can't access via IPV6. But their answer kind of claim their customer is dumb to work thing out.

At the begining, I asked them to bridge my mikrotik but it take them a week to do that, and the tech come to my house is not familiar with mikrotik things, but I heard somewhere that the ISP has already import huge amount of mikrotik. I request speak to higher tech and this person claims that mikrotik can't work well with pppoe or IPTV. But guess what, I figured all thing out by follow most intrustion from here. The more I'm working with the tech guy, the more I found that those tech guys, even at higher level and we call them NOC don't know much about their job either. It took me couple months to figure about pmtu here, and another couple months to figure this clamp-to-pmtu rule. Thanks to the right keyword.

I know this topic is old enough but there still people like me have difficult time with the ISP like this one and they don't even want to help at all. Thanks to sb56637 and mducharme.

seridohost · Thu Sep 07, 2023 3:39 pm

Bom dia!
Pra resolver esse problema de não conseguir abrir alguns websites usando IPv6, basta alterar no profile do ppp change-tcp-mss para yes. Assim, não precisará criar a regra no mangle.

/ppp profile
Flags: * - default 
 0 * name="default" bridge-learning=default use-ipv6=yes use-mpls=default 
     use-compression=default use-encryption=default only-one=default 
     change-tcp-mss=yes use-upnp=default address-list="" on-up="" on-down=""

Who is online