Need help with my VLAN firewall rules to make sure they do what I think they do

imthenachoman

So if I wanted to allow SSH from one VLAN to another VLAN, for the destination, would I put * net or * address? I assume * net since I want it to have access to all the devices on that destination VLAN?

johnpoz

My dig works fine.. My question - is why are they doing a directed query vs just doing a normal query for the TXT record.. from the one statement it seems that AD dns has some issue? Which is BS..

Do a query using whatever dns the OS is currently set to use - if that fails, then tell the user.. Hard coding some directed query to some specific NS is just utter BS.

That is exactly what applications are doing - to bypass pihole ;) That they would do the same thing is nuts.

johnpoz

@imthenachoman

Yes if you want want network X to talk to ssh to anything on network Y, then the dest would net Y..

imthenachoman

@johnpoz Rock on. Thanks!

bingo600

@johnpoz said in Need help with my VLAN firewall rules to make sure they do what I think they do:

Do a query using whatever dns the OS is currently set to use - if that fails, then tell the user.. Hard coding some directed query to some specific NS is just utter BS.

Seems like you're right for my OS (here linux mint)
Having pfSense unbound as DNS (that forwards to my bind9's)

$ dig +short -t txt versions.pi-hole.net 
"Raspbian=9,10 Ubuntu=16,18,20 Debian=9,10 Fedora=31,32 CentOS=7,8"

That they would do the same thing is nuts.

Yes ... Seems a bit contradictive to their own purpose

/Bingo

bingo600

Wonder if the pfSense DNS forward would have caught that one , and made the problem go away ....

johnpoz

Yeah a redirect would of worked here.. But what sucks is why and the F should you have to do that.. What is wrong with these people?

If you want to check some dns txt entry for something that is fine. But there is ZERO reason to direct that specifically to some ns..

Do your query - using whatever DNS the OS is pointed to... If it doesn't resolve - then post up an error.. Could not resolve xyz..

Hard coding trying to talk to some specific NS is not the way to go about it.. I just don't get how the makers of a software that allows users to control their own local dns thinks its a smart idea to bypass the local dns? WTF???

If you want to say point to some public dns, when NO local dns is provided - ok, I mean you are setting up dns software and all.. And you never know what some user might have borked up.. But if the box has local dns - bypassing that to check something is just plain wrong.

netblues

@johnpoz Its very simple.
Its called ad marketing.
The more people tend to use piholes, the more ad engines would query hard coded ip's for dns.

Needles to say that ipv6 has no way to redirect port 53 requests, making it all too difficult.
And I have seen mobile phones just doing an ipv6 dns request to google v6 dns to see if ipv6 connectivity exists.
If it doesn't succeed, ipv6 is switched off silently.

bingo600

@netblues

IMHO that doesn't make sense.

I was thinking maybe it was some kind of tracking, to get the "real" ip of the pihole machine. But since you do an update right after, you are going to reveal your ip to them anyway.
So that doesn't make sense either.

It seems to be a "klugde" to circumvent a problem that doesn't exist.

/Bingo

johnpoz

And I have seen mobile phones just doing an ipv6 dns request to google v6 dns to see if ipv6 connectivity exists.

Thats not what its doing - its doing a specific query to a specific IPv4 address.. I am curious if the query is done via hard coded IP, of if it has to lookup ns1.pihole.net first?

I'm thinking @bingo600 is on the right track with its some kludge to work around something that is not actually a problem..

A Former User

@netblues The ability to redirect ipv6 is in 2.5. Not sure if it's NAT6, but what else could it be...

Screen Shot 2020-12-25 at 15.11.43.png

It's in the documentation for the 2.5 release features (above), which points to here: https://redmine.pfsense.org/issues/10984

Not saying that's a good idea. But there it is...

bingo600

@johnpoz said in Need help with my VLAN firewall rules to make sure they do what I think they do:

I am curious if the query is done via hard coded IP, of if it has to lookup ns1.pihole.net first?

johnpoz

Well that is even more stupid then ;)

Just at a loss to WTF they are thinking doing something like that.. I understand it with something like a browser wanting your DNS..

But what is the point of such shenanigans from something like pihole? Just at a loss to understand the point of that..

A Former User

There is this:

https://github.com/pi-hole/pi-hole/issues/3694

That's concerning the installer.

I use a pi-hole and have never noticed that. I'll have to look and see if it's hitting that nameserver.

Why does that nameserver even exist? Do they intend you to forward to it instead of some other public nameserver...

johnpoz

Yeah @bingo600 had already linked to that.. They mention something about a problem with AD dns?? Which is nonsense MS dns can do TXT lookups..

bingo600

@johnpoz

And if you look at that git commit , they actually had it running wo. the ns1 stuff before.

Wonder if we should just rip the ns1 addition out of
/automated install/basic-install.sh

But it would be nicer if they removed it from the upstream git repos.

bingo600

@jwj

They are resolving the supported OS'es (during instal/update) via a DNS TXT record.

A Former User

@bingo600 OK, ummmm. I guess... I can think of other ways to do that... Are they doing two things at once. That the box can resolv some domain and getting the list of supported OS's in one go. Why...

johnpoz

Looking into a bit deeper something about MS dns not supporting cookie options.. But looks to me like the suggested work around was to just set +nocookie in the dig command.

No matter what lame reasoning they came up with - doing a directed query like that is not the way to do it if you ask me.

You could offer it up as a solution if the normal query failed, etc. But doing it in the background not a fan of.. Other option was to hard code the supported OS versions.. which would of been better options I think as well.

A Former User

@johnpoz Just go after some list they host somewhere on pi-hole.net.