-
Notifications
You must be signed in to change notification settings - Fork 718
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
Wildcard netmask support in aliases and firewall rules #4952
Comments
no promises, but at a first glance the trick shouldn't be very complicated to calculated networks from a mask. |
Sounds great. Let me know if I can help testing or something. |
Will do, we have some other alias changes scheduled to be merged (#4941), so I wasn't planning on starting with this one before it's merged, so if I can spare a bit of free time before the 21.7 in July that would be nice, but as mentioned before, no promises. |
ok, |
The trick is to calculate them upfront, if we can do that (easily), we can add it. The filter itself doesn't support this type of matching for as far as I know. |
It's a work in progress (needs ui/api code), but 05d3224 calculates the wildcard netmasks when provided in For the record, support for wildcards will only be provided via aliases, pf doesn't support this format natively. |
Is this to be added as an alias? I have some time today, I could take a crack at it if you've not started it. |
@marjohn56 it should be valid input for the network alias type, you can easily try it out manually when changing an alias in |
Interesting... Not sure what validation it needs... worked perfectly. We have a nice aliastables entry which looks spot on. |
hmm, it seems to validate indeed, but it doesn't look intended. we might need to be careful then what it did before adding this. |
Your obviously so good at this that things work without thinking about it. 😉 |
I would be good if it was able to show the subnets calculated when validating the wildcard netmask |
you can use the table view for that (Firewall -> Diagnostics -> pfTables), at this point the interface doesn't know (and is generic behaviour for all alias types) |
@marjohn56 I really doubt that ;) if it smells like a bug, it usually is. The question is what |
Well I don't use network aliases but if I enter the network 192.168.4.1/24 then I get an aliastable entry of that. Not sure the wiki is correct as it sort of suggests entering !192.168.1.0/24 - which is not accepted, that would just require inverse of the alias in the rule creation, correct? |
the |
Sorry.. my typo. If I enter !192.168.5.0/24 - that works.. I can sort of break it by doing something stupid like !10.5.1.4/0.0.255.0 - which gives me an empty aliastable entry. |
So the only validation I think might be needed is if a user did enter something !192.168.0.1/0.0.255.0 - which results in an empty aliastable, unless you think that the user should be able to enter !192.168.0.1/0.0.255.0? Sort of confusing myself now! |
@marjohn56 if it smells like a bug, it usually is 611304a ;) |
Updated to 21.1.7 and if I use "192.168.0.0/0.0.255.0" it does list correct in pfTables. But if I use "192.168.0.0/0.0.252.0" it lists 64 entries (e.g. 192.168.232.0) which is not correct. I would expect 192.168.0.0/24,192.168.1.0/24, 192.168.2.0/24 and 192.168.3.0/24 |
If I use 192.168.0.0/0.0.3.255 pfTables lists 192.168.0.0/22 |
@OleSta wilcard calculation is rather complex, in case of the |
Not sure how to use this. I would like to create firewall rules and aliases that gives access/define IP's which ends at e.g. x.y.z.64-67 |
|
would 0.0.0.64/30 work with the firewall rules? Guess I have to test next week. |
using the 0.0.0.64/0.0.0.3 does not match any packets in the firewall rules I tested with. Did a test with 10.0.0.64/0.255.255.3 |
Why does both 0.0.0.64/255.255.255.3 and 10.0.0.64/0.255.255.3 give 65536 entries in pfTables? |
safety limit : core/src/opnsense/scripts/filter/lib/alias.py Lines 97 to 101 in 17dff05
|
Why do I get one more than the limit? Yes 0.0.0.64/255.255.255.3 fails with overflow I see. Why do I get this in my log: |
If I add many wildcards to an alias I get: Invalid argument. [test_wildcard] |
Looks like its working with a few bugs and a limit of 65536. |
… to obey ! when being provided.
…in alias backed code.
…and make sure to obey ! when being provided.
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
[x] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
[x] I have searched the existing issues and I'm convinced that mine is new.
[x] When the request is meant for an existing plugin, I've added its name to the title.
Is your feature request related to a problem? Please describe.
Yes, we have to create MANY firewall rules instead one.
Describe the solution you'd like
I would like to create firewall rules and aliases that gives access/define IP's which ends at e.g. x.y.z.64-67
Using another firewall provider we could do this by using wildcard netmasks as this 0.0.0.64/0.0.0.252
Describe alternatives you've considered
Cannot handle it in OPNsense right now without creating a lot of firewall rules.
Additional context
Cisco example syntax:
Match all 192.168.x.1 addresses:
permit 192.168.0.1 0.0.255.0
Barracuda inplementation:
https://campus.barracuda.com/product/cloudgenfirewall/doc/79462985/how-to-create-wildcard-network-objects/
Watchguard implementation:
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/networksetup/wildcard_ip_addresses_about.html
The text was updated successfully, but these errors were encountered: