Preventing to access pfSense login page on IoT VLAN
-
Hi,
I did set up an IoT VLAN (192.168.73.0) with no access to the user LAN. I would like to block access to the pfSense login page on the IoT VLAN(192.168.73.1).How can I make this happen?
Thank you in advance!
-
@keesdek
Basically pfSense blocks any traffic which is not explicitly allowed by a pass rule anyway.If you want to allow internet access on the IoT VLAN, but not access to other internal network segments, add a pass rule to the IoT interface for any destination but your internal networks.
Best way to do is adding an alias of type network and add all RFC1918 networks to it. Then use this alias for destination in the pass rule in conjunction with "invert".Consider also that floating rules with "Quick" option checked are applied before rules on the other interface tabs.
-
@viragomann
Thank you for your response!
I am not sure if your answer applies to my question, but I am relatively new to networking
In the current setup it is possible to login to the pfSense page on the IoT VLAN at 192.168.73.1. Normally I login on the pfSense page at my LAN 192.168.10.1.
Is there a way I can prevent IoT users to even see my pfSense login page at 192.168.73.1 in the IoT subnet? -
@keesdek
As I said, if there is no rule allowing the access explicitly pfSense will block it. So check you rules.
By default there is an "anti-lock-out" rule enabled on LAN, but not on other interfaces. Maybe thismatches here if your VLAN is not configured properly.If you can't find the responsible rule, enable logging in all your rules and check the log.
You also can add a block rule on the IoT for all RFC destinations, however a quick floating pass rule may override this as well.
Also you may need to allow access to specific internal services like DNS, so will will need to add additional pass rules for this.
-
@keesdek said in Preventing to access pfSense login page on IoT VLAN:
Is there a way I can prevent IoT users to even see my pfSense login page at 192.168.73.1 in the IoT subnet?
Yes block it.. use of "this firewall" is prob best choice..
Here is example rules for a locked down vlan - it would have no access to pfsense web gui.
-
@johnpoz OK John, it's bugging the hell out of me that in your first rule you call it pfsense, the 2nd it's Pfs, the 3rd it's pfs and the 4th it's Pfsense....
-
I think it had to do with doing it later, ie should prob be consistent ;
edit: ok is that better ;)
-
@johnpoz Much better
-
Touch of the OCD, yeah I get that sometimes as well ;) heheh
-
@johnpoz Hi John, thank you for your input
I inserted a test VLAN (192.168.30.0/24) and put in the firewall rules you suggested. However I can still access the pfsense web gui at 192.168.30.1
Any other ideas?
TIA, Kees -
@keesdek Reset your states via Diagnostics - States.
-
^ exactly. States are evaluated before rules. If you access something that is allowed, a state is created. Until that state expires or is deleted, that state will continue to allow traffic. Even if you create a rule that now should block said traffic.
Other things that could cause you problems - you have a floating rule that is allowing the traffic. Floating are evaluated before interface rules.
Your rules are not in correct order, rules are evaluated top down, first rule to trigger wins, no other rules are evaluated.
-
@johnpoz Resetting States did the trick. But now I cannot connect to the internet from the Test VLAN. I tried changing the order of the rule -> still no internet...
-
@keesdek Be more specific. Can you ping pfSense itself (assuming you allow pings in your rules)? Can you ping 8.8.8.8? If so, can you resolve a domain name?
-
If you want help with your rules - your going to have to post them.
-
@kom Unable to ping anything. Computer is not able to acquire a DHCP address, while the DHCP server is active on the test VLAN
-
@keesdek Post a screen of your rules for that interface.
-
-
@keesdek Rules are processed top-down first match (except floating rules which are last-match unless you have the Quick option selected.) All your rules are out of order since the top rule allows everything. That rule should be last, not first. Your problem isn't your rules.
-
@kom Thanks again for your help!
I tried 'johnpoz' (above) order first, but since it didn't work then, I started changing the order... -
@keesdek Can you confirm that your test client is on test_vlan30?
-
@kom Yes, the test client is on test_vlan30. And in the mean time my computer has acquired an IP address. But still no internet
-
@keesdek In the meantime? Getting an address via DHCP should be almost instantaneous. What is this client? PC, phone? Physical, virtual? Windows, Mac, Linux? Any hardware like a switch between client and pfSense? What do your outbound NAT rules look like?
-
@kom Well... initially I configured the test_vlan30 interface incorrectly. But that is fixed. Attached a screenshot of the outbound NAT rules
-
@keesdek What is this client? PC, phone? Physical, virtual? Windows, Mac, Linux? Any hardware like a switch between client and pfSense?
-
@kom Client is a Mac, connected via UniFy switch and wireless access point
-
@keesdek So lots in between to cause problems. I'm not a Mac guy. Can you confirm that it gets an IP address in the correct range, has the correct mask, gateway and DNS?
-
@kom I can confirm all
-
@keesdek Delete all your rules on that interface except an allow all rule. Get basic connectivity working before you start to restrict things. Once that is done, can you ping the interface from the Mac?
-
@kom Did that and am able to ping the interface. In the webbrowser the pfSense web gui opens as well. And I have internet connection as well
-
@keesdek Well, looks like it works now. Here is what I did. After deleting all the rules except the allow rule, I started turning the rules on again from the bottom up. When I leave the top rule turned off, it works! On the test network I can connect to the internet, but am not able to open the pfSense web gui
Thank you very much for your help KOM and others!!
Still a lot to learn on my side -
@keesdek said in Preventing to access pfSense login page on IoT VLAN:
eave the top rule turned off,
Then there is no way you would have internet.. Again rules are evaluated top down.. If you have not any rule - how would you have internet? You wouldn't not through this interface you wouldn't..
Also whatever you dhcp issue - has nothing to do with rules.. You could have zero rules, you could have explicit rules blocking dhcp and it would still work.. once you enable dhcp on interface - hidden rules are created that allow dhcp to work..
So you saying dhcp wasn't working had nothing to do with any rules you created that is for sure.
-
@johnpoz The dhcp issue was due to the fact that I misconfigured the test_vlan interface...