Hi,
the automatically generated rules usually include a rule named "let out anything from firewall host itself" that doesn't really restrict its match:
2025-11-06_13-34.png
(this is from my OpenVPN Rules, /firewall_rules.php?if=openvpn)
I assumed that some magic would be associate with those rules to only match for addresses originating locally.
But that doesn't seem to be the case, my log is full of entries like:
2025-11-06_13-37.png
This is certainly no traffic that originated on my firewall host itself. It is intended production traffic between a system on the internal LAN and a machine connected via OpenVPN.
Why does this rule match? Is "id: 7999" a flow ID or a rule IT? How would I find out which rule this actually is? I guess that the rules do have a more well-defined identifier other than the label, don't they? The magnifying glass with the "fae55" link makes another browser tab pop up for a short while and then close again.
Is there a place where I am supposed to enter the IP addresses of my local firewall host, or is the system supposed to pull that magically from system configuration?
I would appreciate some insight. Thank you.
Greetings
Marc
That packet was first matched and permitted on direction IN. When it is then forwarded OUT towards its destination that action is permitted by this global rule. It's already "in the firewall" in some mbuf, right? So when it is passed on, it is "from the firewall itself".
Without that rule you would need IN and OUT rules for each service you want to allow. So the general idea is that you only need IN rules and once a connection is permitted, the firewall does not care which way the packet leaves it.
See this note in the docs (https://docs.opnsense.org/manual/firewall.html#overview):
QuoteTraffic leaving the firewall is accepted by default (using a non-quick rule), when Disable force gateway in Firewall ‣ Settings ‣ Advanced is not checked, the connected gateway would be enforced as well.
Quote from: Patrick M. Hausen on Today at 01:47:19 PMThat packet was first matched and permitted on direction IN. When it is then forwarded OUT towards its destination that action is permitted by this global rule. It's already "in the firewall" in some mbuf, right? So when it is passed on, it is "from the firewall itself".
So it is also "from the firewall itself" when it's a forwarded packet? Now that's a surprise.
I would have expected that rule to be limited to, like, outgoing queries originating from the local unbound, or when the local routing daemon initiates a BGP session .
Quote from: Patrick M. Hausen on Today at 01:47:19 PMWithout that rule you would need IN and OUT rules for each service you want to allow. So the general idea is that you only need IN rules and once a connection is permitted, the firewall does not care which way the packet leaves it.
That is very very different from what a Linux veteran is used to. In Linux, a packet that is routed by the system is only seen by the firewall rules once, in the FORWARD chain. You usually allow the first packet of a TCP connection explicitly with a dedicated rule, and the other direction and the following packets of the connection gets allowed by a catch all rule that allows everything that belongs to an ESTABLISHED connection.
I do fully understand that FreeBSD is not Linux and that I should have broadened my firewall horizon beyond that Linux thing a decade ago, but that's the way it happened and now I need to understand the differences.
I do not need to understand why that rule that will handle 99 % of the traffic the box moves is set to "logging", though.
Greetings
Marc
Quote from: Zugschlus on Today at 01:56:29 PMI would have expected that rule to be limited to, like, outgoing queries originating from the local unbound, or when the local routing daemon initiates a BGP session .
1. "From the firewall itself" is just a description, as you are probably aware.
2. The Unix socket interface and BSD family IP implementations do not keep record of the source interface through which a packet arrived anywhere in the stack. Routing decisions are made on destination address only - unless policy routing is implemented and e.g. tags are used (which pf and hence OPNsense can perfectly well do), but not by default.
So a packet sits in some buffer to be forwarded to its destination - it is impossible to know if it originated locally or entered through any network interface.
Don't know if Linux does this differently but we occasionally have heated discussions with people demanding that a reply packet leave through the interface on which the request packet arrived. Only nobody knows at that stage in the processing. The topic arises when folks stumble over asymmetric routing issues as you might guess.
Yeah, the difference in firewall logic of pf and Linux's way of doing it is one of the reasons why OpnSense and pfSense cannot easily be migrated to Linux (which would be beneficial in terms of driver support). Got me as well a while back and I still have got some reservations about FreeBSD...
As for IN and OUT rules: Once you get accustomed to it, they are easy to handle (i.e.: forget about OUT rules).
Investigating outbound rules in OPNsense (https://forum.opnsense.org/index.php?topic=49413.msg250624)