OPT1 needs LAN DNS access
-
@silence Oops, yes, I've removed that now. Thank you for pointing that out.
-
@lewis, a pleasure to help you, anything else you need here we are.
-
Wait now, do I have to uncheck that then or not?
I had already tested and clients from anything other than LAN could not get to pfsense. -
@lewis said in OPT1 needs LAN DNS access:
yes, I've removed that now
You removed what the anti-lock out rule? I really wouldn't recommend that.. If your concerned about devices accessing pfsense, don't put them on the pfsense "lan" interface. Put them on a different vlan or interface.
In a locked down scenario, the "lan" makes a perfect admin network. Where the only devices on this network are admin.. Since it has the antilock out rule.
More likely than not, if you remove that you are going to at some point lock yourself out ;) hehehe.
As mentioned by Steve already - the rules on LAN have zero to do with what optX can do..
-
@johnpoz, Every day I have to provide support to people who ignore the default settings. simply because your system works fine.
@stephenw10 good to know that 2 admins defend the default settings.
-
The LAN side is the only side that should have access to the firewall.
The additional networks should not which is why I still had that the anti-lockout unchecked. I did that based on reading up about anti-lockout and it seemed to be the right way/option. -
@lewis, first remove the default rule, and then configure the blocking rule on each interface! If you have questions, how do you let me know? I'm here to help.
-
Those rules on the LAN interface only filter traffic from clients on the LAN. They have no influence on traffic from clients on OPT1 or OPT2.
So if your goal is to prevent clients on OPT1/2 accessing the firewall then you need to check the rules on those interfaces.
Those rules on LAN are fine.
Steve
-
@lewis said in OPT1 needs LAN DNS access:
I still had that the anti-lockout unchecked.
What - dude only devices on the LAN network would have the antilock rule, not other interfaces have that. And if you create a new interface or vlan are ZERO rules on that interface.. You can not access anything from that network until your create rules.
The only thing that would work is dhcp, if you enable that hidden rules are created so it will work.. But that is all until you actually create rules.
How about you actually show us the rules you have placed on these other interfaces.
edit: Here is an example locked down vlan/network - its have very limited access ping, dns, ntp and nothing else other than interface, can not access the firewall gu, can not access anything on any other vlan/network locally. etc..
It can ping pfsense IP on that interface - for connectivity validation, etc. They can be adjust how you see fit.. But we really need to see the rules you have on these network.. What is on the lan has zero do with anything.
-
Maybe we are getting out of sync.
The only place that anti-lockout option is enable (or unchecked) is on the LAN.
Meaning, in system, advanced, the anti-lockout is not checked.I tested from the other networks and they cannot reach the firewall which is what I wanted so I'm not following what the problem is. I did this based on some pfsense document I found which talked about anti-lockout.
Some information suggested using this method, others suggested creating an alias and using that as a rule so it's kind of confusing to know which is the right way.
-
@lewis said in OPT1 needs LAN DNS access:
I tested from the other networks and they cannot reach the firewall which is what I wanted so I'm not following what the problem is.
Don't worry, friend, don't drown in a glass of water, just do a tracert and set the route your team takes to get there.
-
@lewis said in OPT1 needs LAN DNS access:
The only place that anti-lockout option is enable (or unchecked) is on the LAN.
Ok that is correct, because it is not possible to enable that or disable that on any other interface.. Its a LAN thing only.. So yeah might be some confusion there that you were removing the antilock out for some reason.
Some information suggested using this method
It is possible if you wanted to restrict devices that were on your lan from getting to the web gui, to turn off the antilock out and set your own rules. But to be honest if you were going to be locking down your network, I wouldn't be putting anything on the "LAN" that shouldn't be there, ie admin only sort of thing.. Turning off the antilock rule should be carefully considered..
There was recently a thread where they were locked out and had to refer them here
https://docs.netgate.com/pfsense/en/latest/troubleshooting/locked-out.html -
I want to understand what is being said and it's not clear to me.
From the OPT1 (10.0.0.1/24) and OPT2 (192.168.254.1/24) network, I cannot reach or even see anything on the 192.168.1.1 network using nmap.
From clients on each network, I get a reply from devices on the same network as expected but none see anything on other networks.
Of course, I need to block the firewall from any clients on each of those networks. The only network that should have access to the firewall is LAN.
-
And that is correct. The rules you had on LAN were fine. If the rules you have on OPT1 and OPT2 are as they were previously in this thread that's also fine.
If not then post the rules you have now for all 3 interfaces and we can review them.Steve
-
To be safe, here they are. DNS servers are on the LAN, hence the rules.
-
I think all I really need to do now is to add a rule on each network to not allow clients to access the gateway/firewall right?
-
@lewis said in OPT1 needs LAN DNS access:
each network to not allow clients to access the gateway/firewall right?
Your rfc1918 rule would do that, other than the wan IP which I would assume is public. This is good use of the "this firewall" alias. Which would include any IPs on the firewall, even if they change.
-
Correct, none of the clients on each network can see the pfsense firewall.
Or I should say, using nmap from a client, I can see the gateway of the network which is the pfsense device but no ports show up which is good.However, I have a bit of a different situation on another network. I set up OPT2 recently for my new AP and the wireless clients can see ports 22, 53, 80 and 443 on the AP.
It's not yet clear to me if I should block that from the AP (running openwrt now) or using pfsense.
What is interesting to me is like our DHCP talk, it would be nice to have just one place (pfsense) to monitor/maintain all access rules.I will have to block access to clients using the AP rules but am curious to know if there might be a way to do it from pfsense instead. Meaning, some rules on pfsense that would block other clients on the same network from being able to see those ports while also allowing the LAN to have access to the AP.
-
@lewis said in OPT1 needs LAN DNS access:
I set up OPT2 recently for my new AP and the wireless clients can see ports 22, 53, 80 and 443 on the AP.
Pfsense has no control over devices talking to other devices on the same network.. If you fire up some device, even an AP on a network and it has services listening on ports pfsense would have no way to stop a client on the same network from seeing those. That would have to be done on the device.
With something like an AP, the management IP should be on a network that is not available to wireless clients for example..
-
Got it. I thought there might be a way to block clients on the network itself.
I'll block access on the AP then and allow the single LAN IP that should have access.
