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

netblues

LAN address is the address of the interface of the pfSense to the LAN. (ie. 192.168.1.1/32)
LAN subnet is the subnet attached to this interface. (ie. 192.168.1.0/24)

As for caching of dns, well, unbound is bound to all running interfaces, so this will happen by default, without any redirects.

If you are using pfblockerng, then yes, you probably want some control over external dns access

Having total control is nice, but it also means to be constantly adjusting things.
Its nice as an exercise, but doing that in a home network with demanding users (aka kids) is kinda of a full time job.

bingo600

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

So, my understanding is, LAN net is 192.168.1.1, right? That is also what clients on LAN get for the DNS server. So when said clients want to do a DNS query they send it to 192.168.1.1:53. Am I right so far?

So if I want traffic from the LAN clients coming through LAN net to be able to make DNS queries to 192.168.1.1:53, or LAN net:53, then I need a FW rule saying traffic from LAN net to LAN net:53 is allowed. Right?

Re: Lan net vs Lan address (pulldown selections)
Lan address is the specific interface adresss : ie. 192.168.1.1
Lan net is the defined network : ie. 192.168.1.0/24

For allowing any (on the Lan) to send DNS req. to the interface i would do.

IF : LAN
AF: IPv4
Proto: TCP/UDP
SRC: Lan net
Dest: Lan address (Only matches The interface ip)
Port: DNS

Allow Lan Net to Lan Net , would only be effective if the dest-ip was the Lan interface, as all other packets sent between devices on the same "subnet" would be sent directly between the devices. And not pass the firewall. Hence the rule would be better indicating : LanNet to Lan address (interface ip)

Btw: I totally agree with @netblues , that only allowing specific permits , on a "general use" subnet. Would be a steady job.

bingo600

Btw:
Only allow DNS requests to "Lan address" seems a bit contradictive , with the purpose of the "DNS forward rule".

The forward rule (Catch all DNS) , is usually made in order to catch programs/apps that uses "hardcoded" or custom DNS servers. Ie. a Google app that tried to resolve DNS via 8.8.8.8.

If DNS to "any" was allowed (while the DNS forward rule was in place) , the request to 8.8.8.8 would be rewritten to 127.0.0.1 once the package was entering the pfSense , and the APP would still get a DNS answer (from pfSense).

If you only allow DNS to the LAN address (interface) the request to 8.8.8.8 would just be dropped.

It depends on what you want .....

I only allow DNS to my "interface" , and all(most) all apps that tries a "foreign" DNS , will fall back to the DNS given by DHCP.

But it will break Ie. PI-Hole updates , as they now relies on SRV records from a specific DNS server , to inform about supported OS'es. And the forward "trick" would also break it.

I think i have 2..3 apps that are misbehaving if not allowed to their native DNS. I can live with those limitations.

/Bingo

johnpoz

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

as they now relies on SRV records from a specific DNS server

huh/what?? That is not how it works..

Your saying pihole has to talk to a specific NS or it can't update??

johnpoz

@imthenachoman

Not saying you can not stop something from talking to DNS you don't want it to - my point is redirection of traffic hiding from the client that it not talking to who it thinks it is talking to is not good practice.

You sure and the F would not like it if your isp did it to you.. While its your network and you can do what you want. It amounts to the pot calling the kettle.

If you don't want something talking to outside dns, then block it sure.. But redirection is not good idea if you ask me..

bingo600

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

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

as they now relies on SRV records from a specific DNS server

huh/what?? That is not how it works..

Your saying pihole has to talk to a specific NS or it can't update??

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

Somehow it won't (in default config) accept my DEB10 as a valid OS , unless i permit access to : ns1.pi-hole.net / 185.136.96.96 (for Update)

A workaround would be this : PIHOLE_SKIP_OS_CHECK=true

So DNS is being (mis)Used for lot's of tricks.

And it is how it works (for pihole update)

Edit:
pihole-check Git commmit
https://github.com/pi-hole/pi-hole/commit/0ff32c3629220f386a45c14d8982aaaf128aa47f

I didn't dig deeper , as i just did a temporary permit during the update.

Edit2: Seems to be a TXT not SRV (my bad)

/Bingo

johnpoz

Yeah I agree with the comments on that - that is a HORRIBLE solution to an issue of some local dns sucking..

Looks like they are changing it to output info, for those that block dns..

Since when does MS dns fail to return txt records? I don't see any SRV mentioned in that?

bingo600

@johnpoz
My bad assumed they used a SRV not a TXT

bingo600

My main dns'es are two local bind9 servers.
Everything else , including pihole & unbound uses those

Primary reason i had them running before pfSense was installed.
Use them for DNS & DHCP , and get the full ISC features.

And i can do dynamic DHCP updates wo. the dreaded unbound dead time

johnpoz

My pihole is currently up to date..

root@pi-hole:/home/pi# pihole -up
  [i] Checking for updates...
  [i] Pi-hole Core:     up to date
  [i] Web Interface:    up to date
  [i] FTL:              up to date

  [✓] Everything is up to date!
root@pi-hole:/home/pi#

But I will for sure try and test this next time an update is out.. I have just added a block any other dns on the piholes vlan.. I was blocking dot and doh.. It didn't attempt to check any other dns when I asked it to see if update - but maybe it only does that if there is an update?

imthenachoman

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

Re: Lan net vs Lan address (pulldown selections)
Lan address is the specific interface adresss : ie. 192.168.1.1

Oh! I see my mistake now.

Lan net is the defined network : ie. 192.168.1.0/24
For allowing any (on the Lan) to send DNS req. to the interface i would do.
IF : LAN
AF: IPv4
Proto: TCP/UDP
SRC: Lan net
Dest: Lan address (Only matches The interface ip)
Port: DNS

Awesome. Thank you!

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

If DNS to "any" was allowed (while the DNS forward rule was in place) , the request to 8.8.8.8 would be rewritten to 127.0.0.1 once the package was entering the pfSense , and the APP would still get a DNS answer (from pfSense).

Wouldn't a port forward rule take care of this? Any request from a client on :53 gets redirected to 127.0.0.1 (pfSense)?

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

Not saying you can not stop something from talking to DNS you don't want it to - my point is redirection of traffic hiding from the client that it not talking to who it thinks it is talking to is not good practice.

Totally fair. But as I am just starting out in my journey, I will set it like this for a while and see how ti works. I'll redo everything in a few months anyway -- once I understand things better -- and then I'll see how I set up my DNS.

--

I really do appreciate all of the time y'all have been putting in to help me. I am a big fan/supporter of paying those who help when I can. Teachers in schools get paid, so should teachers elsewhere. LMK if I can return the fair monetarily.

Also, Happy Holidays everyone!

bingo600

@johnpoz

I have localhost as resolver on the pihole DEB10
dns-nameservers 127.0.0.1

And pihole is using my bind9's as upstream resolvers (on the same L2) - That failed during the updates.

Then i made a specific allow pihole/32 to any - dns
And it updated.

After update i disabled that one again

bingo600

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

LMK if I can return the fair monetarily.

My (adequate) payment is to know i helped someone else that has an issue. - We have all been there.
And i hope they will help someone else in the same way.

Also, Happy Holidays everyone!

You too

Edit: There is an implicit "thank you" method here on the forum.
Click the "Thumbs up icon" in the bottom of the post you like.
That gives the poster a +1 on helpfull posts.

/Bingo

bingo600

@johnpoz

I have been a naughty boy
And hadn't updated mine.

Here's a "sniff" of my pihole ip , w. port 53 tcp/udp during a "NS1 allowed" update.

Wo. allowing "NS1" it barfs.

/Bingo

johnpoz

Why are they doing a directed query? What reason is given - that AD or MS dns does not allow for TXT queries? That is utter BS plain and simple..

I am not buying the reason for doing this at all..

bingo600

@johnpoz
I don't have anything w M$ DNS
If you do you could try the dig they use here.

https://github.com/pi-hole/pi-hole/commit/0ff32c3629220f386a45c14d8982aaaf128aa47f

If working it should give the same answer as in my sniff above i suppose.

Or the pcap here

imthenachoman

@bingo600 @johnpoz

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!