Preventing to access pfSense login page on IoT VLAN
-
@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...
-
@johnpoz Brilliantly useful. This is EXACTLY what I wasted time trying to blindly do on my own via google and youtube. THANK YOU
-
Hey all... I was just reading through firewalling posts and wanted an opinion on this topic where rules I have setup are concerned. In my case, I needed other trusted networks to be able to initiate traffic to IOT devices but not the other way round. Further, I do not use pfsense as a dhcp server because it acts as a dhcp relay. My setup is a bit different where I am using a L3 switch for trusted networks where the routing between them is done on the switch. Untrusted vlans such as GUEST and IOT are sent up to pfsense via a separate trunked interface where I have the firewall governing where the traffic on those vlans can and cannot go. I wanted to know if what I am doing on IOT from a rule perspective is the best method. You will notice some of the original rules I have disabled in favor of the newer rules. What you see below functions as I described for the IOT network. Thoughts?
-
@aclouden If you have dhcp enabled on this interface "iot" then that rule for dhcp is pointless.. And it wouldn't even work anyway because discover wouldn't be to an IP (its a broadcast), etc. not sure what you have in that alias, but once you enable dhcp on an interface, hidden rules are created to allow for dhcp clients to talk to the dhcp server.
What is your IOT network using for dhcp? You don't have anything allowed that would let it talk to pfsense for dns.
Not sure what "to iot but not from iot" is suppose to mean.
Rules on the iot interface have zero to do with other networks creating traffic to the iot network.
If you want other networks to talk to IOT, then those rules would go on those interfaces. If you don't want iot to talk to other networks, then your rfc1918 rule would do that.. Here is a sample listing of locked down network.. My other networks can talk to it all day, but this network can not talk to any other of my networks that rfc191.
the rfc1918 alias contains the rfc networks
-
@johnpoz Hi John. Thanks for the reply.
Pfsense is acting as a dhcp relay. I am using Windows servers for dhcp.
Depending on the subnet, I am using internal Windows dns servers or pointing to external dns (such as for the IOT network). Pfsense is not handling dns.I don't have rules on other interfaces to allow them to talk to IOT because they don't exist on pfsense. They are SVI's on a L3 switch. The gateway of last resort is a transit interface defined on the switch uplinked to pfsense. The guest and IOT vlans are trunked to pfsense on a separate L2 ethernet port with their vlans and L3 interfaces defined on pfsense. Each dhcp scope has its default gateway defined as the ip address in the SVI for the respective vlan. The whole idea for doing it this way was trusted networks are routed at the switch, untrusted networks are controlled via the more powerful rules that can be leveraged in pfsense. So, in order to create a way for the other networks to talk to IOT, I created an alias for those and set them in an inverted match rule. That is what is meant by to IOT but no from IOT, if I am understanding inverted match rules properly.
The results as I have tested thus far allow traffic into IOT but not initiated from IOT, nor can IOT reach pfsense management addresses. IOT can reach my dhcp servers and the internet only. I was simply wondering in light of the rest of the network setup if my method is the best way to do it. It was the only way I could come up with to meet the need.
-
@aclouden said in Preventing to access pfSense login page on IoT VLAN:
Pfsense is acting as a dhcp relay.
Which would also create hidden rules..
cat /tmp/rules.debug
# allow access to DHCP relay on TEST pass in quick on $TEST proto udp from any port = 68 to 255.255.255.255 port = 67 ridentifier 1000004641 label "allow access to DHCP relay" -
@aclouden said in Preventing to access pfSense login page on IoT VLAN:
o, in order to create a way for the other networks to talk to IOT, I created an alias for those and set them in an inverted match rule.
Doesn't work that way.. How would traffic from other networks come into this interface?
If you have a transit network from your L3 switch (downstream router) to get to other networks that are not on the switch (router) this traffic would come into the transit networks interface on pfsense. This is where you would allow or deny where that downstream traffic could go.
that rule on your iot interface isn't allowing that traffic.
All that rule is doing is allowing iot traffic to go anywhere that is not in your trusted_to_iot alias. Most likely the internet for example.
So you have a network like this
Your iot network in this example would be the 172.29.1.0/24 network. Doesn't really matter if you have a separate switch for this network, or just leveraging L2 vlan on same physical switch your doing L3 routing on. The rule to allow access or deny access to the 172.29.1/24 network would be on the transit interface. The 172.26.1.1 interface in the above picture.
If traffic entering pfsense on some other interface is allowed to talk to the iot network, the return traffic from the iot network would be allowed by the state created when pfsense allowed the traffic in the first place.
edit: unless you have a very specific use case where you would really "need" to use a bang rule - which I can not really think of one off the top of my head. Its best to be explicit in you rules, allow or deny the traffic. With a bang rule your allowing traffic with a deny statement. A quick look over that rule could read your denying traffic to "trusted_to_iot" vs allowing anything but that..
There have in the past been issues with using ! rules when there are vips involved, etc. It prob a better idea to no use them, and just create very specific rules to what is allowed and what is not. In my above rules you can see specific deny traffic to anything that is rfc1918..
If your going to use ! rules, I would be very thorough in your testing. And only use them if it is the only way to accomplish something.. Which again I can not think of a scenario where that would be - just create the specific explicit rules vs using a ! as a shortcut.
-
Hi John,
Thanks for taking the time to explain this. I appreciate it. I will test more heavily and do some packet sniffs to verify some things. Further, I will create some test rules on the transit interface and see what happens.
Definitely more info than I expected. Very helpful. I'll post back what I find out. Not likely until either the weekend or next week.
Thanks again.
-
@johnpoz
Well... Did some testing... Turns out that those inverted match rules were not doing what I thought. So I have the desired rules on my transit interface controlling what can talk to IOT and appropriate rules that block access from IOT (and GUEST) to internals as needed. Thanks for the heads up on inverted match rules. I have a screenshot of the IOT rules in case it helps anyone else out who may be providing dns, dhcp or other services that are not running on their pfsense box.Merry Christmas everyone!
-
@aclouden Why do you think you need that dhcp rule at the top?? if you enable dhcp or dhcp relay on the interface the rules are put in place to allow for dhcp hidden, I don't see what the point of that dhcp rule is when there would be hidden rules to allow anyway.
And block works as well, but using reject on local is sometimes better because it can cut down on devices retrans, basically banging their head on the wall - hey I want to go here, I want to go here, I want go here.. With a reject when it tries to go - it will be told NO!! and wont send any retrans trying to get an answer.
-
@johnpoz
I seem to remember when I was setting up these interfaces that dhcp would not reach my internal servers without that rule. I'll test that again..I remember reading a long time ago that block is the best choice because the traffic is simply dropped with no reply. But.... Since these are internal interfaces and not public facing, I see what you mean.
-
@aclouden yeah reject would be a bad choice for external interface where your seeing noise from the internet, but internally its a better choice to be honest.
edit: you can view your hidden rules for dhcp like this
https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html
[23.09.1-RELEASE][admin@sg4860.local.lan]/var/unbound: pfctl -sr | grep DHCP pass in quick on igb0 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server" ridentifier 1000002541 pass in quick on igb0 inet proto udp from any port = bootpc to 192.168.9.253 port = bootps keep state label "allow access to DHCP server" ridentifier 1000002542 pass out quick on igb0 inet proto udp from 192.168.9.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server" ridentifier 1000002543 pass in quick on igb2 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server" ridentifier 1000003591 pass in quick on igb2 inet proto udp from any port = bootpc to 192.168.2.253 port = bootps keep state label "allow access to DHCP server" ridentifier 1000003592 pass out quick on igb2 inet proto udp from 192.168.2.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server" ridentifier 1000003593 pass in quick on igb4 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server" ridentifier 1000004641 pass in quick on igb4 inet proto udp from any port = bootpc to 192.168.200.1 port = bootps keep state label "allow access to DHCP server" ridentifier 1000004642 pass out quick on igb4 inet proto udp from 192.168.200.1 port = bootps to any port = bootpc keep state label "allow access to DHCP server" ridentifier 1000004643 pass in quick on igb2.4 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server" ridentifier 1000007791 pass in quick on igb2.4 inet proto udp from any port = bootpc to 192.168.4.253 port = bootps keep state label "allow access to DHCP server" ridentifier 1000007792 pass out quick on igb2.4 inet proto udp from 192.168.4.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server" ridentifier 1000007793 pass in quick on igb2.6 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server" ridentifier 1000008841 pass in quick on igb2.6 inet proto udp from any port = bootpc to 192.168.6.253 port = bootps keep state label "allow access to DHCP server" ridentifier 1000008842 pass out quick on igb2.6 inet proto udp from 192.168.6.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server" ridentifier 1000008843 pass in quick on igb5 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server" ridentifier 1000009891 pass in quick on igb5 inet proto udp from any port = bootpc to 192.168.7.253 port = bootps keep state label "allow access to DHCP server" ridentifier 1000009892 pass out quick on igb5 inet proto udp from 192.168.7.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server" ridentifier 1000009893 pass in quick on igb3 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server" ridentifier 1000010941 pass in quick on igb3 inet proto udp from any port = bootpc to 192.168.3.253 port = bootps keep state label "allow access to DHCP server" ridentifier 1000010942 pass out quick on igb3 inet proto udp from 192.168.3.253 port = bootps to any port = bootpc keep state label "allow access to DHCP server" ridentifier 1000010943 [23.09.1-RELEASE][admin@sg4860.local.lan]/var/unbound:Those are all the interfaces I have dhcp enabled on, zero rules set on my gui - dhcp works on all interfaces.
