Firewall has no implicit deny all

[n1nja]

I have multiple VLANs on my network and for the life of me I cannot figure out why the implicit deny all doesn't seem to work.  Take for instance, I have my wired VLAN and my WiFi VLAN:
LAN:
10.0.0.0/24
WiFi:
10.30.0.0/24

When I ping from my WiFi net to my LAN net, it should be dropped.

But instead, I'm seeing it permitted and matching this floating rule that was automatically created with the description:
"let out anything from firewall host itself"

There's even a "default deny any" rule above that one.  So I'm not sure where these rules are coming from and it isn't secure.

Where are these coming from and how do I secure it?

[utahbmxer]

What rules do you have in your WiFi interface/list?

I was genuinely curious, so I fired up my test instance to see.  I found the same behavior between two networks (pinging from LAN to LAN2), but as soon as I disabled all the rules for the LAN interface, I got a DENY with "Default deny rule".

Here's what I think is happening for you.  You likely have a rule in your WiFi list that is allowing destination to ANY.  So traffic is allowed in WiFi (and you likely don't have logging turned on for that rule), and then the floating rule is allowing the traffic out of the LAN interface and that is logging as "let out anything from firewall host itself".  (The floating rule is for traffic leaving an interface)

What I did for my internal network rules on DMZ, Guest, etc. is I created an Alias which has all the RFC1918 private networks (you could also be more specific and just use your actual networks).  Use this alias as the destination in all your rules that would typically be "Any", but you need to check the "Invert" checkbox.  This way my rule allows all traffic to destinations that aren't private such as all the other networks behind my OPNsense.

[n1nja]

OK this is what I ended up discovering earlier and it works, but it kind of baffles me.  I don't even think pfSense did this but I could be wrong.  It's a little weird how pf/opnsense present it in the UI but I'm wrapping my head around it.  It's honestly a bit more work to set up policies in this fashion as well. 

Like if I want a wifi "zone" and a wired "zone" and want to permit both out to the internet, but not to one another, I need to set it to permit wifi->!rfc1918, then put my exceptions above that.  Unless I'm blind there seems to be no prebuilt object for referring to the internet so I just made my own as you did.  At first I had it set to bogon networks but then I realized that object is actually blank by default, from what I can tell.

Is there no better way to accomplish this?

[utahbmxer]

I only have a couple years experience with OPNsense (and a few more with PFsense), but I don't think there is another easy way since they don't have the concept of zones that you can associate interfaces too.  I came from Sophos UTM which had a out of the box network object called "Any Internet IPv4" (or something similar) which I think is probably just doing the same thing as the invert box in OPNsense.

Would love to hear what others are doing, but this is the cleanest way I've found of preventing traffic between internal networks.

[jimjohn]

I second that approach. Use the RFC1918 alias and you are good to go.

[n1nja]

OK then that's the way I guess I'll have to do it.  I've got a ton of years of experience with Palo Alto and I really like the approach there.  But ya, that's zones.

[jimjohn]

OK then that's the way I guess I'll have to do it.  I've got a ton of years of experience with Palo Alto and I really like the approach there.  But ya, that's zones.

I found a steep learning curve with OPNsense … but hey, the more you have to do manually, the better you understand what you are doing.

[Greelan]

I’m a little bemused by the OP’s comments in this thread.

Yes, OPNsense (and pfSense, because it behaves pretty much the same, just with less visibility in the UI for example with automatic rules) may approach things a different way to other solutions. But I can’t see how it creates more work doing things. On another solution a rule has to be created to allow a subnet to a defined “internet object”. On OPNsense a rule has to be created to allow a subnet to everything but local IPs (ie to the internet). Still one rule. In both cases if exceptions for local IPs are needed, additional rules need to be created.

Just because you are not familiar with something or don’t yet understand it doesn’t mean that it doesn’t work or is wrong (case in point is the title to this thread, which is that exact opposite of how OPNsense operates).

In my case I have created a firewall group of all local interfaces, called ALL_LOCAL. This gives an automatic alias of ALL_LOCAL net, which contains all the IPv4 and IPv6 subnets configured on those interfaces (and so changes with changes to those networks or interfaces in the group). If I want to block a subnet from accessing other local subnets and only allow internet access, on the allow rule I specify the destination as ! ALL_LOCAL net. If I want a common rule to apply to all the local interfaces, I specify it on the ALL_LOCAL interface. Nothing hard about that.

[n1nja]

My home network has 5 VLANs.  The networks I work on day to day often have even more.  From my view, it's a royal PITA to have to create an address object for all these VLANs and remember to add it to the bottom of the rule sets.  In addition, if I want a mix of access on a mix of VLANs now I'm adding multiple rules with multiple address objects.  Let's say for example I have this:

MGMT: VLAN 1
Trust: VLAN 2
Untrust-Wired: VLAN 3
Trust-WiFi: VLAN 4
Untrust-WiFi: VLAN 5
Cameras: VLAN 6
Internet

Now I want all my VLANs except for cameras to reach the internet, and I want trust to permit full access to cameras and MGMT, and I want trust-wifi to access just trust, and with a mix of full open or port based.

With the approach of security zones this is quite simple.  With zones everything is dropped no matter what.  If you want the Trust interface/zone to reach the internet, you just add a simple rule like trust to internet, done.  In the case of opnsense and pfsense, you can't do that without making a custom address object. But it's a one time thing so not a big deal... until you get to wanting trust-wifi to reach wired and internet.  Now you're talking a new address object, or 2 rules. And you have to mentally validate your rule order which isn't necessarily needed with the zone method.

Just because I didn't understand the way it worked here isn't to say it's wrong, don't mistake me.  My point is convenience and simplicity.

I'm not sure about your comment on how my title is the opposite of how opnsense works.  It definitely has implicit deny all, I have never come across a firewall that has an implicit permit all (unless it's meraki IVR).  The catch in my case was that I was assuming each rule set attached to each interface was dropping anything not allowed, not realizing that a rule on another interface can affect the interface I was looking at.  IE: permit wifi-trust to all permits to wired firewall rule set, even if the firewall rule set only has 1 rule to permit internet access, for example.  Again I'm not saying the approach is wrong, just that I didn't realize it didn't work that way.

In my view, much easier to do it the zone way.

[Greelan]

Admittedly I haven’t used a firewall with a zone approach, so can’t directly compare on the question of ease or convenience. I do like the granular control that OPNsense provides, which IMO is easy to work with once the principles are understood.

I still think that using firewall groups can give you a lot of the convenience you are looking for. Would be worth playing around with those.

The basic philosophy of OPNsense is to approach firewall rules from the perspective of ingress on an interface into OPNsense (there are exceptions, but they are special cases). This makes sense from an efficiency perspective - why process a packet only to drop it on egress? Once you get your head around that, the operation of the ruleset becomes much clearer. So if you have a rule on wifi_trust to allow to any, then it is obvious it will do exactly as it says - allow wifi_trust to any. You could stop this by configuring a block rule on another interface that applied to packets coming OUT of that interface from a source in wifi_trust, but that is an inefficient and not particularly clear way of addressing it.

My comment on the thread title was simply to note it is wrong - it says “Firewall has no implicit deny all”. But as you note, OPNsense does - all packets are blocked by default coming into any interface on OPNsense UNLESS there is a specific rule allowing them. In your case you had a specific rule allowing them, you just didn’t appreciate that was the case.

[n1nja]

I think really the summary of it all is zones are easy because if you create a zone for internet, and attach it to your internet port, anything routed out that interface is destined to the internet zone, so that will catch anything headed in that direction, regardless of IP address.  It does make things really easy. 

For example:
from [wired] to [internet] action: permit
from [wired] to [wireless trust] application: HTTPS action: permit

Above would let wired clients have access to internet and just HTTPs to the wireless trust zone.

For *sense you'd have to do something like
from [wired] to [wireless trust] port:443 action: permit
from [wired] to [any] except [lan subnets] action: permit
[address-group: lan subnets] <- manually maintain this as you add vlans and so on

Yeah the title is a bit of a thing - my intent was to point out how the way my firewall is configured at this time, it seemingly has no implicit deny all.  But I get what you mean.

In any event I need to adjust how I view the firewall on this thing.  Thanks for the clarification!

[utahbmxer]

In my case I have created a firewall group of all local interfaces, called ALL_LOCAL. This gives an automatic alias of ALL_LOCAL net, which contains all the IPv4 and IPv6 subnets configured on those interfaces (and so changes with changes to those networks or interfaces in the group).

Wow, been using OPNsense for a little over a year, how have I not known about Interface groups?!  Thank you for opening my eyes.  LOL.

[Greelan]

LOL. I was aware of them from the beginning but couldn’t see the point until I was also shown the light by another user. They can be quite useful.

Bear in mind that Group FW rules are processed before individual interface FW rules. OPNsense’s order is Floating, Group, Interface. Of course you can make stuff even more funky by using non-quick rules.