Hi all, I'm setting up my OPNsense router for home use and are moving towards a segmented network. Currently I'm writing the firewall rules which span multiple interfaces. I've got some basic aliases (which are vlans/interfaces) for which I specify the rules. Now I want to block by default if none of the rules match. To prevent subnets from losing internet access I should whitelist traffic within their respective subnets (or at least the gateway address). I'm aware that this is possible by creating a rule for each interface (such as this -> https://ibb.co/MRh22bP). However, I was wondering if there is the option to specify this once as a floating rule instead of creating an ALLOW XX NET -> NET XX ADDRESS rule for each interface.
Why would said traffic ever hit the firewall? Hosts only use routers to reach subnets other than their own.
Hmm, I was under the impression that this was the case. Can you explain why the block rule in the attached screenshot (https://ibb.co/zRCx8Nt) prevents internet access on the IOT network? If I disable this rule I am able to reach the internet on the IOT network (which is part of the trusted_for_internet alias). This does seem to suggest that this traffic is passed through the firewall.
As floating rules are matched before interface rules the final rule (which is on the interface level) is not matched, hence the question for a more generic floating rule to solve this problem.
Don't use floating rules if you don't know what you are doing.
Could you elaborate on why not to use floating rules? Why the distinction between floating rules and interface rules (which are then okay to use without knowing what you are doing?
For manageability floating rules seem to require less entries since it allows the use of aliases. For instance, I've got multiple interfaces/vlans from which I want to access the management portal. I could create an alias for this which includes all these interfaces/vlans and a single floating rule or I could create the same identical rule for each member of this alias in the interface section. For me, managing a single rule and a grouped access list has my preference.
But, as you suggest, I'm fairly new to this topic and I'm open to suggestions on how to handle a situation such as described above :)
I would suggest to use the interface group feature:
https://docs.opnsense.org/manual/firewall_groups.html
I'm kinda new to OPNsense as well, but shouldn't the rule allowing access to the gateway be higher on the list than the rule blocking access across all private networks? First match wins, right?
All VLAN internal traffic stays confined to the switches. All inter-VLAN traffic is blocked by the deny rule, but it also happens to include the gateway of each VLAN, preventing internet access (and DNS, DHCP...). The rule allowing access to the gateway is never reached.
It would be easier to tell if the content of the aliases was provided.
In the end I got it working just using floating rules (https://ibb.co/5W4LFQk). I've also looked into groups, as suggested here, but ended up not using it. It is possible to create rules with <GROUP> net but not possible to specify <GROUP> address, which is possible with regular interfaces. I'm aware that this is perhaps not the best practice, but I really like having all my rules in one place. Perhaps if the number of rules becomes to large that I will relocate them to their respective interface.
If there is a way to condense the whole allow traffic within subnets block I'm still very interested to hear how it can be done!
Thanks for the help!
IMO, the key change here was moving the 'allow net -> address' rule(s) above the 'deny * -> private range'.
I honestly don't get it and there might be something hidden in the setup of the OP that is only visible by direct close inspection or if they would post all the configuration instead of a prose description.
There's another thread about airplay that is more or less the same.
Within a single broadcast domain the firewall (the appliance that is the default gateway) is never involved in any of the traffic. It all goes from host to host via the switch.
Now if there is no switch and they are using OPNsense with a bridge to have multiple ports in e.g. LAN, that is a completely different story, but neither in this nor in the airplay thread any bridge is mentioned so I must assume a switch is used.
So what is it that is at play here?
Quote from: Patrick M. Hausen on October 09, 2024, 07:47:50 PM
I honestly don't get it and there might be something hidden in the setup of the OP that is only visible by direct close inspection or if they would post all the configuration instead of a prose description.
There's another thread about airplay that is more or less the same.
Within a single broadcast domain the firewall (the appliance that is the default gateway) is never involved in any of the traffic. It all goes from host to host via the switch.
Absolutely.
Quote from: Patrick M. Hausen on October 09, 2024, 07:47:50 PM
Now if there is no switch and they are using OPNsense with a bridge to have multiple ports in e.g. LAN, that is a completely different story, but neither in this nor in the airplay thread any bridge is mentioned so I must assume a switch is used.
So what is it that is at play here?
There's this:
Quote from: StotoV on October 06, 2024, 07:52:30 PM
Hmm, I was under the impression that this was the case. Can you explain why the block rule in the attached screenshot (https://ibb.co/zRCx8Nt) prevents internet access on the IOT network? If I disable this rule I am able to reach the internet on the IOT network (which is part of the trusted_for_internet alias). This does seem to suggest that this traffic is passed through the firewall.
...
In my experience on other platforms, deny xx net -> xx net (or private ip ranges) tend to include the gateway of xx and thus block DHCP, DNS. The latter gives the impression that internet access is blocked...
Arguably, a static address and DNS pointing directly outside (not the gateway) restores internet access as well.
Oh, and I tested this as well on my setup (OPNsense as a filtering bridge - between my router and main switch - with a rule on the bridge) and got the same behavior. DHCP and DNS fail.
I've seen deny xx net -> xx net used to achieve Wi-Fi "guest" behavior on wired networks...
[Edit: that last part of course only works as a switch rule.]
Quote from: EricPerl on October 09, 2024, 09:34:08 PM
Oh, and I tested this as well on my setup (OPNsense as a filtering bridge - between my router and main switch - with a rule on the bridge) and got the same behavior. DHCP and DNS fail.
In the context of a filtering bridge of course all of what I wrote changed fundamentally! Duh! ::)
But the OP did not mention a transparent filtering bridge setup.
So his heading was wrong all the time. It looks like he wants to take to much shortcuts. Also he is allowing any protocol on any port. That is doing it all wrong.
Doesn't a 'deny xx net -> xx net' also block DHCP and DNS (pointing at the gateway) in a more traditional setup?
I tested this on my bridge because that's my setup at this time but it doesn't change a whole lot IMO).
It sits between my router and my main switch so it only sees traffic going to the gateways of each VLANs.
All intra VLAN traffic stays confined to the switches.
[Edit: I suspect the OP uses a traditional setup, not a filtering bridge]
Quote from: Bob.Dig on October 09, 2024, 10:13:13 PM
So his heading was wrong all the time. It looks like he wants to take to much shortcuts. Also he is allowing any protocol on any port. That is doing it all wrong.
As a newbie myself, I can see where the OP is coming from.
I believe he's going for a compact set of rules that applies to all interfaces (not obvious how many).
So knowing intra VLAN is not subject to OPNsense rules, I read:
* Allow a well-known set of machines to do anything
* For each VLAN, allow clients to access the gateway of the VLAN (at least DHCP, likely DNS...)
* Deny all clients to private network (which effectively blocks all inter VLAN traffic)
* Allow wide internet access to a second set of machines.
Adding a VLAN requires updating 1 alias and adding the gateway rule.
I chose a simpler path, with one rule per source, and no floating rules.
I arguably have more aliases.