pfsense blocking certain/some sites

Gurveer

@johnpoz how to forward this portal2.bsnl.in or portal.bsnl.in to 8.8.8.8 or 1.1.1.1? Please help

Gertjan

First :

Then :

Save and then Apply.

Gurveer

@johnpoz @bingo600 @Gertjan @rcoleman-netgate @stephenw10 @viragomann thanks mine was set to automatic value based interface mtu changed to unbound default sites started working flawlessly after which i enabled dns forwarding too. Huge thanks you guys

bingo600

@gurveer
Why do you use forward, and not just let pfSense resolve ???
Any specific reason or ???

Another +1 for @johnpoz

Gertjan

@bingo600 said in pfsense blocking certain/some sites:

Any specific reason or ???

Something like : The name servers involved being unable to communicate over TCP (so these names servers 'break' DNS) + a total fxckxd up DNSSEC = his unbound resolver refuses to work.

All this said, something amazing is happening : I can look at the site :

and I'm not forwarding, I'm using the pfSense resolver unbound with default settings + dnssec hardening.
So, I tend to think 'something' is not good on @Gurveer's side.
If my pfSense + unbound resolvers works
It should also work for @Gurveer.

stephenw10

I think Johnpoz meant to add a domain override for bsnl.in to 8.8.8.8 or similar so everything else is still resolved directly rather than use forwarding mode.

johnpoz

@stephenw10 exactly..

But did he mess with his udp size? If he did he prob doesn't need to forward and this domain would work.

Gurveer

@bingo600 nothing just did on whim it is fine to run forwarder ?

johnpoz

@bingo600 said in pfsense blocking certain/some sites:

I doubt it had been messed with by OP

You would think that huh - but I find that quite often users click on shit all the time.. Until actually see screenshot or a sniff showing it using 4096, etc. You have no idea what is actually happening other than that ns isn't answering on tcp, and it sends back large info that could exceed 512, etc.

stephenw10

Well I have two machines here hitting this and I'm pretty certain I never changed the buffer size. Both are set to the default (auto based on MTU). Both have 1500B WANs.

Just digging to see what the actual buffer size is but I don't know where that is...yet

stephenw10

Looks to be 512 in unbound.conf...

stephenw10

Mmm, and on working devices:

edns-buffer-size: 1432

That's in 22.11 so newer Unbound version

johnpoz

@stephenw10 that was changed from default, see my screenshot shows 4096 as default.. on 22.05

I had not read that unbound was changing their default settings. But sure pfsense could, default for unbound I think is 1232, I think that came out of a flag day for dns back a couple of years ago.

But that can be overridden with that actual bufsize setting, etc. But the max-udp-size: I believe defaults to 4096.

But if your having issues with a NS that is not answering on tcp, it would behoove you to validate what your settings are, etc. To make sure they are appropriate for your network connection.

stephenw10

That isn't the pfSense default config though. At least not any longer. It should be Auto based on MTU there since 2.5 https://redmine.pfsense.org/issues/10293
If that's a machine that was upgraded from before that it might still be 'Unbound default'. Several of mine are which is why they weren't hitting it.
Still can;t see why these two machines I have ended up at 512 when all their interfaces are 1500B MTU. However I'm not seeing it on any 22.11 test box so it might be moot.

Steve

johnpoz

@stephenw10 I agree with a setting based on mtu is prob the best scenario..

IMHO the problem here is that the NS for this domain doesn't answer on tcp - which is going to cause problems for sure..

I see a few options here, make sure unbound is using an appropriate size for your network and its connection. If settings are correct, and still having issue then the hack/workaround for such a domain would be to forward for that "specific" domain to remove your connections issue with large udp.

The nuclear option sure is to forward all your queries and let them worry about it ;) But to me that is burning down the house to kill a spider..

stephenw10

Yes, absolutely the NS should respond to TCP and the fact it doesn't is broken behaviour.

It's interesting that it's shown this edns buffer issue though. It looks like there probably is a bug there because it shouldn't be 512 in a default config where all the NICs are 1500B MTU.

It's also interesting that it still failed for me with DNSSec disabled where queries are much smaller.

Steve

Gertjan

These are the NS :

[22.05-RELEASE][root@pfSense.xxxxx.net]/root: dig bsnl.in NS +short
ns11.bsnl.in.
ns12.bsnl.in.

Not good :

[22.05-RELEASE][root@pfSense.xxxxx.net]/root: dig portal2.bsnl.in @ns11.bsnl.in +tcp
;; Connection to 218.248.240.178#53(218.248.240.178) for portal2.bsnl.in failed: connection refused.

Who is 218.248.240.178 :

[22.05-RELEASE][root@pfSense.xxxxx.net]/root: host 218.248.240.178
178.240.248.218.in-addr.arpa domain name pointer ns11.bsnl.in.gstkarnataka.gov.in.
178.240.248.218.in-addr.arpa domain name pointer ns11.bsnl.in.
178.240.248.218.in-addr.arpa domain name pointer ns11.bsnl.in.gvmc.gov.in.
178.240.248.218.in-addr.arpa domain name pointer ns11.bsnl.in.eofficeharyana.gov.in.

Multiple reverses .... hummm.
It's "ns11.bsnl.in." who was refusing to answer.

Good :

[22.05-RELEASE][root@pfSense.xxxxx.net]/root: dig www.test-domaine.fr @ns1.test-domaine.fr +tcp +short
5.196.43.182

@Gurveer : go have a talk with those who manage your ns11.bsnl.in. and ns12.bsnl.in.

johnpoz

@gertjan said in pfsense blocking certain/some sites:

talk with those who manage your ns11.bsnl.in. and ns12.bsnl.in.

I don't think he has anything to do with the site, I think he is just a user trying to get to the site..

Gertjan

@johnpoz

Maybe.
But some one has to tell some one that something isn't right.
If in this list with persons there is no place for @Gurveer, then the issue stops.

johnpoz

@stephenw10 said in pfsense blocking certain/some sites:

DNSSec disabled where queries are much smaller.

But it is set to hand back servers with every query, which increases the size even with no dnssec, now that size is not anywhere close to 512..

While its easy to have large udp with dnssec, its not impossible to go over 512 without it.

The bottom line is those name servers are borked in my professional opinion - borked being a very technical term ;)