Help please: Why are these rules isolating IoT not working?
-
Simple way would be to just set the rule to log, and try and go to another rfc1918 network ;) And you should see the block logged..
But simple way to do it would before you put in the rule - ping something on another network that answers and then put in your rfc1918 block.. And once there is no state you would not be able to ping that device.
Or for testing purposes, remove your "this firewall" rule - and then ping other interfaces that are rfc1918 in pfsense. The this firewall rule would prevent that with or without the rfc1918 block - which is why you would need to remove it for testing rfc1918 blocking.
In the 12 something like years been using pfsense - have never seen it not do what it what you told it to do from the rules ;) Other than some oddness with ! rules when you have vips - but if you looked at the rules directly
https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html You could see what it was happening.. I have used ! rules in the past.. And they do work - its just good idea if your going to do them to fully test them.. And not using them are much cleaner - my current rule sets on all my interfaces have no ! rules in them.. They are explicit and direct and easy to view and walk through on what exactly should happen.
-
Can imagine. Impressive software.
I cleared the state table and even rebooted, pinged another network etc as instructed. Same result.It's that in the 6 days I have been using it, I don't know if I am telling the ping utility what to do correctly. :)
When you say ping other interfaces in rfc 1918 is the correct method to :
Diagnostics --> Ping --> Hostname (ip of another interface in rfc 1918) - IPv4 - source address (interface with rules/wifithings here) - Max 3 - seconds 1
Is that effectively sending the ping from the blocked network to another rfc 1918 address? Am I doing that correctly?
-
@rennit said in Help please: Why are these rules isolating IoT not working?:
Diagnostics --> Ping --> Hostname (ip of another interface in rfc 1918)
That would be pfsense doing the ping - no shit it would be allowed ;) There is hidden rule that allows firewall to do really anything.. There are a few hidden rules - to keep the user from shooting themselves in the foot.. You can view them with the link I provided above.
# let out anything from the firewall host itself and decrypted IPsec traffic pass out inet all keep state allow-opts tracker 1000012115 label "let out anything IPv4 from firewall host itself" pass out inet6 all keep state allow-opts tracker 1000012116 label "let out anything IPv6 from firewall host itself"And pinging its own interfaces from itself - I don't think there is anyway to block that. Have never seen any device or firewall that would allow for rules to stop it from pinging its own IPs addresses ;)
What I mean is from a device on network A lets call it 192.168.1/24 say 192.168.1.100, try and ping a box in say in network B 192.168.2/24 or ping pfsense IP on that interface say 192.168.2.1
To stop pfsense from doing something from its own interfaces - you would have to put in a special outbound rule in the floating tab.
-
Well no shit indeed. haha If there was emojis here there are certainly a few I'd throw out after that on my part. It would have taken me hours to figure that out or know that. Seriously. Makes sense of course. I though maybe the utility accounted for that somehow by choosing source name.
Thank you for the references.
Did what you said and could not ping. Then turned off the block rfc 1918 rule and could ping so cross-referenced and verified. Awesome!
If that interface/vlan did not have an access point on it, is there another method besides pinging to see if packets are blocked going out from that specific interface. Just logging or...?
-
@rennit said in Help please: Why are these rules isolating IoT not working?:
out from that specific interface
Just for clarity keep in mind rules are evaluated as traffic enters an interface from the network attached to the interface..
network ---> int (pfsense)
Pfsense blocks traffic before it enters the firewall.. To do out blocking - you would have to do those in floating rules.
Out of the box the default block rule logs - so in the log you should see anything that is blocked by default rule at the end of every interface set of rules (just not shown). If you put in your own block rule on an interface - and you want to log that traffic, then you would need to set the specific rule to log.
If that interface/vlan did not have an access point on it
If there is nothing attached to the interface - how would there be anything to block?
-
Ahhh makes sense. Clarity was needed.
I meant not an access point that I would send a ping from. e.g. a lightbulb, but I suppose I could physically intercept or hook-up to it's connection, just wouldn't know how to control that vlan remotely to test or ping from it, but what you explained above is a perspective I wasn't considering. Guess that is where my question 5 on management came in. I am trying to understand that piece of the puzzle.
I am very grateful that you picked up this thread today and have been responding. I have spent countless hours for just tiny bits of what you were able to share and solve so quickly today. Truly thank you!
-
@rennit Yeah if all you have is iot on a network - its hard to do any validation testing, etc. But something has to allow for a connection to it - be it wifi or wire.. So you can test from that network with a laptop or phone even.
Other then just logging traffic.. But if you put your rules in, in a clear and direct manner it should be pretty obvious. If you ever have question on rules - just post up for peer review.. Lots of smart people here on the forum that willing to chime in with insights..
-
Yes, makes sense, was hoping there was a more efficient way.
Been reading a ton. For sure there are and appreciate the welcoming nature... :))Seems that this thread has gained a bit of traction for being up just 24 hours, so for fellow beginners reading:
Did a lot of a/b and multi-variable type testing, both to gain a better grasp and also to make sure I didn't screw anything up and achieved desired results.
Couple of lessons learned:
- @johnpoz mentioned worrying about existing states. Cannot over emphasize that. Had he not mentioned that, it would have been a tremendously long frustrating experience for a person like me, who wouldn't have thought of that for problem solving and, as a novice, tends to first think I did something incorrectly, then check and recheck and research for way too long....
May times I made changes and didn't achieve desired results or it just seemed 'not to work' or I lost access from an interface etc.
9 of 10 just had to flush the states.Diagnostics --> States-->Reset States
(refresh page, may not auto-reload)
2nd line problem solving after verifying proper entries:
Reload Firewall & Reset States-
Regarding the DNS rule: It does prevent your designated DNS from being called if it is not set to Pass. Therefore, you will not be able to load a webpage and may think you are offline. If for VPN or other reasons you make all traffic go through the DNS on general setup, have to enable the pass rule from @johnpoz above. As he mentioned, unless it's strictly using web based DNS.
-
Opinions: Copy rule helps a lot, careful with all the drop downs and have multiple interfaces with verified access to firewall for testing that rule.
After using logs a lot for testing, seems 90% of the firewall log is multicast IPv6 on my system, because I have it checked to disable in setup and logging is then automatic.
Seen threads going back to 2014 with this issue. Many spoke of floating rule solutions, but I don't know much about floating rules yet, so through my research this is a solution found that I can understand and seems to have good forward leaning benefits as denoted on the bottom.
Later added:
@johnpoz is that what is still being recommended today or is there a preferable method?
Also, I'm just getting a better handle on IPv4 and definitely not up to IPv6 yet. I have done some searches and cannot find a picture or a clear description on how to make those - what I think are aliases (because not valid just entering them in the rule box).
fe80::/10
ff00::/8
fe80::/10
fe80::/10I did noticed that all of my logs had either fe80 and/or ff02, so I realize that is what is needed, but how do you create that, is it a range, or enter it? Do you have a pic perhaps?
Thank you!!
-
@rennit said in Help please: Why are these rules isolating IoT not working?:
did noticed that all of my logs had either fe80 and/or ff02, so I realize that is what is needed
For what would you need those? That is ipv6 link local traffic - the only reason you would need rules to allow that would be for if you were running avahi? And using IPv6 - are you??
Yeah the default blocking rule that logs - will log all kinds of noise on the network.. That is NOISE if you are not specifically doing something with it, like avahi.. You could create rules not to log that noise..
You said you wanted to isolate iot network - why would you have any desire to allow it to do discovery of stuff on your other networks via mdns?
-
My log is full of this from the default disable, so trying to create a rule without logging enabled...
That was in a prior thread as a sloution, but perhaps that's not what is needed. Why I @johnpoz :)) haha
-
No, not currently using IPv6, unless mobile devices require or a reason I do not know. I have it disabled in settings, which I have learned creates the default log entries with no option to disable logging. Therefore suggestions I have seen is to create a new rule without logging. How should it be done? I'm scrolling through hundreds...
-
@johnpoz Just saw your last statement. I do not. Not running avahi either. Read a prior post of yours regarding that too.
I want to keep blocking out the noise, but just not completly fill the logs with the memory of it. :)I have also seen floating rules suggested as well as non. I know all that is needed a rule and not have logging enabled. I do not want to disable the default rule without knowing the new rule for certain does the job, that is why need the expert advice. Do you have a pic of how to do it correctly?
-
@rennit I am not really a fan of floating rules.. Because first thing you go to when trying to troubleshoot something is the interface - and sometimes forget about rules that might be in floating. So unless you have like 100s of interfaces that you want a rule on and don't want to create them specific I would always put rules (other than outbound rules - which are rare) on the interface.
If your not using ipv6.. Just create a IPv6 any rule to block or even allow - and just not allow it.
Then doesn't matter what it is, link-local, multicast, whatever it just won't be logged.
edit: Ah you have ipv6 set to blocked - that is the rule that is logging that, not the default rule.. I believe you might be able to do that without logging.. Let me look - I do not log default unless troubleshooting/testing something. I have my own rules that I want to log, and only log those.. Keeps my logs clean of noise. I only log syn tcp, and only common udp ports.
edit2: You have this unchecked I take it
-
Very good point. Good to know, I really do not know anything about floating rules and therefore did not want to try and use one when there are alternatives. Now I know I can focus learning time elsewhere.
Okay, that I can do. What interface(s): LAN, WAN, VPN, OPVN?
Yes exactly, I have it blocked and that is causing the default logging. I did not see anything about how to turn logging off with it. People have been posting about this nuisance since at least 2014, I am surprised if not an option not to log by now.
edit: Correct mine is unchecked and I used default incorrectly. Meant default logging with box unchecked.
-
This post is deleted! -
@rennit I would have to do some testing. As I mentioned I do not log default, and I don't have that unchecked because I do use some IPv6.
Not sure where the rule for blocking ipv6 goes in the stack - might before interface rules. If that is the case you might have to use floating rules to not log it.. When get a chance will do some testing and let you know.
Keep in mind - that unless you have rules to allow IPv6 - that being checked ipv6 still wouldn't work since default is deny.. So ipv6 could never work unless you actually have rules that allow it.. So if that block rule is causing log spam - you could check it and then just don't allow IPv6, this way for sure any rules you put in interface to not log IPv6 would work.
-
Appreciate that, but do not want you to go out of your way more than you already do. Is there a way to not log with that box unchecked?
@johnpoz From note below regarding edit: Okay, when you say do not allow, do you mean not have any explicit Pass rules or create active block rules? Or how does one actively make sure that IPv6 is not allowed universally? Just not clear on where or what to do for that last suggestion, but it sounds like what I want to do.
-
@rennit see my edit to post above..
-
@rennit said in Help please: Why are these rules isolating IoT not working?:
Okay, when you say do not allow
The default rule is always deny.. They are just not shown in the gui list of rules. If you do not have a rule on an interface or floating tab that "allows" something - then it will be denied. No need for a specific deny rule - unless you want to log it, or not log it or reject vs just drop.. Or depending on what your wanting to allow calls for specific block in the rule order. Say for example you want to only allow icmp to some specific vlan or dest, or only from specific host to internet.. You would need a specific deny between that rule and the default any any rule at the bottom of the rule list.
If you do not have an allow rule on lan for example that allows for IPv6 - then even if client has IPv6 address.. He isn't getting off his own network through pfsense using it.. So its really not a requirement to uncheck that box to specifically create block rules for ipv6.
-
Got it. Perfect sense. I am going to check that box then verify I have nothing that allows IPv6 on any interface.
Once that is complete, is there any place I could look or diagnostic to run to both learn, and verify that IPv6 traffic is being ignored or is it more of a 'trust the software'? There is a ton of that IPv6 noise...
Does this also work for WAN, should I place that rule? Then when needed make it just IPv6...
WAN Interface
