Check the linked document on the tracepath equivalent on the Mac measuring the MTU from 1444 to 1508.
(ping -g 1444 -G 1508 -c 2 -h 1 -D tellmon.net)

https://www.dropbox.com/s/d6zznaypfb2uw49/Tracepath-tellmon_net.pdf?dl=0

No effect. Disabled ipv6 on my Mac with "networksetup -setv6off Wi-Fi" and rebooted. Still the same result.

traceroute to tellmon.net (79.161.150.134), 64 hops max, 72 byte packets
1 10.4.4.1 (10.4.4.1) 3.298 ms 1.915 ms 2.128 ms
2 192.36.162.9 (192.36.162.9) 2.676 ms 2.291 ms 2.279 ms
3 ilikr2-ge-0-0-3-1.ilik.net (192.71.20.21) 5.031 ms 509.863 ms 4.442 ms
4 telia-gw.ilik.net (192.71.20.25) 2.745 ms 2.808 ms 2.957 ms
5 193.181.252.67 (193.181.252.67) 3.065 ms 3.087 ms 2.987 ms
6 sesbww01-r12.ericsson.net (193.180.17.236) 2.984 ms 3.087 ms 3.340 ms
7 78.77.163.217 (78.77.163.217) 3.033 ms 4.801 ms 3.232 ms
8 s-b6-link.telia.net (80.91.250.43) 3.828 ms 4.179 ms 4.517 ms
9 level3-ic-155475-s-b2.c.telia.net (213.248.99.134) 42.783 ms 31.932 ms 31.786 ms
10 * ae-1-3.bear1.oslo2.level3.net (4.69.202.245) 28.569 ms 29.383 ms
11 ae-1-3.bear1.oslo2.level3.net (4.69.202.245) 28.428 ms 28.698 ms 28.451 ms
12 62.140.27.6 (62.140.27.6) 28.766 ms 28.999 ms 28.393 ms
13 216.213-167-114.customer.lyse.net (213.167.114.216) 29.179 ms 30.508 ms 31.162 ms
14 237.79-160-112.customer.lyse.net (79.160.112.237) 30.061 ms 28.175 ms 28.393 ms
15 2.79-160-49.customer.lyse.net (79.160.49.2) 29.889 ms 29.706 ms 29.963 ms
16 65.79-160-49.customer.lyse.net (79.160.49.65) 32.049 ms 31.082 ms 31.180 ms
17 203.79-160-49.customer.lyse.net (79.160.49.203) 31.332 ms 31.903 ms 31.391 ms
18 134.79-161-150.customer.lyse.net (79.161.150.134) 31.324 ms 31.248 ms 31.329 ms

I work for Ericsson and connects trough a demo network outside our corporate firewall (directly connected to Telia). See tracert in the next message.

The telnet reports the following:

mg11:~ Mats$ telnet tellmon.net 80
Trying 79.161.150.134...
telnet: connect to address 79.161.150.134: Operation timed out
Trying 2a01:79d:3e86:5a18:5945:87fd:f332:83c...
telnet: connect to address 2a01:79d:3e86:5a18:5945:87fd:f332:83c: No route to host
telnet: Unable to connect to remote host

I do agree that it's a minor problem, but nevertheless interesting to dig into. I have the possibility to select another network where this works well. But as strange it is for you that 1500 users can connect without problem, it is equally strange that we (the three users) can't access your sites from our side. And only your sites. Absolutely all other sites I have tested works as expected (as noted, we can traceroute to tellmon.net, but the web server won't give us it's content).

If the error is in our domain or in yours we probably never will find out unless we continue to work together, but if you find it to much of a hassle I will stop the work initiated and move to another network when I need to connect to tellmon.net.

Maybe we are getting closer to the problem? More from the network guru:

---

I do not have any experience of pfSense firewalls, but looking at the web it seems like pfSense has a known problem with PMTUD in conjunction with NAT. My suggestion is to try the setting the kernel parameter “net.inet.icmp.reply_from_interface=1” according to the following web site to see if that fixes the problem:

https://plone.lucidsolutions.co.nz/networking/pfsense/pfsense-v2.1.5-pmtud-issue-with-ipv4-and-nat
---

More from the tech:

This MTU test only tests the MTU on the connection between “www.letmecheck.it” and “paks.no”, not from my client to “paks.no”, i.e. I will get the same result as you.

I still think it’s PMTUD functionality that is broken, the question is which node(s) that breaks it… Is 79.161.150.134 the “real” address of the web server, or it is hidden behind NAT on the FW? What kind of web server are you running?

MTU test :

Let me Test it

28

Online MTU test allows you to test the maximum MTU size from our host to your destination. To check your MTU, simply provide your IP or DNS hostname. We will test the PMTU (Path Maximum Transfer Unit) aka maximum MTU size (unfragmented) between our host and your destination, most likely the outside of your router or firewall.
More info: Wikipedia

This online MTU test is in BETA. Please let us know, using our contact form, if you find any irregularities.

Sending 32 bytes to Paks.no <- not fragmented Sending 750 bytes to Paks.no <- not fragmented Sending 1125 bytes to Paks.no <- not fragmented Sending 1313 bytes to Paks.no <- not fragmented Sending 1407 bytes to Paks.no <- not fragmented Sending 1454 bytes to Paks.no <- not fragmented Sending 1478 bytes to Paks.no <- FRAGMENTED! Sending 1466 bytes to Paks.no <- not fragmented Sending 1472 bytes to Paks.no <- not fragmented Sending 1475 bytes to Paks.no <- FRAGMENTED! Sending 1473 bytes to Paks.no <- FRAGMENTED! Sending 1472 bytes to Paks.no <- not fragmented From the tests we did, we can assume that 1472 bytes is the largest unfragmented packet size. The MTU size would be 1500, made up from 1472 payload and 28 ICMP/IP Headers and payload information. 

The maximum MTU size for Paks.no is: 1500
 NB: The Internet Protocol requires that hosts must be able to process IP datagrams of at least
576 bytes (for IPv4) or 1280 bytes (for IPv6)

 

And their reply: :-)

I do not think it’s the actual MTU on the FW that should be changed. 1500 bytes is standard. It seems more like the TCP Path MTU Discovery (PMTUD) isn’t working, i.e. the function to discover the MTU of the complete path between the server and the client. PMTUD is using ICMP, so I think a first step can be to make sure the FW does not block incoming ICMP type 3 code 4 messages (i.e. “Destination Unreachable, Fragmentation Needed and Don’t Fragment was Set”. These ICMP messages must be able to reach the webserver so it can adjust the packet size accordingly.

From our network techs (I guess you know Swedish Pål, so I won't translate it):

"Har nu gjort diverse tester och enligt vad jag kan se så är det troligtvis storleken på paketen från ”paks.no” som är problemet. När man kör från vårt demonät är MTU-storleken mindre än från t ex ECN (anledningen till detta är en annan historia…), och i normala fall så anpassas paketstorleken efter detta. Jämför jag t ex storleken på mottagna paket från ”www.dn.se” till en klient på demonätet med en klient på ECN, så ser jag att paketen är mindre som går till klienten på demonätet. Av någon anledning verkar dock inte denna anpassning göras när man kopplar upp sig mot ”paks.no”, vilket gör att paketen inte kommer fram till klienten.