Help please: Why are these rules isolating IoT not working?

[rennit]

What is the issue with these not working? I'm trying redundantly, though still seems not to work....

LAN does have any / all allowed, but I tried blocking on LAN and did not work.

No rules set for OpenVPN or VPN and only default blocking WAN.
The gateway for this interface is WAN.

There is a NAT rule allowing this network as source on WAN network to any.
Is that a wrong foundation effecting this? If yes, how should it be done?
If should be from the 'WifThings' as interface, rather than WAN, what would source and destination be?

Thank you!

[johnpoz]

@rennit said in Help please: Why are these rules isolating IoT not working?:

The gateway for this interface is WAN.

Huh?

The interface should have no gateway set?

Your not showing what interface these rules are on - they are on the wifithings interface? I take this is where your iot stuff is.

What exactly is in rfc1918_all_172.10? Why do you have source as any if this is on your wifithings interface? How would any other network ever be source? Other than wifthings?

This a bang rule !, so your letting anything go to anything they want other than what is in that alias.

you then ave a rule that lets wifthing net to g to anything exept what wan net and wifithings?

What exactly are you wanting to do? Stop wifi net from going where??

I really would not suggest bang rules !.. Just be explicit in what your wanting to allow or block..

[rennit]

Thank you for replying. Really appreciate it.

Got it. So if no gateway set there, how/where is the gateway designated eg. VPN tunnel vs clear WAN?

Yes, it is the wifithings interface. Similar to an IoT for me, but I also have an IoT, so differentiated, but similar. Principle exactly the same. Would like traffic to the internet only and not rest of network. Treated like IoT.

rfc1918_ALL_172.10_10... I have understood the rfc1918 to represent internal ip addresses, the rest is cut off.
That is the rfc1918 alias representing 192.168/16; 172.16/12; 10./8. for all internal traffic is what was taught in a tutorial. I should have clarified. Lessons learned.

I agree the block or allow is much more straight forward and logical. Was just trying this new tutorial as nothing was working.
Once the baseline is set properly, making a block/allow effective, I will stick to only block and allow. Makes sense.

The rule was entered as an internal ip pass inverted match.

So Pass, WifiThings interface, any protocol, source any on that interface, Alias (all internal addresses) inverted and WAN not included. I thought that then meant the opposite, so as not to pass internal LAN and WAN to pass? I read it to mean 'any source', but specifically through that interface, (which is the interface I want to block) shall not pass. Clearly not. :) This was from a YouTube dedicated to networking and a lot of pfsense stuff. Probably my user error somewhere... How should it be done properly is where this is headed, but wanted to answer your questions.

(The ! point I was guessing is the pfsense designation for an inverted rule, but I do not know that for sure.) I will look up the bang rule. Absolutely right, I should have posted a better and more detailed pics.

The any to any rule is darkened because inactive. That was just when I was setting pfsense up for the first time a few days ago and wanted to make sure all my vlans and everything had connectivity, as remarkably, I knew even less of what I was doing then, than I do today. Tutorial I saw suggested do that first, then lock it down bit by bit to work through it, for numerous reasons, then when going 'live' and all is functioning well, delete it.

I am only as good as the tutorials at this point, and I have seen and read a ton, clearly was steered wrong from the beginning, so I am very thankful for your time answering.

Wanting to do: Like this interface (and later those like it) to have internet only access, no access to rest of full LAN or anywhere else, isolated. I do not think I need mDNS or Avahi on this interface so far. This interface is PVID and is a native on a port on SG2100 with a connection to a 'dumb access point' etc. May move to tagged VLANs later, but firewall principles is my huge shortcoming here.

(Possibly a pass through to wifithings on a vlan going to, but not from. I will not know if needed until it is effectively blocked first.) I tried to research it for these devices and won't know until tested.

My concern is the tutorials and references I followed for basic setup, seemed to have set a poor foundation and left a wide open hole, because I have followed multiple methods and tried this many different ways, even redundantly, and seems not to work.

If I may, is this correct for baseline 101 beginner fresh setup:

WAN - no rules, besides the default blocks
LAN - Anti-lockout and LAN to any with VPN Interface/Gateway in Gateway drop down. (This came from VPN provider tutorial)
VPN No rules
OpenVPN No rules
This WifiThings VLAN as pictured (clearly wrong, need direction)

Then the NAT-Outbound - which I think is a big pitfall for me overall. I'm going to read up, but any principles or guidance you can share won't be wasted. Currently for this (non-VPN designated traffic) is the auto created outbound rule (working in manual outbound NAT mode though) of:

WAN
IPV4
Proto: Any
Source: Network -- IP address
Dest: Any

Essentially, what are the starting entries for a given VLAN to have general connectivity?

Is there a tutorial you recommend or perhaps a reference from an old post of your's that I could follow just to setup and understand the basics of what should be in the NAT for VLANS with VPN Tunnel vs WAN respectively, as well as baseline firewall setup for any given VLANs just for connectivity? I have seen the manuals and many hours of reading and YouTubes. May not show here, but is the case.

All VLANs, Trunks, SSIDs etc are good and functioning. It's the firewall I am stuck on. Looking to setup egress to internet via WAN and VPN tunnel/OpenVPN interfaces for different use cases (VPN tunnel itself configured correctly and working).

Looking to have proper baseline settings on all VLANs. (Native LAN interface seldom sees traffic, don't know if that is best practice or not, as parent interface I did not expect that, but everything is through VLANs.

Then the goal is to isolate and further segment a couple of parts of the network (like this wifithings), but the foundation has a hole so the whole thing is collapsing. Course if there is a better way you suggest, I'll do it.

Summarily:
Baseline configuration
Then rules to isolate segments/block or allow traffic in or out to designated parts or all of LAN.

This is all likely rudimentary for you. I am not asking without having put the time in on my own, but I clearly haven't found an up-to-date guided resource. Just need to understand what to do 1x the right way, as I am sure many other new pfsense users and/or netgate consumers do, so hopefully this will be paid forward. Thank you again!

[johnpoz]

@rennit said in Help please: Why are these rules isolating IoT not working?:

Baseline configuration

Your alias for rfc1918 is ok if has rfc1918 space in it - but why a bang rule?

Here is basic locked down rules that do not allow access to any other network you might run that is rfc1918 and allow internet

This will go out your default wan interface or vpn if you have pulled routes and let it set default. If you have not done that and you want to policy route this out your vpn, then change the gateway setting in the last rule to use your vpn as its gateway.

You allow ping to pfsense interface in this network - because how else would you validate connectivity..

You could pull out the ntp rule if you wanted. And you could pull out dns rule if your clients are only going to talk to dns out on the public internet and not pfsense.

[rennit]

Incredible! Makes perfect sense. Thank you so much for the effort. That picture is worth more than 1000 words, many hours of parsing through research, and teaches it all as well.

Regarding the 'bang rule'. I could not get any information on what you mean and do not want to assume. Below are the 4 search results from all of google:

Our current thread, a thread you replied in during 2018, one in a foreign language, and one, well, inappropriate, so I cut off the full description, but interestingly 'pfsense' was in the metadata. I also tried various search strings e.g. bang rule firewall etc...Nothing. What is a bang rule?

If you are referring to the other rule I tried, not pictured above, it was:

That alias was all interfaces etc, with the exception of the current and the WAN I wanted it to go out through. Having both rules was because the first failed and I was just trying to see if I could get anything to work.

What you did - direct allow/block also makes more sense to me and inline with how I think, but I was reaching and trying various methods people were suggesting before asking for help and taking people's time directly. That rule pictured is from a fairly well known source actually, so thought was worth a shot. Definitely did not come up with that myself. Just trying to figure everything out. I still am not sure why those two together did not work at all, but I completely get what you did and I can follow that logic and apply it with different rules, to different interfaces going forward.

Hopefully to help future readers as well:

For learning the methodology to apply to all VLANs, so as to not have to take your time again on this:

It seems to me the premise is that everything is already open internally/LAN to LAN (I know external/WAN rule default is block all) so to block some, but not all, create rules to say specifically what want to Pass e.g. ping, NTP, DNS (followed top down) then add what to block i.e. firewall and RFC1918 addresses, then where can go/Pass entirely (any) from what is left i.e. WAN or VPN tunnel gateway. Is that good standard practice? Please correct me if wrong.

(Essentially work backwards from all open on LAN and all blocked on WAN.
If blocking something, but want specific things within, then add those as pass first.)

Questions:

1. If the below is a good example of the xyztest foundational/starting interface allowing all and routing out through WAN (or can change to VPN tunnel); then should such a rule be applied to every VLAN going out that gateway as a foundation? Done?

On xyztest interface

2. Then if did not want 'xyztest' to have access to e.g. 'abctest' interface -
   Place a block rule (above gateway) on xyztest net as: source xyztest net then destination abctest net?

On xyztest interface

Is that correct to block all traffic from xyztest to abctest, but abctest could still reach xyztest?

3 . Does the DNS pass rule you made eventually route external to my default DNS servers or is that strictly internal?

4. What is the best way to test if block rules or pass rules are working effectively? Also, considering Ping is allowed.

5. (Last) My network consists of all vlans. I do not use native LAN as I have been reading is good security practice not to. I am turned upside down on how to set rules for a dedicated management VLAN that can securely communicate with many different VLAN's on different subnets, including trunked and tagged endpoints (e.g. an AP or switch or peripheral) and also while not being a security hazard.

Is there any chance you could post just a picture of the rules for such a setup and I will figure it out from there? I have been searching and reading and watching videos and cannot find just a picture or description of how to do it.

Truly appreciate your help. Unless you want further discussion or questions, I'll not ask for more regarding the above, to respect your time. I could also post 5. in a new post to make it easier to search. Hopefully this will be helpful to many others as well. I have found a lot of questions out there on it, but not direct answers for the non-professional. Thank you!

[johnpoz]

bang rule = inverted match, it uses ! (bang) as symbol.. Those not something to play with unless you have a specific reason and need. And need to validate they are working as you want.

In the past there was some issues when you had vips setup and tried to use those..

in your abc xyz rules - yes, you would be blocking xyz from from abc, but abc could still talk to xyz depending on the rules on abc.

And completely agree single picture can be worth 10k words!

I would be more inclined to always have wan dhcp be default, and policy route things I want out vpn. Vs what you show there sending traffic out wan dhcp. I also like to use reject vs block on internal networks, since it can save retrans when the device gets the reject.. But rejects normally not a good idea on the wan side of things.

Inverted matches can be a way to shorten rule list, etc. And I agree they should work - but per some great advice and discussion with Derelict over the years. I have come to agree with him that they are not normally a good idea.

[rennit]

haha got it. I am so chest deep in firewall weeds that I was thinking only in that context. Knowing that I don't know much, I thought was a specific rule I needed to learn about, not the general English synonym. :))

Understood. I will not be using bang rules then.

Okay, I'll go with wan dchp default.

Thank you for the additional input on block vs reject. Makes sense. I'll follow that guideline. Appreciate you mentioning.

Regarding question 4 above and testing. I created the rules exactly as you laid out. I then disabled the Pass Ping rule. Then went to Diagnostics -->Ping then set source address as wifithings. 0% packet loss. I then went back to the block rfc 1918 rule and tried it with source as wifithings address, because I do not know how the ping utility works when selecting source, so figured try both ways, and 0% packet loss again.

What is the best way to verify the settings for blocking like that? I do not know if I am not testing right or it is not blocking effectively.

[johnpoz]

Keep in mind that if you change from an allow rule, or put in a block rule you have to worry about existing states.

While icmp is suppose to be stateless - pfsense still keeps track. So if you had an allow rule, and pinged, and then removed the ping rule and was still able to ping - its most likely related to the "state" of your ping still being there an allowing for it.

You can clear the state, or wait for it to time out on its own before testing again.

I personally se no reason to not allow ping.. It is most valuable to be able to ping the gateway from a client to validate connectivity.. I always allow ping - even on my wan..

[rennit]

That is hugely enlightening and a great consideration to know about in general. Thank you!

I only disabled it temporarily only for testing purposes, because I do not know how to test it other than with ping. With the ping pass rule enabled, what is the best way to test that all RFC 1918s are being blocked from that interface?

[johnpoz]

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.

[rennit]

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?

[johnpoz]

@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.

[rennit]

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...?

[johnpoz]

@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?

[rennit]

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!

[johnpoz]

@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..

[rennit]

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:

1. @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

2. 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.

3. 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::/10

I 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!!

[johnpoz]

@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?

[rennit]

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

[rennit]

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...