Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Alex Atkin UK]

From what I've seen, Netgate generally recommend using Unbound with full resolution so you get a pure DNS solution.

DNS on your end would have no impact on the BQM though as that is pinging directly to your IP.

If your upstream was maxing out, I'd expect some dropped ping packets.  Although I wouldn't expect a video call to do that, I don't really trust VM to not be heavily contended upstream.

[exdirectory]

I have had to change my DNS servers to 1.1.1.1 and 1.0.0.1.

Just using 8.8.8.8 I could not access some sites, such as thinkbroadband.com

[exdirectory]

DNS on your end would have no impact on the BQM though as that is pinging directly to your IP.

Alex, from my somewhat limited understanding that is the point of this thread. It does not make sense but there is some problem between pfSense, VM and SH3 in modem mode that for some reason causes weird stuff to happen on BQM.

I am now following Ronskis solution for 24 hours to see if my BQM improves.

Since changing only from router to modem mode+pfSense factory already my BQM has changed (see previous post) which already seems strange and unexplainable, by me anyway.

[exdirectory]

From what I've seen, Netgate generally recommend using Unbound with full resolution so you get a pure DNS solution.

Alex, are you suggesting I need to turn off this setting to get pure a DNS solution?

System -> General Setup -> DNS Server Settings -> Allow DNS server list to be overridden by DHCP/PPP on WAN

[Alex Atkin UK]

Alex, are you suggesting I need to turn off this setting to get pure a DNS solution?

System -> General Setup -> DNS Server Settings -> Allow DNS server list to be overridden by DHCP/PPP on WAN

If you're going to define your own DNS servers or use the resolver then yes I'd have that turned off to avoid it adding or overriding with the ISP defined ones.

[exdirectory]

If you're going to define your own DNS servers or use the resolver then yes I'd have that turned off to avoid it adding or overriding with the ISP defined ones.

Cheers. Now turned off. My DNS settings look like this now.

Am assuming I can leave to None as single WAN and am not using TLS for DNS.

[Alex Atkin UK]

Cheers. Now turned off. My DNS settings look like this now.

Am assuming I can leave to None as single WAN and am not using TLS for DNS.

Well you CAN use TLS on those servers, its slower but prevents your ISP from snooping on your requests.  Or alternatively don't forward at all, do full resolution (what DNS Resolver does by default).

[PhilipD]

So this is interesting (to me anyway), I would have thought that only changing from router to modem mode, there should be no difference. But clearly the two graphs are quite different.

I have been using the internet all day working from home, 3 longish video calls.

If it was not for the red elements I would call it a day and suggest this might be the best I can get.

Next step is to try the DNS change, I will read back through the thread to find out what I need to do.

I never seem to have two days looking the same on my BQMs so you will see some differences, the point being is are they showing a similar trend and I would say yes on yours, which are typical Virgin Media, however you are getting packet loss on the more recent.  DNS doesn't cause packet loss, too much time is spent worrying about DNS, it's important, but it simply uses a tiny part of the connection.  If DNS isn't working you will find you can't get to web pages at all and will get a DNS type of error reported by the web browser, if it works, it is used just once when you visit a web page or use a service, then plays no further part in the connection. 

Using the built in DNS Resolver is by far the best option and using something like DNS Benchmark from GRC.com shows it is 100% reliable on pfSense and faster than any public ones, plus it is more private as it is your own DNS server hidden locally on your own network.

Your packet loss is likely being caused external to pfSense and showing an issue on the Virgin network or their modem, it might be fine another day.  Virgin Media has never been known for it's good looking BQM charts, all you can hope for is that things seem to work okay and try and ignore the charts 

Regards

Phil

[Ronski]

Phil, you need to accept that there was/is something going on with the SH3 in modem mode and pfSense DNS combination, I and others on VM forum's proved this at the time. The difference between running the SH3 in router mode and in modem mode with pfSense was night and day and the same goes for using a different router, only when using SH3 in modem mode with pfSense was the problem present, and it affected browsing.

There shouldn't be, but there is/was, until I made the changes detailed in this thread my browsing experience was poor and my BQM was appalling even by VM standards.

My graphs were much worse than exdirectory's, so I've no idea if they are experiencing the same issue or not, but the problem did exist for me and other users.

[exdirectory]

My graphs were much worse than exdirectory's, so I've no idea if they are experiencing the same issue or not, but the problem did exist for me and other users.

Ronski, my experiences back in May time were much worse on modem mode. Two things have changed that may have improved this as yesterday I had no visible outages to me unlike in May which was hourly.

1, Recently I shortened the cable and re-did the coax cable to VM SH3, I was seeing low power on one channel, this seems to have sorted this and I no longer get pre RS errors.
2, I upgraded to 2.4.5

Here is my May graph. So light and day from graph yesterday but now I gained packet loss!

[PhilipD]

Hi

Phil, you need to accept that there was/is something going on with the SH3 in modem mode and pfSense DNS combination, I and others on VM forum's proved this at the time. The difference between running the SH3 in router mode and in modem mode with pfSense was night and day and the same goes for using a different router, only when using SH3 in modem mode with pfSense was the problem present, and it affected browsing.

There shouldn't be, but there is/was, until I made the changes detailed in this thread my browsing experience was poor and my BQM was appalling even by VM standards.

My graphs were much worse than exdirectory's, so I've no idea if they are experiencing the same issue or not, but the problem did exist for me and other users.

I do accept there is a problem but don't agree with this being a fix.  Why is the DNS Resolver seemingly causing a problem when all it is doing is going out to authoritative servers (and not all the time once they are cached) with DNS requests?  Has someone run a package capture to see what is happening or what the differences are between the two modes?  What if you run a DNS Resolver on your network that is separate to pfSense (like that in Windows Server or an open source option), does that still trigger the problem? 

Turning off something as fundamental as a DNS Resolver on your network and switching to a forwarder in order to have a working internet connection is not a fix, just indicative of a serious issue somewhere on VMs network or with the modem.

What next?  Will the next version of pfSense trigger the same issue with your only option to turn off something else, then something else, then something else until you might as well not be using pfSense at all and the only option is to use the VM supplied kit?

It doesn't really worry me as I'm unlikely to ever be a VM customer, but I like pfSense and can't believe it is the cause of the issue and just like a puzzle and getting a proper answer 

Regards

Phil

[Ronski]

You seemed to imply that DNS won't be causing the problems because the packets are tiny, you didn't say a work around was the wrong way to fix it.

I agree it's a work around, but work it does and my families browsing experience is so much better for it. Unfortunately I am not technically minded enough nor have the time to learn, and when I do I soon forget, so I'm not willing to nail down the cause of it, if the cause was PfSense there would be a slim chance of getting it fixed, if it's the hubs firmware which is more likely there is zero chance of getting it fixed. It seemed to coincide with a hub firmware update.

It's also far beyond my capability and I required the help of many people on here and VM forum's to sort out the work around. I find pfSense rather difficult to get on with, and information hard to find, there's just too much of it, I had a much better experience setting up a Draytek router at work, so if pfSense became too much of an issue whether it's own fault or not I'd switch to a Draytek device, it does pretty much everything I need. At the moment I have to use VM to get a decent speed, that will hopefully change soon as our area is getting FTTP, once live I'll see what options I have.

[Ronski]

Ronski, my experiences back in May time were much worse on modem mode. Two things have changed that may have improved this as yesterday I had no visible outages to me unlike in May which was hourly.

1, Recently I shortened the cable and re-did the coax cable to VM SH3, I was seeing low power on one channel, this seems to have sorted this and I no longer get pre RS errors.
2, I upgraded to 2.4.5

Here is my May graph. So light and day from graph yesterday but now I gained packet loss!

I don't see any red indicating packet loss, just a busy connection. I occasionally get some red packet loss, but not very often. It may well be worth checking devices on the network, a few months ago my browsing experience went bad, thought the problem had returned, turned out to be an Amazon Fire TV that was having a melt down, no idea what it was doing but it was extremely hot, turned it off and everything went back to normal.

[Chrysalis]

Philip you asked what the difference is, its more than you think.

A public resolver like google dns or cloudflare will have lots and lots of traffic, meaning all widely used hostnames will rarely be served to you cold, they will almost always be from their cache.

If you are requesting a uncached hostname the following may happen.

You have to determine the authoritative name server for the domain.  Thats the first request.
Then you have to resolve the ip of the nameserver hostname e.g. ns1.superduperhosting.com, sometimes this might need a root dns server lookup for glue record.
Then maybe you finally at this point you can send a dns request to the authoritive server for the ip of the hostname you looking up, typically these are not on cdn's so might be high latency.

All that just for one hostname, many websites have several to resolve.

Now days many main stream servers use very low TTL values so results dont stay cached for long, on a home router, most of the time, you wont get a cached record as it will expire before you click again, this is mitigated either by enforcing high min TTL's or using a feature called 'serve expired' an option you can see inside pfSense.

If you using something like cloudflare dns, the vast majority of the time you just request the hostname and you served from its cache, and they will have a local dns node to serve your requests from so low latency as well.

The best combination for a home user is dns resolver with forwarding enabled, and have serve expired on.  Also due to bad behaviour on pfSense turn off the dynamic DHPC registration.  Also be aware if you using pfblockerng, the frequency of its updates affect when the DNS resolver is reloaded.

I hope this helps you understand the pros and cons more of direct dns lookups vs using forwarders.

Also in regards to Alex comment most of netgate's recommendations are more suited to enterprise users.  The pre tuning for things like super high mbuf's and the direct dns resolution aimed at a different type of usage.

[PhilipD]

Hi

Philip you asked what the difference is, its more than you think.

A public resolver like google dns or cloudflare will have lots and lots of traffic, meaning all widely used hostnames will rarely be served to you cold, they will almost always be from their cache.

I know how it works, but typically for most of us we will visit similar websites during our day.  pfSense will also cache all the results, it will also cache lookups to find the various authoritative servers/name servers. Regardless if pfSense needs to do a few lookups more initially for a new address, we are still talking about a handful of packets, and the data transferred is nothing, and the processing is nothing. 

As evidence to this as I posted further up, running a DNS benchmark that is making thousands of DNS lookups against the pfSense resolver for random addresses I certainly would never have visited and so would not be cached locally, the benchmark shows the fastest DNS server is my pfSense, with Google etc coming further down the list, even though Google shows a small percentage of cached results, less than you might expect on the random list of addresses the benchmark picks, pfSense is by far the fastest, responds 100% of the time, and was 100% error free.

So whilst that benchmark is running, hammering pfSense DNS Resolver, also hammering a dozen or more other DNS servers to benchmark against all at the same time, pfSense shows nothing to indicate extra loading, a continuous ping to the BBC shows every ping still taking 8ms, so no change or jitter in latency, and the BQM chart shows nothing different during the period of the test.  Ergo, DNS is nothing, it places very little demand on a home network, uses next to no CPU cycles, and the data it uses is insignificant.

A DNS Resolver in pfSense is not a resource hog and is not the cause of slowing things down, that is ludicrous to suggest and shows a lack of appreciation to what DNS is technically, that is tiny packets of data and the network is dealing with more traffic processing the BQM chart pings from Thinkbroadband than it does dealing with DNS resolution! pfSense works fine across the planet using its own DNS Resolver, but there is something odd happening when the resolver is enabled on Virgin.

Regards

Phil

Edit, evidence is better than assumptions. I've attached the DNS Result from another test that did as many DNS lookups in 5 minutes than most people will do in a lifetime!  pfSense shows CPU around 5% (normal idle amount) so loading unchanged and even the CPU didn't feel the need to throttle up from it's minimum 600MHz (APU2 motherboard).  The test result is pfSense is the fastest.  Feel free to download and do the same test from GRC.com and then peer review if you like.