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

bingo600

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

@johnpoz

I see. So the clients use the LAN/VLAN address as the DNS server. What do I need to do to make sure the DNS queries clients send, to the LAN/VLAN address, also get routed to 127.0.0.1? Another port forward rule?

How about changing from !LAN to "Any"

johnpoz

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

o the LAN/VLAN address, also get routed to 127.0.0.1? Another port forward rule?

what would it matter? They are going to the same place to be honest. They are still going to unbound be it loopback or 192.168.1.1 - still going to unbound.

imthenachoman

@bingo600

Thanks. I was thinking that but then unsure since the pfsense recipe didn’t say that. I kinda assumed the recipe instructions would do what I need/expect — assuming it was written with the understanding that clients would get LAN IP as DNS server.

imthenachoman

@johnpoz

But the port forward rule says to forward anything NOT to the LAN IP. Since the clients are using the LAN IP as DNS server, the port forward rule never triggers. Or am I misunderstanding?

bingo600

@imthenachoman

The forward rule is a "Catch any" and redirect to 127.0.0.1 (that's the pfsense).

The only thing not "Caught" is the DNS going directly to the LAN interface ... Who/what do you think handles the requests on the incomming Lan interface ??

/Bingo

imthenachoman

@bingo600

I see. So I guess I need a FW rule to allow clients to access LAN address. I don’t think I have that right now. :/

imthenachoman

EUREKA!

So I had to add another FW rule that says allow IPv4 TCP/UDP from LAN net to LAN net on 53. I can see that rule working.

Thanks all!

johnpoz

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

I don’t think I have that right now. :/

yeah you do

That rule allows anything - if there was not a specific deny above that - then it would be allowed.

Rules are evaluated top down. first rule to trigger wins, no other rules are evaluated. So if your trying to talk to 192.168.1.1 on 53 you have no rules above that any any rule that would block that or force it elsewhere - so its allowed. by your last rule.

imthenachoman

@johnpoz

Yes but it wasn't doing what I was expecting.

I would have expected the FW rule I circled (the port forwarding of DNS from LAN to pfSense) to be triggered. But it wasn't and so the catch all rule was catching it.

But I figured out the issue and created a FW rule to allow traffic from LAN net to LAN net on 53. That rule is triggering for the client DNS queries -- so I don't need the catch all.

Not that you asked, but if you're curious, I've been making notes for myself and decided to put it in a public gist to hopefully help others out. https://gist.github.com/imthenachoman/67ca5f0cb747b680ca4a44abdc564b20

johnpoz

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

FW rule to allow traffic from LAN net to LAN net on 53.

Rule doesn't make a lot of sense.. If you want to allow access to lan address, then allow that.. lan net as destination on the lan interface makes no sense..

Lan can already talk to anything else on the lan, devices on lan don't talk to pfsense to talk to other stuff on lan. So lan net as destination makes no sense on the lan interface. Lan address is a destination that makes sense, stuff other than lan make sense..

We already went over why your circled rule wouldn't match..

Not sure where you got the idea that everything needs to be redirect to pfsense. Are you not handing them already.. If you don't want things talking to other than pfsense for dns or ntp. Block it I think is better.

Would you like it if your isp said, hey you know what we don't want clients using google - so lets redirect them so they think they are talking to google, but they will really be talking to us.

Redirection can be a solution to a problem - where client X doesn't listen to what you you hand him via dhcp, or set on him directly.. Personally I think its a bad idea to do as some sort of standard.. I would say a block rule is prob better than you log, so you can see hey this client I hand pfsense for dns, why does he continue to bang his head trying to query google for xyz.tld..

imthenachoman

@johnpoz

I want to have very tight control of what traffic is allowed where. I don't want any kind of "default allow all" rule or anything.

Lan can already talk to anything else on the lan, devices on lan don't talk to pfsense to talk to other stuff on lan. So lan net as destination makes no sense on the lan interface. Lan address is a destination that makes sense, stuff other than lan make sense..

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?

Not sure where you got the idea that everything needs to be redirect to pfsense.

Why is it not better to have a central authority for all DNS queries on my network? That way those queries are cached. So if system1 looks up example.com, when system2 looks it up, pfSense can return a cached response. Isn't that good/desirable?

imthenachoman

@johnpoz

I wager most folks disagree with me for having excessively strict rules. I'd be willing to debate/discuss it with someone but I much prefer the policy of only allowing exactly what is needed, nothing more, nothing less.

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