LAN to OPT Rules?

Started by absolute_matt, July 18, 2022, 11:52:56 AM

Previous topic - Next topic
Everything I search for on this topic is about LAN to OPT2 NOT working. My question is the opposite. I have traffic flow but I dont understand why and I really want to ensure I have a grip on all the rules in play.

Ignoring the WAN interface. I have:
LAN    192.168.13.1/24 and
OPT2  192.168.15.1/24
they are physically seperate ports attached in isolation to respective devices.

My install is out of the box. I havent created any firewall rules myself, the only ones there are the automatically generated Floating/Interface rules created by OPNSense.

Looking at the default rules I can see:
- a floating outbound "let out anything from firewall host itself" (which I assume covers ALLOW outbound traffic for ALL interfaces), and
- on the LAN interface an inbound rule "Default allow LAN to any rule" (which I assume covers inter LAN communication).

There are no rules on the OPT2 interface that I can see being relavent. There is even a comment in blue on the OPT2 interface firewall page "No OPT2 rules are currently defined. All incoming connections on this interface will be blocked until you add a pass rule"

So.... my assumption was that traffic travelling from LAN to OPT2 would have been blocked by the floating inbound "Default deny rule" that is top in the list.

However this doesnt seem to be the case. I can freely browse and control ESXi on OPT2 via a web browser on LAN.

There must be something that I am missing in all this but I cannot see it. Anyone able to explain why I can get from LAN to OPT2 freely?

Cheers,

Matt

Quote from: absolute_matt on July 18, 2022, 11:52:56 AM
- on the LAN interface an inbound rule "Default allow LAN to any rule" (which I assume covers inter LAN communication).
This rule covers exactly what it says. Everything from LAN to anything else is permitted. From LAN to LAN, from LAN to WAN, from LAN to OPT ...

You need to place a deny rule "from LAN net to OPT net" on the LAN interface above that allow rule (rules are processed in order).

"Any" means any. And it's a reasonable default for a new firewall because you have the "bad" WAN and the "good" LAN and all devices on LAN should be able to reach the Internet ...

This probably helps:
https://docs.opnsense.org/manual/firewall.html#overview
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Thanks for coming back.
I actually saw a similar response from you https://forum.opnsense.org/index.php?topic=29343.0 in my search but still didnjt have it right in my head.

I expected floating rules to apply to all, Interface LAN rules to apply to the LAN port and OPT interface rules to apply to the OPT port. Meaning OPT's ingress would be controlled by the union of floating and OPT interface rules only.

Given your response, and reading up on it some more, it appears an inbound rule on the LAN interface will also influence the OPT interface's ingress in this way. And I presume this is all working becasue the first match/precedence hits this LAN allow rule before the floating "default deny all" that covers OPT.

Perhaps it was the message "All incoming connections on this interface will be blocked until you add a pass rule" on the OPT2 interface rule page that threw me. I was expecting to have to add a "pass rule" on OPT.

Thanks for helping to confirm that I need the deny on LAN before the allow.

Have a nice day!




Quote from: absolute_matt on July 18, 2022, 12:46:13 PM
Given your response, and reading up on it some more, it appears an inbound rule on the LAN interface will also influence the OPT interface's ingress in this way. And I presume this is all working becasue the first match/precedence hits this LAN allow rule before the floating "default deny all" that covers OPT.
OPNsense is a stateful firewall. Once the ingress on LAN is allowed, a connection is established which allows the return packets from OPT to LAN to also pass.

All these in/out allow/deny decisions are made about connections, not individual packets. For TCP that's obvious and simple, for UDP timeouts are applied.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)