OPNsense Forum
Archive => 20.7 Legacy Series => Topic started by: kyferez on May 21, 2020, 06:59:48 pm
-
Multiple Alias based and firewall rule based feature requests:
1. Built-in Aliases for InternetIPv4 addresses and InternetIPv6 addresses. This would basically make it easier to specify all Internet IP ranges in a rule which would automatically exclude all other address types such as RFC1918, multicast, etc.
2. Alias Groups. This is an Alias which contains multiple other Alias names. Useful when you want to create multiple hosts like GoogleDNS1 GoogleDNS2 Level3DNS1 Level3DNS2, then create a group PublicDNS which would contain those 4 alias' names. This also applies to services, such as a "HTTP" group for ports 80 and 8080, and "HTTPS" group for ports 443 and 4443, so a Service Group Alias would contain both "HTTP" and "HTTPS" as entries in the Alias Service Group.
3. DNS Alias' and DNS Groups. If a DNS name can be an alias that the firewall resolves, this would be very helpful for making rules to internet applications, and would need to also account for the fact that some FQDNs resolve to multiple IPs. Then a DNS Group would be an Alias with multiple FQDNs.
4. Rules to allow multiple Sources, Destinations, and Services. This makes rules much easier to manage. If I can create one rule like below examples it's much more concise, less error prone, and easier to manage. I'd otherwise have to create multiple Alias' and multiple rules or both which quickly becomes confusing for an environment with many VLANs and many restrictions.
Example:
Source: Host1 or Host2 or AliasGroup1
DST: AliasGroup2 or AliasGroup3
Services: WebBrowsing or SSH
Another example:
Source: AliasGroup
DST: InternetIPv6 or InternetIPv4
Services: WebBrowsing
5. Ability to reverse priority of Floating rules and interface specific rules. I like to use the Floating rules as General Purpose Allow rules which apply to most of my network, and the specific interface rules for more specific denials or allows which I want to override the floating rules. This helps keep the Floating rules limited to smaller numbers of rules which makes management easier and less error prone, as the alternative is to create Floating deny rules above the general purpose allow which gets messy fast. Thus if I could have the Interface rules have priority over the Floating rules, this would work much better for this sort of design.
Thanks!
-
Do you use a current OPNsense version?
Most of your requests already work since several releases out of the box.
1. Instead of having aliases containing 2^32 addresses, excluding RFC1918, try using the negate option for source or destination.
E.g. allow src not RFC1918
2. alias groups. It's no problem to define aliases that contain other aliases. I have aliases for local DNS and provider DNS and an alias that contains both aliases. Works perfect.
3. I always use DNS names in aliases, since our addresses resolve to ip4 and ip6 or several DNS load balanced servers resolve to multiple ips. Really no new feature. Of course you can also nest aliases that use DNS names.
4. That's really a request that would be new
5. Read about Freebsd pf quick and lazy rules. I think you can make floating rules lazy and so create a last match
-
Yes, I'm on the latest 20.1.7.
1. This doesn't really work as I would want Not RFC1918 and Not Multicast and Not Loopback and NOT SpecialPurpose and NOT Broadcast and NOT etc. I guess since #2 actually exists I can manually create this, but it would certainly be better if it was just built-in!
2. Really? That's great news! The drop-down didn't mention using Alias' as an option, and since the drop-down was specific, I didn't expect anything but what was specified as the option in the drop-down to work, but I see in description it says they can be nested which I don't remember from before. By the way, which drop-down Type option would be correct for nesting? Should it match the Parent Alias type?
3. Also great news! That said, which Drop-Down would I use for this? Also the "Type" could seriously use some help in the "Help" area for this and #2! What is External? What is URL and URL Table and Network Group?
4. Of all these items, this is a "most wanted"
5. Thanks, I think I can make that work.
Thanks!
-
To 1.:
Just create some aliases of type network
- RFC1918
- Loopback
- Multicast
- ...
Create an alias to group all above together and use it with not option
That what you want, will never work, since broadcast addresses change depending on network mask, e.g.
192.168.0.0/24 --> 192.168.0.255
192.168.0.0/25 --> 192.168.0.127
192.168.0.0/26 --> 192.168.0.63
Beside of this: what is internet? For you as private user with one isp assigned public IP, everything not RFC1918 and multi/broadcast is internet. For companies that own public network blocks, things look different.
To 2.:
Of course you can only nest aliases of same type. You can group aliases of type network, but cannot add ones of type port. Logic.
-
To 1.:
Beside of this: what is internet? For you as private user with one isp assigned public IP, everything not RFC1918 and multi/broadcast is internet. For companies that own public network blocks, things look different.
Basically all internet route-able addresses. Just because a company owns IP blocks and uses them as internal IPs doesn't mean it's not Internet Routeable. IMO it's foolish and wasteful, but that's neither here nor there. They are still Internet routeable and a company like that would have to be aware that an Internet Alias would include those IPs. I don't think it's unreasonable to provide an InternetIPv4 and InternetIPv6 alias built-in. It's pretty ubiquitous and other companies provide it for ease of management.
To 2.:
Of course you can only nest aliases of same type. You can group aliases of type network, but cannot add ones of type port. Logic.
Not for us autistic types. We question basic logic because it is usually not clearly defined logic that takes into account all possible variables. For example: can a group be nested with a type of URL and a type of Network? It's reasonable to conclude they can, but it's not defined if it will work. Make sense?
What about #3 questions?
-
Basically all internet route-able addresses. Just because a company owns IP blocks and uses them as internal IPs doesn't mean it's not Internet Routeable.
I never said, that these addresses are not routeable, but such alias would not make sense for such companies. In opposite: it would lead to misconfigurations.
Let's create a rule "deny src internet4 to dmz" would block wan AND lan traffic, since company addresses are included in this generic alias.
-
Right, but that's a company using Public IPs for private IPs and would have to consider that. It honestly would affect an extremely small subset of customers. The advantages are more significant such that I think the argument is silly.
But bigger question: Why are my other questions getting ignored?
-
Right, but that's a company using Public IPs for private IPs and would have to consider that. It honestly would affect an extremely small subset of customers. The advantages are more significant such that I think the argument is silly
Before ip4 address became close, public ips where the common away to build networks. Most universities don't use any RFC1918 addresses till today, even printer, access points, etc. have public ips. NAT and RFC1918 addresses are more home user style and got popular due to lack of ip4 addresses. With ip6 there is no reason at all to use non-public addresses at all. So an internet6 alias would be pretty difficult. Then you can just use "any".
But bigger question: Why are my other questions getting ignored?
Maybe because the devs read on GitHub since there is the correct place to open feature requests ;-)
https://github.com/opnsense/core/issues/new?assignees=&labels=&template=feature_request.md&title=
-
Before ip4 address became close, public ips where the common away to build networks. Most universities don't use any RFC1918 addresses till today, even printer, access points, etc. have public ips. NAT and RFC1918 addresses are more home user style and got popular due to lack of ip4 addresses.
That was true, not any longer. These days almost all corporations, even many very large international coprorations use RFC1918 IPs for internal. Are there still some that use their public IP blocks wastefully? Yes. But they are in the extreme minority.
As for IPv6, it would still be best to exclude the link local and special purpose IP ranges from Public Internet IPs.
Did not know what they used for feature requests; the forums seemed likely though.
-
I see you are the pro. On our next network meeting I will forward your suggestion to abandon the existing B- and C-Class net blocks in favor for NAT-bottlenecks.
-
I see you are the pro. On our next network meeting I will forward your suggestion to abandon the existing B- and C-Class net blocks in favor for NAT-bottlenecks.
That's hysterical you make me laugh. I'm not saying abandon them. I'm saying using them as internal is no longer commonly done, and NAT is only a bottleneck if your design is poor. Give me a break. Plenty of companies have 10000+ users on a corporate network where NAT is not a problem. I manage devices where there's that many internal users and also easily that many users hitting NAT Inbound from external. Issues like port exhaustion only occurs in extreme cases, and there's easy methods to prevent that in enterprise gear.