OPT1 needs LAN DNS access
-
@lewis said in OPT1 needs LAN DNS access:
I then nab their MAC address and create a static DHCP entry.
Yeah I pretty much do the same thing, anything on my network other then guest devices normally have a reservation..
I'm not really a big fan of the term "static dhcp" maybe I am old school, its a dhcp reservation for me ;)
Any time someone says static - what comes to my mind is setting the IP on the device directly.
-
@johnpoz said in OPT1 needs LAN DNS access:
I'm not really a big fan of the term "static dhcp" maybe I am old school, its a dhcp reservation for me ;)
Any time someone says static - what comes to my mind is setting the IP on the device directly.That is of course correct. My bad....
-
@jsmiddleton4 its not you - pfsense calls it static as well..
Its not the term is "wrong" exactly - its just it can be a bit confusing if not spelled out exactly that it was via dhcp or set on the device, etc. Especially for us old timers that grew up with the term reservation for years and years..
-
@jsmiddleton4 said in OPT1 needs LAN DNS access:
And if you need to access the AP directly as in LAN cable to the AP. While a static IP assigned via the router gets to nearly the same place, the IP stays the same, if for some reason the router is out of the picture, good luck accessing the AP without a factory reset turning the AP back into a router.
Before doing a reset, you should still be able to see the AP in the wireless list no matter its LAN IP is by using a wireless laptop. Then you could access the AP's admin page since if would be the laptops gateway IP.
-
Maybe it's a reserved static DHCP IP :).
It really is reserved but once reserved, it's outside of the DHCP pool making it static within the DHCP server LOL.
-
Giving the AP its own static IP eliminates any variables including if a DHCP server is up and running. I like eliminating variables.
-
@jsmiddleton4 said in OPT1 needs LAN DNS access:
including if a DHCP server is up and running
This is a misconception as well - dhcp server being offline doesn't stop clients from working that had already gotten a lease. It only prevents clients from getting a new IP or renewing their lease. If you have no new clients coming on to the network.
If your lease was say 4 days, worse case scenario your lease would be at 2 days when dhcp goes offline - you would have then 2 days to notice your dhcp server is offline before clients started dropping off when their lease expired ;)
Setting a reservation, or call it a static mapping you will has way more advantages then setting the IP on the device itself. You can now change options like dns,ntp, domain or gateway or even the mask or even the IP range being used without having to actually touch a client and make these changes.
With the use of reservations - I can easy change a devices IP without having to mess with it. Say its a pain in the ass on stuff like iot or printers are big example. Where you have to go through some arcane menu system using up down arrows and such on the little menu on the printer. If I want my printer IP to be something different, just change the reservation and reboot the printer - bobs your uncle its now on the new ip.
-
@johnpoz said in OPT1 needs LAN DNS access:
With the use of reservations - I can easy change a devices IP without having >to mess with it. Say its a pain in the ass on stuff like iot or printers are big >example.
Exactly and keep track of devices by Description names, MAC and IPs set via the DHCP server. It's how I manage lots of devices.
-
@lewis, I am glad that in part it is already solved, but what about this?
It says I don't want anyone to be able to get to pfsense management but it has a default rule on LAN (You have to remove it) to correct this.
@lewis said in OPT1 needs LAN DNS access:
I want to prevent opt1 and opt2 from seeing the pfsense gui.
-
That rule only passes traffic from LAN it would not allow devices on OPT1 or OPT2 to access anything.
-
@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.
