After blaming DNS, checking MTU is my backup go-to for unexplained issues. Somehow missed that here – good find.
We couldn’t blame the DNS…because the DNS was the only thing working 
Glad that you resolved the issue, my initial suspicion regarding issue in ROS config was correct after all, there was some misleading/incomplete infos later where I dismissed config issue, but that happens when troubleshooting something when not on site.
Regarding MTU settings, I will still suggest to use 1500 (and LT2MTU calculated by ROS which is slightly higher value) because unless you lower MTU all on network client interfaces connected to router, packets can be fragmented for when 1480 is set. Your measure for 1480 value is for connection over WAN (google.com) which is MTU lowered and fragmented on ISP side, there is no need to fragment packets on your side (and add latency) because it will be performed by ISP infrastructure. For eg. my WAN MTU is even lower over LTE, ping replays using max size value 1330, there is also log message when lte1 interface is connected: lte1 IPv4: <ip>, DNS: <dns_ip1,dns_ip2>, MTU: 1358, still lte1 interface and other LAN interfaces have 1500 set, there is no connection/performance issues. Also jumbo frames 9000 MTU does not have effect unless network client interfaces which are communicating (for eg. on nas and computer) have also same MTU value.
There is still an open question why PMTUD did not kick in for the web traffic. Perhaps Pi-Hole 6 is blocking ping? But the MTU should have been discovered by network stack, or like to think so.
IDK if PMTUD is even performed in containers for VETH interfaces, this should be performed by OS not applications. And it is not possible to change MTU for VETH…
I’m going to read carefully your reply next days because I understand barely 30% of it (I’m going to leave for the holiday tomorrow and I’m bit confused thinking about it) 
PS: I understood from your exchange with @Amm0 that you (as me) didn’t understand why the MTU settings only affected Pi-Hole6. right?
Hi @optio,
I take a couple days to read, read again and read something about it on the internet.
Are you saying that I could ignore the output of the “ping -f -l” for anything different from the WAN?
PS: don’t want to make dirty this topic, but because we’ve ended up talking about MTU, I noticed this is a subject I didn’t give the right importance.
I’m now out of home, connecting to the internet with a Netgear M1 and sometimes to the RB5009 with OpenVPN.
While just connected to the internet the ping passes wit an MTU of 1330. With the OpenVPN connection it goes up to 1375. Should I still ignore these values while configuring the Ovpn server MTU value?
PS: while connected to the Ovpn server I have issues reaching some websites (two I noticed are Facebook and Speedtest.net) but it seams there isn’t a right MTU value for the openvpn server that fixed this (if the issue is MTU) because I tryied 1300 too (just taught “let’s set it very low )
Yes, there is no need to adjust MTU on LAN interfaces and bridge to WAN MTU.
For OpenVPN you must set on client and server side same MTU value if you change default one (1500). Try to set same MTU on client side config with tun-mtu <mtu_value> and mssfix <mtu_value - 40> (MSS clamp). I have also OpenVPN configured (L3 - ip/tun type), but I’m rarely using it because it is backup for Wireguard, my OpenVPN server interface has default 1500 value while WIreguard peer 1420. I guess I was lazy to tweak these values to proper MTU sizes to avoid fragmentation inside VPN because it is working with them and I didn't noticed issues, that is when both sides, server and client, has same MTU value set on interfaces (OpenVPN has default 1500 if not overridden by config).
because changing MTU on clients (on the app settings) is not allowed, I imagine you intended setting it into the ovpn file used to import the profile. At this point I always had 1500 (because not set) on the clients and 1480 on the server (better leaving it to 1500 at this point).
So at the moment I don’t understand why connecing to the VPN breaks some sites…but maybe it’s better to change MTU before on all the other ports of router, switch and access points and then try again…too many wrong variables at the moment
Ok, I set all the network with MTU = 1500 except for WANs and what has an automatic setting (wireguard and veths), and anything still works (that wasn’t automatic ).
Now, in a couple of day I should be able to test if issues with OpenVPN outside the network are gone or not