pfsense seems to delay loading websites after moving server



  • Hi All!

    We have installed a new server rack and moved everything in place. The setup is exactly the same, but since moving everything the internet seems to have a very slow reaction time.

    When we connect to a site or page that we haven't visited before, there seems to be a 15sec. pause as some sort of delay before actually getting down to business. Then the site loads as fast as it should. Speedtest for example also takes 16 seconds but then gives stats like 220Mbps down and ping 14ms. These stats are good of course.

    I suppose the pfSense is to blame. We have updated it to the newest version, we have restarted everything, but the matter still remains.

    Do you have any suggestions?

    Thank you very much in advance!



  • Why do you assume pfSense? Did you change something with it?



  • No, but all our internal connections work very fast and once the page is starting to load it goes very fast too. It just takes a while to start loading.

    I assume that everything internally is okay, and everything from our ISP is okay too. So pfSense is the only one who is in between who takes control of our internet usage. We have not changed anything in the configuration.


  • Rebel Alliance Global Moderator

    And if you go back to the same site.. How fast does it load?

    Out of the box pfsense resolves and does not forward - so depending on where the NS for for the domain your doing queries for the initial look up could take a few MS extra.

    Unless you have high latency connection or your isp is messing with your dns, etc.

    If you think it could be dns related, then you need to troubleshoot a specific domain your thinking your having issues with. But once something is looked up then it is cached locally just like in a forwarder, etc.

    Are you using packages like pfblocker or squid (proxy) etc.. etc..

    If unbound is restarting over and over again?? Its possible your running into that problem where you first query it its not working, and then query again its working and etc.. Your clients are using pfsense for dns I take it?



  • Yes, the clients have the pfSense as DNS. If we load the same site again, it goes much faster - if it is the same page. If we click through to another page, then it takes a while again. I have tried a lot of different (big) websites, so it doesn't seem a specific domain. A few ms extra is no big deal, we could live with that (say, most of our users won't notice a few ms extra), but 15 seconds is a lot in times like these. We have around 400 clients on normal working days, but due to the holidays they are not working now. That's why we moved everything now. But we have to get rid of the loading issue before they start again of course :-) !


  • Rebel Alliance Global Moderator

    well to test if its dns related.. Do a simple query for some domain from a client or on pfsense diag, dns - how fast does it respond?

    examples

    Here I did a dig for cnn.com took 68 ms first time, don't normally ever go to that site.. And you can tell from the TTL that came back that it had to be resolved.

    ;; QUESTION SECTION:
    ;www.cnn.com. IN A

    ;; ANSWER SECTION:
    www.cnn.com. 3600 IN CNAME turner-tls.map.fastly.net.
    turner-tls.map.fastly.net. 3600 IN A 151.101.185.67

    ;; AUTHORITY SECTION:
    fastly.net. 5679 IN NS ns1.fastly.net.
    fastly.net. 5679 IN NS ns2.fastly.net.
    fastly.net. 5679 IN NS ns3.fastly.net.
    fastly.net. 5679 IN NS ns4.fastly.net.

    ;; Query time: 68 msec
    ;; SERVER: 192.168.9.253#53(192.168.9.253)
    ;; WHEN: Sat Jul 14 07:53:09 Central Daylight Time 2018
    ;; MSG SIZE rcvd: 167

    I then looked it up again, and see it came back with 1 ms or pretty much instant from the cache on pfsense. If your talking full seconds for something to resolve seems more like you have possible problem with unbound restarting? Or your have some serious dns issues.

    ;; QUESTION SECTION:
    ;www.cnn.com. IN A

    ;; ANSWER SECTION:
    www.cnn.com. 3441 IN CNAME turner-tls.map.fastly.net.
    turner-tls.map.fastly.net. 3441 IN A 151.101.185.67

    ;; AUTHORITY SECTION:
    fastly.net. 5520 IN NS ns1.fastly.net.
    fastly.net. 5520 IN NS ns2.fastly.net.
    fastly.net. 5520 IN NS ns3.fastly.net.
    fastly.net. 5520 IN NS ns4.fastly.net.

    ;; Query time: 1 msec
    ;; SERVER: 192.168.9.253#53(192.168.9.253)
    ;; WHEN: Sat Jul 14 07:55:48 Central Daylight Time 2018
    ;; MSG SIZE rcvd: 167

    If the problem is dns related... Your going to have to actually check some specific FQDN to see if its dns or something else..



  • @bertdujardin said in pfsense seems to delay loading websites after moving server:

    Yes, the clients have the pfSense as DNS. If we load the same site again, it goes much faster - if it is the same page. If we click through to another page, then it takes a while again. I have tried a lot of different (big) websites, so it doesn't seem a specific domain. A few ms extra is no big deal, we could live with that (say, most of our users won't notice a few ms extra), but 15 seconds is a lot in times like these. We have around 400 clients on normal working days, but due to the holidays they are not working now. That's why we moved everything now. But we have to get rid of the loading issue before they start again of course :-) !

    Need a better picture of your network. What DNS servers is PFsense using? How are you managing those 400 clients? AD? If so, your clients should be using AD for DNS.

    Also, as johnpoz mentioned, it sounds like you're using the resolver. If you're looking for performance, disable the resolver and enable the forwarder.


  • Rebel Alliance Global Moderator

    @marvosa said in pfsense seems to delay loading websites after moving server:

    If you're looking for performance, disable the resolver and enable the forwarder.

    NO that is not true at all... Resolver is not going to be any slower than forwarding in the long run, and to be honest can be faster.. If your forwarding to NS X, and it takes 30ms say on average for every single query to pull something that is cached..

    While with resolver the authoritative ns for domain xyz.com might only be 10 ms away from you. And once you cache the NS for that domain lets say that is ttl of 24 hours, you never have to look that up again and next time you need something from domain xyz.com its only 10ms away vs your forwarded ns which is 30.. And that is only if it has it cached - if what your looking for is not cached - then it has to resolve it plus your 30ms to him.

    In some scenarios sure it might be faster to just forward to your ISP dns - if your on really bad connection and talking to ns all over the planet is problematic, or your isp does filtering of dns and prevents you from doing that, etc. Then ok you need to forward to your isp dns.

    But a blanket statement that forwarding is better performance than actual resolving is just not true.. Please do not spread such nonsense information... Users tend to parrot stuff they see and next thing you know everyone is spreading that FUD..

    Also keep in mind that unbound can do prefetching of stuff as it gets close to its TTL so this can actually drastically increase overall performance since the end client would never see upstream query for what they are looking for - the local client would see the local 1ms return time since its always locally there what they are looking for, etc..

    Resolving is almost always going to be better option vs forwarding.. Unless you have some specific sort of problem with doing that or special use case.. Blanket statements that one is faster or better than the other is not good practice without all the details of said environment you can not say it would be better to forward.



  • Thanks for all your replies! I will try to test them out today. I arrived at the office and when I opened the Active Directory Domain Services on the AD server, I got an error "Naming information cannot be located because: the specific domain eiter does not exist or could not be contacted". But that server ís the active directory server :-). Will look into this first... hopefully I can find or resolve this. This might be the cause of the delay also.



  • @johnpoz said in pfsense seems to delay loading websites after moving server:

    @marvosa said in pfsense seems to delay loading websites after moving server:

    If you're looking for performance, disable the resolver and enable the forwarder.

    NO that is not true at all... Resolver is not going to be any slower than forwarding in the long run, and to be honest can be faster.. If your forwarding to NS X, and it takes 30ms say on average for every single query to pull something that is cached..

    While with resolver the authoritative ns for domain xyz.com might only be 10 ms away from you. And once you cache the NS for that domain lets say that is ttl of 24 hours, you never have to look that up again and next time you need something from domain xyz.com its only 10ms away vs your forwarded ns which is 30.. And that is only if it has it cached - if what your looking for is not cached - then it has to resolve it plus your 30ms to him.

    In some scenarios sure it might be faster to just forward to your ISP dns - if your on really bad connection and talking to ns all over the planet is problematic, or your isp does filtering of dns and prevents you from doing that, etc. Then ok you need to forward to your isp dns.

    But a blanket statement that forwarding is better performance than actual resolving is just not true.. Please do not spread such nonsense information... Users tend to parrot stuff they see and next thing you know everyone is spreading that FUD..

    Also keep in mind that unbound can do prefetching of stuff as it gets close to its TTL so this can actually drastically increase overall performance since the end client would never see upstream query for what they are looking for - the local client would see the local 1ms return time since its always locally there what they are looking for, etc..

    Resolving is almost always going to be better option vs forwarding.. Unless you have some specific sort of problem with doing that or special use case.. Blanket statements that one is faster or better than the other is not good practice without all the details of said environment you can not say it would be better to forward.

    At a high level, I don't necessarily disagree with the message as I know what you're trying to say. However, in an attempt to ward off what is believed to be a blanket statement... I think it's important not to make blanket statements ;) :

    "Resolving is almost always going to be better option vs forwarding."

    I was simply offering an opinion and didn't want to write a book about DNS. The low-level details should be researched by the OP, so he/she can come to their own conclusions and implement what makes sense for their own environment.

    Resolver is not going to be any slower than forwarding in the long run, and to be honest can be faster

    In order to engage in a dialog about this, we now have to define, "better", "slower" and "faster". Which won't be efficient in this setting, but for example... if my ISP's DNS servers are in-network, only 5-7 hops away and respond within 5-15 ms vs. a root server on the internet that can be 10-20+ hops away and respond in some cases in 50-100+ ms... which one is "faster"? The answer is of course... it depends. One of those many factors is your user base... i.e. are you supporting a handful to a few hundred users or 30,000+?

    There typically is no one size fits all solution. All you can do is identify as many relevant variables as you can, define your priorities and test different implementations to determine which solution is more ideal for your defined set of priorities.

    In some scenarios sure it might be faster to just forward to your ISP dns - if your on really bad connection and talking to ns all over the planet is problematic, or your isp does filtering of dns and prevents you from doing that, etc. Then ok you need to forward to your isp dns.

    We can only account for our own experiences... for me, even on an install with gig fiber... the network just felt more responsive when forwarding vs resolving. But there were many factors at play... small user base, I'm not leveraging PFblockerNG, I'm not doing DNSSEC, etc....at the same time... no one should be taking that as gospel for every environment... they should be doing their own research and testing to make a decision about their own environment.

    Resolving is almost always going to be better option vs forwarding.. Unless you have some specific sort of problem with doing that or special use case.. Blanket statements that one is faster or better than the other is not good practice without all the details of said environment you can not say it would be better to forward.

    I touched on it earlier, the opening statement of this paragraph is just as much of a blanket statement as mine was thought to be. There's not much reason to drag this out much further...it will just extend the thread unnecessarily. For me, the bottom line is... this is a public forum where people all over the world are asked to give their advice based on opinion and experiences and it should be taken as such. Nothing that's posted here should be taken as absolute gospel for every install (unless it's a dev speaking to specific functionality within PFsense). Everyone should be doing their own research and testing to determine what's more ideal for each environment based on their own (or their customer's) priorities.


  • Rebel Alliance Global Moderator

    @johnpoz said in pfsense seems to delay loading websites after moving server:

    Resolving is almost always going to be better option vs forwarding.

    Your trying to say that is a blanket statement?

    No I do not agree at all. I clearly put used the word "almost" on purpose. You make some very good points - which should of been in your first point vs telling the user to disable resolver and use forwarder without any actual info from the OP to their environment.

    That is the point that rubbed me the wrong way to be honest. It screamed lack of understanding to me..

    Your example of root server being 50-100 ms away as your saying reason for resolver to be "slower" points to not actually understanding how a resolver works.

    The root only has to be queried to find the list of authoritative ns for the tld. Once that has gotten they ae all cached. Will not have to query for them again until the ttl expires. Then with prefetch user may never see this delay again.

    Same goes for every ns down the tree to get to the authoritative ns for the domain in question.

    My point was "overall" - looking at it from every aspect of dnssec being on by default, and not sending all your queries to some ISP for company like wanting your queries without providing any real benefit, etc. This has zero to do with using pfblocker or not..

    Overall - no matter how you look at it, almost always resolver is a better choice for anyone wanting to turn a fqdn to an IP.. Be it your 1 user or 10,000.. The advantages of resolving are almost always going to be well worth the "possible" slight delay in looking up xyz the first time. Then just forwarding to abc and hoping they have it cached. And then having to ask them again as soon as that ttl expires, etc.

    You brought up some valid discussion points about how to decide if forwarder "might" be better for some use case.. But your BLANKET statement and suggesting the user to turn off the resolver and forward for "performance" is just NONSENSE!!! And that was what I wanted to stop!!! Your not doing anyone any favors making such statements.