Opnsense somehow blocks ipv6 access to microsoft services

[NikJen]

I have a weird issue where (as far as I understand) multiple microsoft services (e.g js.monitor.azure.com) over ipv6 are unreachable. After a while my browser falls back to ipv4 and the website loads normal. For browsing this a pretty annoying but manageable. Where the issue really begins is with software that does not fall back on ipv4. They simply refuse to work...

My setup:
- Opnsense 25.7 running the latest patches
- Dual Stack configuration with both static ipv4 and static ipv6 prefix through pppeo and dhcpv6 on WAN interface
- Dual Stack with static ips on LAN
- Unbound DNS with dns over tls to quad9
- My PC gets its IPv6 over RA

Here is what I found out so far:
- Ipv6 works as expected. https://test-ipv6.com results in a perfect 10/10. Other IPv6 capable websites work flawlessly.
- DNS is not the issue. Tried different DNS setups, including configuring DNS on my pc directly and circumventing the Opnsense unbound DNS completely. After that the behavior was still the same.
- The firewall seems to be correctly configured: Live View with a filter on all my source addresses do not result in any blocked requests to microsoft services
- When running a curl command (eg. curl https://js.monitor.azure.com/scripts/c/ms.jsll-4.min.js -v) on my pc I wait forever. On the Opnsensebox however it goes through within a blink of an eye

I know this topic is rather strange and debugging remotely like that isn't easy. I would however very much appreciate every little input on how to fix this. I'm kinda desperate.

Thanks in advance

[ProximusAl]

I had a similar issue with portal.azure.com

My issue was because I get IPv6 over WireGuard Tunnel and the issue was MTU size.

Reducing the MTU to 1280 made it work.

[Monviech (Cedrik)]

If your connection is running PPPoE it is most likely an MSS issue.

I have the same issue with some sites, a good one to try is mail.yahoo.com, which will fail completely.

Some sites do not handle PMTUD correctly (an ICMP feature).

You can test this easily by lowering the MTU of your client OS network driver to e.g. 1400 and if things magically work thats the reason.

[NikJen]

Wow thank you very much! Lowering the MTU did the trick!

[meyergru]

Or try doing this.

[NikJen]

Thanks for your link. I tried replicating the configuration but no matter what, it didn't work.
ifconfig gives the following output:
igc0 (the physical lan interface): MTU 1512
vlan01: MTU 1508
pppoe0: MTU 1508
These values reflect what you described in your post.
Is my configuration "chain" correct? WAN -> PPPOE -> VLAN or should it be the other way round (WAN -> VLAN -> PPPOE)?
However the issue still remains. Accessing Microsoft or mail.yahoo.com is slow or impossible. Also the issue seems only to be connected to ipv6 and from what I read the mtu usually is not the issue with ipv6 because it has larger frames specified in the standard.
Other Info that might help:
The MTU returned from the bash-script returns different MTUs over time. As of writing it last returned 1334. But I also saw other values.
My systems network interface has 1500 set as MTU.

[meyergru]

The chain is WAN->PPPoE->VLAN, otherwise, it would not work at all.

Yes, IPv6 uses a smaller MTU. mail.yahoo.com does in fact resolve to IPv6, so if you have that configured, it will be used first.

If the script shows 1334 when using 8.8.8.8 as destination, then there is something seriously wrong with your ISP.

[NikJen]

I don't think it is the ISPs fault. I'm with the biggest provider in Germany (Telekom). Also when I revert the settings back to "default" on the PPPOE MTU and the Interface MTU the script consistently returns 1492.

[NikJen]

In the end I changed the MSS of my LAN interface. I know that's not the ideal solution. However fiddling with the MTU wasn't entirely successful.

Getting mail.yahoo.com to work, the only possibility for me was setting the MTU of the LAN interface lower (e.g 1400). This however had a weird side effect where other websites would stop working (e.g duckduckgo).

For now I will keep it that way. But I'm open to test other solutions.

I will also take a look in switching my Modem (Vigor 166) to something from Zyxel. It might be the case that the Modem does not allow frames larger than 1500 Bytes.

[meyergru]

If it (half-)works for you with an MTU of 1492, then fine.

The usual remedy for solving the problems that arise from a 1492 MTU on WAN would be to use MSS clamping, such that all LAN clients including your LAN interface can use the default 1500 byte MTU, but the packets are repackaged to the lower WAN MTU.

However, I remember having read several reports to the extent that this clamping functionality is broken with newer OpnSense releases, so YMMV.

[Patrick M. Hausen]

I have a German Telekom uplink, never messed with your proposed MTU settings but set the "MSS" in the OPNsense UI to 1492 for all internal interfaces.
Which according to the docs and the in-UI help would just do the right thing.