MTU issues with certain sites like netflix, spotify, usps and even opnsense.org

[rgonzales98]

This initially started with netflix and spotify not working on my TV and stating no internet connection even though everything else was working. I have tried to find a solution to this but nothing is working :/ . Netflix has started working after i have disabled ipv6 but whenever i ping netflix.com it still gives me a timeout response as if the dns is not responding with a valid IP!!!  I have read that maybe some websites with load balancers are not responding with the correct IP address or just overall not responding at all to query requests. I am a beginner so ive just been following basic tutorials on how to set this up. Currently allowing all traffic on my firewall LAN for ipv4 so its not an issue with my firewall rules.

I'm either getting a ERR_CONNECTION_TIMED_OUT (opnsense.org) or DNS_PROBE_FINISHED_NXDOMAIN(usps.com).

I was wanting to stick with my ISP DNS and keep my DNS config simple using unbound but maybe thats the issue? Any recommendations on what i should do to fix this? I dont have an special DNS settings setup. I have included screenshots of my DNS settings and general settings. I have been dealing with this for hours.

[OPNenthu]

I'm not having issues on the other sites you mentioned, but since yesterday many Netflix domains are not resolving in Unbound (recursive mode) and it's not due to block lists.  See screenshots.

Local resolver returning NXDOMAIN:

Code: [Select]

$ dig help.netflix.com

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> help.netflix.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37074
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;help.netflix.com.              IN      A

;; ANSWER SECTION:
help.netflix.com.       300     IN      CNAME   help.dradis.netflix.com.
help.dradis.netflix.com. 60     IN      CNAME   help.us-east-2.internal.dradis.netflix.com.

;; AUTHORITY SECTION:
dradis.netflix.com.     60      IN      SOA     e.ns.nflxso.net. nicadmin.netflix.com. 1732744401 16384 2048 1048576 60

;; Query time: 43 msec
;; SERVER: 192.168.40.1#53(192.168.40.1) (UDP)
;; WHEN: Wed Nov 27 17:02:57 EST 2024
;; MSG SIZE  rcvd: 169


Same query working with public DNS (DoH):

Code: [Select]

$ dig @1.1.1.1 help.netflix.com +https

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> @1.1.1.1 help.netflix.com +https
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29796
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;help.netflix.com.              IN      A

;; ANSWER SECTION:
help.netflix.com.       32      IN      CNAME   help.dradis.netflix.com.
help.dradis.netflix.com. 60     IN      CNAME   help.us-east-2.internal.dradis.netflix.com.
help.us-east-2.internal.dradis.netflix.com. 60 IN CNAME apiproxy-helpcenter-nlb-6cc037a5a8a90429.elb.us-east-2.amazonaws .com.
apiproxy-helpcenter-nlb-6cc037a5a8a90429.elb.us-east-2.amazonaws.com. 60 IN A 3.136.253.118
apiproxy-helpcenter-nlb-6cc037a5a8a90429.elb.us-east-2.amazonaws.com. 60 IN A 52.14.201.162
apiproxy-helpcenter-nlb-6cc037a5a8a90429.elb.us-east-2.amazonaws.com. 60 IN A 3.133.57.11

;; Query time: 35 msec
;; SERVER: 1.1.1.1#443(1.1.1.1) (HTTPS)
;; WHEN: Wed Nov 27 17:05:21 EST 2024
;; MSG SIZE  rcvd: 236

When I temporarily switch my browser to use DoH, Netflix sites start working again.

Incidentally the Netflix app on my phone is not able to connect to the Chromecast for streaming as of yesterday.  Not sure if related.  I'm seeing a persistent error message when trying to cast that I'm unable to find information about online.  This was working the day before.

[OPNenthu]

Ok, I solved it.

Services->Unbound DNS->Advanced->Strict QNAME Minimisation (uncheck)

Disabling that makes everything with Netflix work again, including the Chromecast.

Code: [Select]

$ dig help.netflix.com

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> help.netflix.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64904
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;help.netflix.com.              IN      A

;; ANSWER SECTION:
help.netflix.com.       300     IN      CNAME   help.dradis.netflix.com.
help.dradis.netflix.com. 60     IN      CNAME   help.us-east-1.internal.dradis.netflix.com.
help.us-east-1.internal.dradis.netflix.com. 60 IN CNAME apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com.
apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com. 60 IN A 3.231.234.168
apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com. 60 IN A 52.71.159.247
apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com. 60 IN A 3.222.220.127

;; Query time: 79 msec
;; SERVER: 192.168.40.1#53(192.168.40.1) (UDP)
;; WHEN: Wed Nov 27 18:12:00 EST 2024
;; MSG SIZE  rcvd: 236

Always a sad day having to disable a global pro-privacy option that had been working previously.

[rgonzales98]

Doesnt seem to be my issue unfortunately. I'm getting back a reply for some of the domains but websites like opnsense.org dont even load lmao. It requires me to use a vpn for me to load this site.

Code: [Select]

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> opnsense.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52253
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;opnsense.org.                  IN      A

;; ANSWER SECTION:
opnsense.org.           826     IN      A       178.162.131.118

;; Query time: 1 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Nov 28 00:51:10 UTC 2024
;; MSG SIZE  rcvd: 57

Code: [Select]

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> netflix.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48874
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;netflix.com.                   IN      A

;; ANSWER SECTION:
netflix.com.            60      IN      A       3.211.157.115
netflix.com.            60      IN      A       3.225.92.8
netflix.com.            60      IN      A       54.160.93.182

;; Query time: 38 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Nov 28 00:53:00 UTC 2024
;; MSG SIZE  rcvd: 88


Code: [Select]

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> usps.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25141
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;usps.com.                      IN      A

;; Query time: 2 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Nov 28 00:53:30 UTC 2024
;; MSG SIZE  rcvd: 37


[rgonzales98]

Maybe it's not an issue with DNS issue since im getting a reply back?

Ok, I solved it.

Services->Unbound DNS->Advanced->Strict QNAME Minimisation (uncheck)

Disabling that makes everything with Netflix work again, including the Chromecast.

Code: [Select]

$ dig help.netflix.com

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> help.netflix.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64904
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;help.netflix.com.              IN      A

;; ANSWER SECTION:
help.netflix.com.       300     IN      CNAME   help.dradis.netflix.com.
help.dradis.netflix.com. 60     IN      CNAME   help.us-east-1.internal.dradis.netflix.com.
help.us-east-1.internal.dradis.netflix.com. 60 IN CNAME apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com.
apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com. 60 IN A 3.231.234.168
apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com. 60 IN A 52.71.159.247
apiproxy-helpcenter-nlb-8f45ed8b6aa9cee1.elb.us-east-1.amazonaws.com. 60 IN A 3.222.220.127

;; Query time: 79 msec
;; SERVER: 192.168.40.1#53(192.168.40.1) (UDP)
;; WHEN: Wed Nov 27 18:12:00 EST 2024
;; MSG SIZE  rcvd: 236

Always a sad day having to disable a global pro-privacy option that had been working previously.

[meyergru]

You should try to look at what exactly is not working. Other than the thread title suggests, the DNS resolution seems to work just fine...

Are you using jumbo frames or does your ISP connection use VLANs or PPPoE? There are websites that do not use PMTU discovery, so they may fail when your MTU settings are wrong.

[rgonzales98]

Thank you for your response! I've left any MTU setting as default so it should be 1500. From my understanding my ISP uses PPPoE. If my ISP did use VLANs i would have to set the vlan ID for the internet to work at all correct? Just did some ping test to see if i can figure it the MTU. Seems to be 1500. Ill use wireshark to try and find the failing point for this since im at a loss

Code: [Select]

ping yahoo.com -f -l 1472

Pinging yahoo.com [74.6.231.20] with 1472 bytes of data:
Reply from 74.6.231.20: bytes=1472 time=44ms TTL=49
Reply from 74.6.231.20: bytes=1472 time=47ms TTL=49
Reply from 74.6.231.20: bytes=1472 time=46ms TTL=49
Reply from 74.6.231.20: bytes=1472 time=46ms TTL=49

Ping statistics for 74.6.231.20:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 44ms, Maximum = 47ms, Average = 45ms

Code: [Select]

ping netflix.com -f -l 1472

Pinging netflix.com [54.160.93.182] with 1472 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 54.160.93.182:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

Code: [Select]

ping opnsense.org -f -l 1472

Pinging opnsense.org [178.162.131.118] with 1472 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 178.162.131.118:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

You should try to look at what exactly is not working. Other than the thread title suggests, the DNS resolution seems to work just fine...

Are you using jumbo frames or does your ISP connection use VLANs or PPPoE? There are websites that do not use PMTU discovery, so they may fail when your MTU settings are wrong.

[meyergru]

And there you have it!

As you can see, the problematic sites cannot be accessed by a payload of 1472 bytes corresponding to a MTU of 1500. That is your problem, not DNS.

The maximum physical MTU of the ethernet adapter has to be reduced by 4 bytes for VLANs, plus 8 bytes for PPPoE encapsulation, thus you will either have to reduce your WAN (net) MTU by these amounts. That is, you should reduce your MTU to 1492 or 1488 bytes.

Or you can hope that your ethernet driver (and your ISP) supports even more than 1500 bytes and set larger sizes for the lower layers beneath the logical WAN adapter in order to keep 1500 bytes.

But beware:

1. The OpnSense settings here are somewhat "wrong". If you have a WAN over PPPoE over VLAN, you "should" have to set WAN = 1500, pppoe0 = 1508, ONT = 1512, but in reality it works for me with these MTUs:

WAN: 1508 (this also sets pppoe0, which you cannot set directly, but really results in 1500 on WAN)
ONT (this means the physical ethernet port): 1512 if you have a VLAN for PPPoE, 1508 if not.

2. Set the above values in the web UI and then reboot - they cannot be changed via UI manipulations, because the order of application seems to be wrong that way.

Retry your tests afterwards.

And, as a courtesy to others, please change your thread title as it is obviously not DNS that is your problem. If your problem is fixed, add [SOLVED] to the thread title.

[MagikMark]

meyergru

Is there a way to know if your ISP is doing what you just described?  Or this is just trial and error? My ISP uses IPoE over vlan and multicast vlan.  Following your instruction, this would be 1500 + 4 + 4 MTU is now 1508?

[meyergru]

The reduction of available MTU size by adding encapsulation layers is a given fact. You can always reduce your WAN MTU size accordingly.

Whether your own hardware and your ISP infrastructure will support more than 1500 bytes MTU on the lower network layers can either be tested (what you call trial and error) or probably be looked up or you can ask them. Sometimes it can be driver dependend or may be different in certain areas because of different equipment employed.

In my experience you cannot believe something that you have not tested yourself. Also, a test is probably easier anyway.

[OPNenthu]

Few observations that I'm confused about regarding the MTU topic:

1. I cannot presently ping netflix.com regardless of which payload size I use.  The other sites do respond.  Can I just assume that ICMP is being dropped somewhere along the path and has nothing to do with misconfigured MTU?  (red herring)

2. I don't understand what is going on with MTU in my own setup and will also appreciate some guidance.

My ISP service is over a DOCSIS cable modem using DHCPv4 and DHCPv6 (not PPPoE).  From what I can find out online, the ISP sets the MTU to 1500 on the gateway.  In OPNsense I have not specified the MTU and am using the interface defaults, which includes the "Override MTU" option checked in DHCP Client Configuration.

Now taking the 20-byte standard TCP/IP header into account, I should be able to ping with a payload size of 1480 I think?  Is that correct?

But I'm seeing that only 1472 works:

Code: [Select]

> ping -f -l 1500 opnsense.org

Pinging opnsense.org [178.162.131.118] with 1500 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 178.162.131.118:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),



Code: [Select]

> ping -f -l 1472 opnsense.org

Pinging opnsense.org [178.162.131.118] with 1472 bytes of data:
Reply from 178.162.131.118: bytes=1472 time=102ms TTL=49
Reply from 178.162.131.118: bytes=1472 time=100ms TTL=49
Reply from 178.162.131.118: bytes=1472 time=98ms TTL=49
Reply from 178.162.131.118: bytes=1472 time=100ms TTL=49

Ping statistics for 178.162.131.118:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 98ms, Maximum = 102ms, Average = 100ms


Code: [Select]

> ping -f -l 1473 opnsense.org

Pinging opnsense.org [178.162.131.118] with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 178.162.131.118:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),


1500 - 1472 = 28 byte header... corresponding to PPPoE (?)

Sorry if I severely misunderstand something here but this isn't making sense and I'm not sure if I need to change anything in OPNsense.

My speedtest and bufferbloat results look OK.  Latency is controlled since I implemented FQ_CoDel in Firewall->Shaping.  Thus I haven't thought to even question MTU until now.

[meyergru]

1. I cannot presently ping netflix.com regardless of which payload size I use.  The other sites do respond.  Can I just assume that ICMP is being dropped somewhere along the path and has nothing to do with misconfigured MTU?  (red herring)

You are correct, netflix.com does not respond to pings at all. But opnsense.org does, it only does seems to have defective PMTU discovery. I verified that I get png answers with an MSS of 1472 from opnsense.org, so my MTU is fine, whereas the OP's MTU was not.

Also, always bear in mind that when you use a DNS name, you may be communicating with a different IP than other people, depending on your geolocation.

2. I don't understand what is going on with MTU in my own setup and will also appreciate some guidance.

My ISP service is over a DOCSIS cable modem using DHCPv4 and DHCPv6 (not PPPoE).  From what I can find out online, the ISP sets the MTU to 1500 on the gateway.  In OPNsense I have not specified the MTU and am using the interface defaults, which includes the "Override MTU" option checked in DHCP Client Configuration.

If there are no further encapsulation layers and we talk strictly IPv4, they this should operate much like a direct ethernet connection, so your MTU should be 1500 bytes (i.e. default).

Now taking the 20-byte standard TCP/IP header into account, I should be able to ping with a payload size of 1480 I think?  Is that correct?

But I'm seeing that only 1472 works:

Code: [Select]

> ping -f -l 1500 opnsense.org

Pinging opnsense.org [178.162.131.118] with 1500 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 178.162.131.118:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),



Code: [Select]

> ping -f -l 1472 opnsense.org

Pinging opnsense.org [178.162.131.118] with 1472 bytes of data:
Reply from 178.162.131.118: bytes=1472 time=102ms TTL=49
Reply from 178.162.131.118: bytes=1472 time=100ms TTL=49
Reply from 178.162.131.118: bytes=1472 time=98ms TTL=49
Reply from 178.162.131.118: bytes=1472 time=100ms TTL=49

Ping statistics for 178.162.131.118:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 98ms, Maximum = 102ms, Average = 100ms


Code: [Select]

> ping -f -l 1473 opnsense.org

Pinging opnsense.org [178.162.131.118] with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 178.162.131.118:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),


1500 - 1472 = 28 byte header... corresponding to PPPoE (?)

Sorry if I severely misunderstand something here but this isn't making sense and I'm not sure if I need to change anything in OPNsense.

First, ping options in FreeBSD, Linux and Windows greatly differ. Assuming you use ping on Windows, the flags mean "-f = don't fragment", which is to potentially create packets that are too big to fit into your MTU and "-l 1472", meaning "send 1472 bytes of payload with the ping".

While TCP has a header size of at least 20 bytes, actual payload may start only after 60 bytes, because you can also have TCP options taking up more header space.

But that is not the point. The ping utility does not use TCP at all, but another IPv4 "protocol" called ICMPv4.

That protocol has its own 8 Byte header, where for a ping, an ICMPv4 "echo request" (type 8 ) packet is used. But that header is placed after the initial IPv4 header, which is at least 20 bytes long. Adding that up makes a total ICMPv4 header length of 28 bytes, giving you 1472 bytes at most for the payload.

Besides: TCP/IP has a total header length of (at least) 40 bytes, because it also prepends the IPv4 header before the actual TCP header. The IPv4 header already has src and dst address, but the src and dst ports are within the TCP header portion. With ICMP, you do not have ports, so the header can be shorter.

My speedtest and bufferbloat results look OK.  Latency is controlled since I implemented FQ_CoDel in Firewall->Shaping.  Thus I haven't thought to even question MTU until now.

Traffic Shaping can have its own pitfalls with some providers (like Deutsche Glasfaser).

[mooh]

I was wanting to stick with my ISP DNS and keep my DNS config simple using unbound but maybe thats the issue?

If you really want to stick with your ISP's DNS servers, you may want to use dnsmasq as simple forwarder. If you have IPv6 available and active, add a rule to allow IPv6 like IPv4. IPv6 should find the path MTU automatically.

[OPNenthu]

While TCP has a header size of at least 20 bytes, actual payload may start only after 60 bytes, because you can also have TCP options taking up more header space.

But that is not the point. The ping utility does not use TCP at all, but another IPv4 "protocol" called ICMPv4.

That protocol has its own 8 Byte header, where for a ping, an ICMPv4 "echo request" (type 8 ) packet is used. But that header is placed after the initial IPv4 header, which is at least 20 bytes long. Adding that up makes a total ICMPv4 header length of 28 bytes, giving you 1472 bytes at most for the payload.

Besides: TCP/IP has a total header length of (at least) 40 bytes, because it also prepends the IPv4 header before the actual TCP header. The IPv4 header already has src and dst address, but the src and dst ports are within the TCP header portion. With ICMP, you do not have ports, so the header can be shorter.

This helps a lot, thank you.

I can't believe I made that mistake with ping and TCP 

Traffic Shaping can have its own pitfalls with some providers (like Deutsche Glasfaser).

In my case it brought the bufferbloat scores from a variable A-C+ to a consistent A/A+.  I only had to sacrifice some bandwidth.  My service is 800/20, but the ISP tend to overprovision so I was actually getting 900 to 1000 Mbps sometimes on the download before the shaping.  Now it's clamped to 760 in OPNsense, but more consistent and lower latency.

[rgonzales98]

I have tried to change the wan MTU config to different values and it still doesnt work. I moved over the ubuntu to ping and test my MTU. Tried the following for google and it worked.

Code: [Select]

ping google.com -c 10 -M do -s 1472
PING google.com (142.250.115.101) 1472(1500) bytes of data.
1480 bytes from rq-in-f101.1e100.net (142.250.115.101): icmp_seq=1 ttl=106 time=16.5 ms
1480 bytes from rq-in-f101.1e100.net (142.250.115.101): icmp_seq=2 ttl=106 time=14.8 ms
1480 bytes from rq-in-f101.1e100.net (142.250.115.101): icmp_seq=3 ttl=106 time=17.4 ms
1480 bytes from rq-in-f101.1e100.net (142.250.115.101): icmp_seq=4 ttl=106 time=18.7 ms
1480 bytes from rq-in-f101.1e100.net (142.250.115.101): icmp_seq=5 ttl=106 time=17.9 ms
1480 bytes from rq-in-f101.1e100.net (142.250.115.101): icmp_seq=6 ttl=106 time=15.9 ms
1480 bytes from rq-in-f101.1e100.net (142.250.115.101): icmp_seq=7 ttl=106 time=17.4 ms
1480 bytes from rq-in-f101.1e100.net (142.250.115.101): icmp_seq=8 ttl=106 time=14.4 ms
1480 bytes from rq-in-f101.1e100.net (142.250.115.101): icmp_seq=9 ttl=106 time=17.0 ms
1480 bytes from rq-in-f101.1e100.net (142.250.115.101): icmp_seq=10 ttl=106 time=18.8 ms

--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 14.393/16.873/18.818/1.429 ms
I do the same command but with opnsense.org and it still times out. Im wondering if maybe its not an MTU issue lmao. I do have ipv6 disabled. Could this be the issue ?

Code: [Select]

ping opnsense.org -c 10 -M do -s 1472
PING opnsense.org (178.162.131.118) 1472(1500) bytes of data.

--- opnsense.org ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9197ms

And there you have it!

As you can see, the problematic sites cannot be accessed by a payload of 1472 bytes corresponding to a MTU of 1500. That is your problem, not DNS.

The maximum physical MTU of the ethernet adapter has to be reduced by 4 bytes for VLANs, plus 8 bytes for PPPoE encapsulation, thus you will either have to reduce your WAN (net) MTU by these amounts. That is, you should reduce your MTU to 1492 or 1488 bytes.

Or you can hope that your ethernet driver (and your ISP) supports even more than 1500 bytes and set larger sizes for the lower layers beneath the logical WAN adapter in order to keep 1500 bytes.

But beware:

1. The OpnSense settings here are somewhat "wrong". If you have a WAN over PPPoE over VLAN, you "should" have to set WAN = 1500, pppoe0 = 1508, ONT = 1512, but in reality it works for me with these MTUs:

WAN: 1508 (this also sets pppoe0, which you cannot set directly, but really results in 1500 on WAN)
ONT (this means the physical ethernet port): 1512 if you have a VLAN for PPPoE, 1508 if not.

2. Set the above values in the web UI and then reboot - they cannot be changed via UI manipulations, because the order of application seems to be wrong that way.

Retry your tests afterwards.

And, as a courtesy to others, please change your thread title as it is obviously not DNS that is your problem. If your problem is fixed, add [SOLVED] to the thread title.