Preventing to access pfSense login page on IoT VLAN
-
@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...
-
@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.
