If stateful, why do I need to allow "out" AND "in" on WAN interface?

[BillyJoePiano]

Someone please explain this to me.  I am trying to configure the firewall rules for a new installation of OPNsense, and this is my first time using it.

Every other firewall at layers 3 & 4 which I've configured in the past -- iptables in Ubuntu, ipfw in FreeBSD, Cisco, and PaloAlto -- maintains a state for outgoing packets to the WAN/Internet.  We can allow NAT'ed packets "out", and if the firewall is stateful then the response packets are also allowed in under that stateful "allow out" rule.  We should NOT need to create another unrelated "in" rule which allows these response packets, since they are already allowed by the statefulness of the "allow out" rule.  No?

Unfortunately, in OPNsense, I have been unable to get internet access from my LAN unless I allow both "out" AND "in" for the rule on the WAN outside interface, and it only works in the floating rules section where I can say "any" to direction.  This seems to be a major security risk, given that we do NOT want to "allow in" packets which are not stateful responses to a conversation which was initiated from the inside (...unless they are going to the DMZ server, but that is another special set of rules).

Also, I am having another problem -- In trying to troubleshoot this issue, I have been unable to get the default deny to show up in the logs, even though it says it is being logged.  I even tried adding my own default deny to the Floating rules (a "last match" deny) and enabled logging on that, and the denials are still not showing up in the logs.  What is going on here?

Thanks in advance for your help with this.

[Demusman]

You're thinking is backwards when it comes to opnsense.
All you need is "in" rules unlike other firewalls. I don't even know why there's an "out" option to be honest.

This firewall blocks traffic going into the interface you're connected to.
So if you're on the LAN interface, packets are blocked coming from your pc at the entrance to the LAN interface.
What you will find odd is the "out" of the LAN interface is traffic going back to your PC from the LAN interface.
So every interface has an "in" and an "out" and both go to the connected network, "out" isn't going to the WAN IOW.

Here's a good analogy to understand it.
Your front door on your house, if you don't want to let someone into your house, you would stop them from entering the front door. Once they're in your house, they are free to leave out any other door.
So traffic you don't want, you block "in".
Traffic allowed in can go anywhere it wants.

My guess is you've been creating "out" rules and found they do not work unless you also create an "in" rule.
Do the opposite, just create "in" rules.

This may also explain the logging.

[BillyJoePiano]

Thanks for your help on this.

Perhaps I'm misunderstanding or didn't explain the situation correctly.  Are you saying that the meanings of "in" and "out" are reversed in OPNsense, from what I'm used to in other contexts?

For example, if my LAN client computer makes a web request, I think of this as being an "in" at the LAN interface, and an "out" at the WAN/outside interface.

To be clear -- I do have an "allow in and out" rule for the LAN interface (again... it seems it needed to be in the floating rules), but the one that I'm concerned about is on the WAN interface where I need to "allow in", which is like opening the door wide open, when I only want statefully established responses allowed in.

[Demusman]

Thanks for your help on this.

Perhaps I'm misunderstanding or didn't explain the situation correctly.  Are you saying that the meanings of "in" and "out" are reversed in OPNsense, from what I'm used to in other contexts?

Correct. IN is traffic into the interface FROM the network connected to that interface.
OUT is traffic FROM that interface TO the network connected. Doesn't have anything to do with any other interface on the firewall.

For example, if my LAN client computer makes a web request, I think of this as being an "in" at the LAN interface, and an "out" at the WAN/outside interface.

Nope.

To be clear -- I do have an "allow in and out" rule for the LAN interface (again... it seems it needed to be in the floating rules), but the one that I'm concerned about is on the WAN interface where I need to "allow in", which is like opening the door wide open, when I only want statefully established responses allowed in.

Don't use floating rules unless absolutely needed. Only make IN rules and you'll be fine. You shouldn't need/use any rules on the WAN. Use a vpn instead.

So with no rules on WAN, and an Allow Any on LAN, you'll have internet access.
Source will almost always be the connected network or devices on that network. Not true for floating rules.
So if you have 3 subnets, LAN, Cam and IOT, and you want a rule to block CAM from LAN, that rule will go on the CAM interface, and have CAM net as source. Putting a block rule on CAM with LAN as source will never be true.
Make sense yet? It's different than any other firewall I've used too. But once you understand you're blocking at the front door, it makes sense.