Wildcard netmask support in aliases and firewall rules

[OleSta]

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

[AdSchellevis]

no promises, but at a first glance the trick shouldn't be very complicated to calculated networks from a mask.

[OleSta]

Sounds great. Let me know if I can help testing or something.
How fast should I expect it to be implemented if done?

[AdSchellevis]

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.

[OleSta]

ok,
Here is a link more that explain the wildcard system more complex.
https://networklessons.com/security/create-complex-wildcard-masks/

[AdSchellevis]

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.

[AdSchellevis]

It's a work in progress (needs ui/api code), but 05d3224 calculates the wildcard netmasks when provided in /usr/local/etc/filter_tables.conf.

For the record, support for wildcards will only be provided via aliases, pf doesn't support this format natively.

[marjohn56]

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.

[AdSchellevis]

@marjohn56 it should be valid input for the network alias type, you can easily try it out manually when changing an alias in /usr/local/etc/filter_tables.conf (e.g. 192.168.0.1/0.0.255.0) I think it only needs the validation extended, but haven't looked at the php code yet. If you want to give it a shot, go ahead, I'm not going to work on it today.

[marjohn56]

Interesting... Not sure what validation it needs... worked perfectly. We have a nice aliastables entry which looks spot on.

[AdSchellevis]

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.

[marjohn56]

Your obviously so good at this that things work without thinking about it. 😉

[OleSta]

I would be good if it was able to show the subnets calculated when validating the wildcard netmask

[AdSchellevis]

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)

[AdSchellevis]

@marjohn56 I really doubt that ;) if it smells like a bug, it usually is. The question is what 192.168.1.0/255.255.255.0 produced in table output before this patch. if it's an empty table, no problem, we can just make sure to fix the validation (which can't be right now), if it's not empty we risk people using undocumented "features"

[marjohn56]

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?

[AdSchellevis]

the ! is a valid pf keyword #4318 which should indeed exclude the specified range.

[marjohn56]

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.

[marjohn56]

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!

[AdSchellevis]

@marjohn56 if it smells like a bug, it usually is 611304a ;)

[OleSta]

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

[OleSta]

If I use 192.168.0.0/0.0.3.255 pfTables lists 192.168.0.0/22

[OleSta]

[AdSchellevis]

@OleSta wilcard calculation is rather complex, in case of the 192.168.0.0/0.0.252.0 I would expect it to return 64 addresses, since 255 equals 256 addresses, cisco's examples look quite similar to the output we produce on the same test cases https://www.ciscopress.com/articles/article.asp?p=3089353&seqNum=5

[OleSta]

Not sure how to use this.
I had hoped for this:
https://campus.barracuda.com/product/cloudgenfirewall/doc/79462985/how-to-create-wildcard-network-objects/

https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/networksetup/wildcard_ip_addresses_about.html

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
How do I get that done with the implemented system?

[AdSchellevis]

0.0.0.64/0.0.0.3 ? which translates to0.0.0.64/30, to me it looks like "wildcard" and "netmask" are swapped in some of the documents (https://en.wikipedia.org/wiki/Wildcard_mask)

[OleSta]

would 0.0.0.64/30 work with the firewall rules? Guess I have to test next week.

[OleSta]

using the 0.0.0.64/0.0.0.3 does not match any packets in the firewall rules I tested with.
Had to use 0.0.0.64/255.255.255.3

Did a test with 10.0.0.64/0.255.255.3
Loading pfTables work fine from Chrome (Remote Desktop Manager Free fails to load them).
Loaded 65536 entries :)

[OleSta]

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?

[AdSchellevis]

safety limit :

core/src/opnsense/scripts/filter/lib/alias.py

Lines 97 to 101 in 17dff05

	for idx, item in enumerate(net_wildcard_iterator(address.lstrip('!'))):
	if idx > 65535:
	# overflow
	syslog.syslog(syslog.LOG_ERR, 'alias table %s overflow' % self._name)
	break

[OleSta]

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:
unable to resolve 10.0.0.64/0.255.255.3 for alias test_wildcard

[OleSta]

If I add many wildcards to an alias I get: Invalid argument. [test_wildcard]

[OleSta]

Looks like its working with a few bugs and a limit of 65536.
I need to get used to the notation form as the other firewalls I have done use an almost reverse notation:
https://www.routerfreak.com/understanding-wild-card-masks/