Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for ether anchors and rules #8074

Open
2 tasks done
darkk opened this issue Nov 20, 2024 · 0 comments
Open
2 tasks done

Add support for ether anchors and rules #8074

darkk opened this issue Nov 20, 2024 · 0 comments

Comments

@darkk
Copy link

darkk commented Nov 20, 2024

Important notices

Is your feature request related to a problem? Please describe.

I'm developing a plug-in that maintains a set of firewall rules for policy-based routing that depends on a MAC address of user's device. That's not a security feature, but a convenience one: all the devices are in the same L2 segment, but OPNsense might route certain traffic through VPN gateways depending on the device.

IP-based rules are not convenient in this case as the network is dual-stack and hosts might have numerous IPv6 addresses with limited lifetime.

pf supports tagging of L2 packets using the following rules:

# pfctl -s all
[...]
ETH RULES:
ether pass in on re0 from 44:85:00:f5:01:b3 l3 all tag no2tun
ether anchor "tag2tun" l3 all

The tag might be used later on in filter and nat rules. Note that ether anchor syntax differs from nat-anchor and rdr-anchor a bit, namely "-" is missing.

Describe the solution you like

I was following the idea of miniupnp plugin and considered adding an anchor for my plugin. Unfortunately, current code in OPNsense/Firewall/Plugin.php and etc/inc/filter.inc does not support anchors of ether type.

Describe alternatives you considered

The best alternative with no patches I can currently imagine is a sidecar process that parses logs for new IP addresses in the specific L2 segment, checks out arp/ndp neighbor table and updates pf table with IP addresses for the source-based routing.

Some ad-hoc cron job injecting an anchor if it's missing is another option.

Splitting the L2 segment into policy-per-vlan schema might sound like an option, but, unfortunately, it's an suboptimal option for the networks I'm managing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant