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

bingo600

I have not read all the above (rules) , and am not using DNS redirect. My guess is it happens like this.

The pfSense "redirect" would "catch all" traffic destined for port XXX (here 53/123) , and reroute it to the pfSense IP dest. 127.0.0.1 (localhost).
This would mean that pfSense would handle (answer) those requests.

But in order for the request packet to be processed at all , you will have to allow it to enter the interface via a fw rule.

I'm only allowing DNS requests to "TFW" (this firewall) , meaning all pfSense interfaces , and have the pfSense IF set as DNS in all my DHCP definitions. If my clients try to ask another DNS ip , the package would be blocked.

But with your redirect setup (more elegant), i would expect that you can allow DNS to "any" in the firewall rule. As the redirect should catch all requests , and redirect them to he pfSense (localhost). And the client using a "foreign" dns , will still get an answer (from pfSense).

So you need two rules.

1: Allow DNS to enter via the interface.
2: Firewall redirect rule

/Bingo

imthenachoman

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

Have you verified that normal dns resolution works using pfsense lan address as a resolver from your windows client?

I don't follow. From what I can tell, even on the default LAN interface, Windows was using 192.168.1.1 as the DNS server and ergo not redirecting DNS queries back to pfSense because the redirect rule says ! LAN address and 192.168.1.1 is LAN address.

You do have to allow dns requests (udp/tcp) to reach the configured lan interface address on pf.

Yes, isn't that what the port forwarding rules are? Those were addedautomatically when you add the redirect rule.

imthenachoman

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

The pfSense "redirect" would "catch all" traffic destined for port XXX (here 53/123) , and reroute it to the pfSense IP dest. 127.0.0.1 (localhost).

Yes but the issue is it's not. The redirect rule, per the instructions on the pfSense site, says to redirect all :53 traffic that is not interface address. However, Windows is sending DNS to the interface gateway which is the interface address.

johnpoz

I have not looked to closely at these rules.. But lot of them make no sense.

Why do you have block on wan? This is the default, there is not reason for those rules.

Also if your trying to redirect traffic for dns/ntp, why do you have 127.0.1.1 vs 127.0.0.1?

Other rules make no sense either. You have a "antilockout" rule listed to allow 22 to vlan20 address - when does ssh use UDP? But then you also have a rule allowing 22 to the dmz address? What is the point of that, ssh to pfsense vlan20 address is the same thing as ssh to its dmz address.. Did you mean dmz net?

Also you have a reject any any at the end? Why default is deny, there is no reason for that rule at the end? Do you specifically want to send a reject vs just drop? If so that ok that rule could have value. You understand the difference between reject and block right?

Same goes for all your ipv6 rules.. Deny is the default - there is no reason to put those rules in, if there is no allows for it anyway. Are you wanting to log or not log some of this traffic.. You don't state which rules are listed as logging or not logging..

Seems like you went to a lot of trouble to post up those rules in such a way.. with the markup and all.. But its not every easy to look at...

Would of been easier to just post up screenshot of the actual rules - including your port forwards.

From the way you posted those rules - I don't see how dns would work since your trying to redirect it to something that will not answer.. 127.0.1.1

Also ! rules, or inverse rules can be problematic if you have any vips setup, etc. I would suggest you use explicit deny rules..

imthenachoman

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

...

The 127.0.0.1 is a typo. It should be 127.0.0.1.

You're right on the reject rules. This is my first time playing around with FW rules and I wasn't sure at first. I've cleaned my rules up.

when does ssh use UDP

My mistake. Will fix.

But then you also have a rule allowing 22 to the dmz address? What is the point of that

I want all devices in VL20_trust to be able to SSH to devices in VL10_dmz. But ignore that rule for now. I haven't actually added it cause I'm trying to get the other rules to work first.

Right now I am trying to make it so client DNS queries all go through pfSense. And they sorta are, but not how I expect.

Looking at just my current LAN rule I created a redirect as mentioned here: https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html. My understanding of the rule is:

traffic on LAN
going to anywhere not LAN address on port 53
redirect to 127.0.0.1:53 (pfSense)

But the client is getting LAN address (192.168.1.1) as the DNS server so it is sending its DNS queries to interface address (192.168.1.1). Ergo, the port forward rules don't get triggered.

Below is picture of my port forward rule and LAN FW rules. No traffic is going to the LAN DNS rule.

I followed the instructions in the recipe so I am not sure what is wrong. Is there something else I need to be doing? I feel like I am missing a step that is supposed to make it so DNS queries on LAN/VLAN address (like 192.168.1.1) also go to 127.0.0.1:53?

johnpoz

If your lan address is 192.168.1.1 on pfsense, that redirect would not come into play... Your port forward says if NOT lan address (192.168.1.1)

But your sending dns queries to 192.168.1.1..

If you want to test that rule, send directed dns query to say 8.8.8.8 or something..

imthenachoman

@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?

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.