Approach to troubleshoot a very slow connection to a single website. - solved
-
Attempt number 2
2.5.0-DEVELOPMENT (amd64)
built on Tue Nov 19 18:35:12 EST 2019I am consistently unable to reach a specific public website from behind my pfSense firewall. It works fine via LTE, or if I bypass my pfsense router. It should load in less than 1 second, but it takes minutes and never appears to complete.
It does not seem to be DNS as I can resolve the hostname via the client device and the page does partially load
ping is not useful as this host appears to block icmp.no pfblocker package loaded,
I am not sure what to look at next.
looking at the firewall rules / LAN, I see the three base rules (anti-lockout, default allow LAN ipv4 and ipv6)
-
could be MTU, you need to analyze the traffic with packet capture / wireshark
-
What is the web site ?
-
@NogBadTheBad
https://meet.alberta.ca
It is cisco virtual meeting VC for a customer of mine.
it loads virtually instantly everywhere I try it other than through my pfsense firewall. -
Contact your ISP?
What are you running pfSense on?
Your not in a double NAT are you? -
Looks fine from behind my pfSense router:-
-
Try ticking "IP Do-Not-Fragment compatibility"
-
@Pippin I will look that up and test, thank you for the suggestion.
-
@ikifar I don’t think it’s the ISP because when I bypass the pfSense firewall by plugging the test PC directly to the ISP link (thus on a public IP address) the problem goes away.
-
@Pippin said in Approach to troubleshoot a very slow connection to a single website.:
Try ticking "IP Do-Not-Fragment compatibility"
I just looked that up in the docs and found this:
"This option is a workaround for operating systems that generate fragmented packets with the don’t fragment (DF) bit set. Linux NFS (Network File System) is known to do this, as well as some VoIP systems.
When this option is enabled, the firewall will not drop these malformed packets but instead clear the don’t fragment bit. The firewall will also randomize the IP identification field of outgoing packets to compensate for operating systems that set the DF bit but set a zero IP identification header field."
Given an OS fragmenting before sending and setting the DNF is entirely normal, doesn't this reflect a bug with pfSense/FreeBSD? No router should be changing that flag.
-
I don't know if it is a bug.
It solved my problem described in the link so I just had a hunch:
https://forum.netgate.com/topic/138124/posting-to-a-forum-issue/21 -
@ikifar no double NAT, and dedicated hardware
https://www.newegg.ca/gigabyte-ga-c1007un-d-mini-itx/p/N82E16813128598 -
@mervincm Ok well I am able to visit the site here at home and I am running pfSense, I assume you don't have any caching so that can't be the issue. Maybe try the file system check to get to this in the pfsense console select the option to reboot (5) then select the option to do a filesystem check which should be F
-
@mervincm said in Approach to troubleshoot a very slow connection to a single website.:
(thus on a public IP address) the problem goes away.
But this public ip address changes right... Do what @NogBadTheBad did and lets see what your browser says about the loading and where the problem is..
-
@Pippin thanks for the hint but it didn't make a difference.
-
@johnpoz
I happen to have a mac so I pulled up safari - web inspector and I get a the same issue. It records for about 12 seconds and stops thinking the page is loaded, but it's a good minute at least from complete.
-
and here is what it looks like from the same system, but connected to LTE
and directly to my ISP
-
@mervincm Well do you have anything like squid that could be breaking https
-
@ikifar
the only packages I have installed are acme,bandwidthd,openvpn-client-export,RRD_SummaryI might have run snort on this install but that would have been a couple years back.
-
@mervincm so snort is definitely not on the system then
-
@mervincm does the website work as expected on the stable version of pfSense in your setup?
-
@ikifar I will try a fresh install on a spare HDD on the weekend if I can't get this going by then.
-
On a spare test system I installed stable version of pfsense, created a fresh xml backup on main system, restored it to the test system, and the issue was gone.
Wondering if it was a stable 2.4 vs 2.5 issue, I then did an in-place update to the test system, taking it to 2.5 dev. The issue was still gone.
I am not sure if it is a hardware issue, or just a currupt install, but the next step will be to blow away my install on the primary system, restore from backup, and see what happens.
-
@mervincm
Well it appears to be hardware specific. I reinstalled from scratch today's dev build on the primary system hw and without even restoring my config, the problem is there. -
Hardware makes no sense to be honest.. More likely you got a different connection from your isp, because when you changed to different system your mac address would be different and you would get a different IP.
If it was hardware - why would it not be on like all sites.. Your just moving packets, pfsense doesn't even know what is the packets. It just moves them.. Pfsense doesn't know what site your talking to..
-
@johnpoz None of this is really making any sense to me to be honest. You are correct I am getting a different public ip to one system and thus there will be somewhat different "connection"
I can't imagine it would be significantly different but ...
I suppose I can replace the mac in the working device with the mac from the problem device, get the same ip and see if the problem follows the mac. -
@johnpoz Either that or possibly the reinstall of pfSense
-
If something wrong with pfsense, why is it only presenting itself with this 1 site?
-
@johnpoz and I did reinstall it from scratch anyway. Absolutely vanilla install and the issue was there. It isn’t an obvious pfsense issue, I agree. I am left with unlikely scenarios more testing is required, starting with the Mac swap
-
@mervincm Did your IP adress change after the reinstall?
-
@ikifar I don't think so.
That being said ... I got back to troubleshooting today.
Test system, configured as above (fresh install yesterday of 2.4.4p3 then my config restores, then up to yesterday's daily)
It continues to function as it was yesterdayPrimary system, configured as above (fresh install yesterday of yesterday's daily, vanilla config (not even walk through setup wizard yet)
It now works, a direct contrast to yesterday! and I notice my ISP assigned me a new IP (to same physical nic with same non-spoofed mac)It looks like my ISP is in fact the problem here. and for some reason, they assigned me a new IP and the issue is gone. if they found an issue and fixed it, or if I just got a different IP because of the luck of the draw I have no idea. My ISP is the phone company around here (Telus) and there is zero chance I will be able to talk to someone who has knowledge at this level.
This can be considered closed.