Ability to disable gateway creation for OpenVPN interfaces

[marcquark]

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/core/blob/master/CONTRIBUTING.md
[x] I have searched the existing issues and I'm convinced that mine is new.

Is your feature request related to a problem? Please describe.
This feature request was originally triggered when i hit this issue: #4395
I believe that having to untick the "disable reply-to" box for every rule created on an assigned OpenVPN interface is unintuitive and potentially also very error prone. Think you'd like to mimic an existing LAN rule on your VPN. You clone the rule, change the interface to the assigned OpenVPN interface instead of LAN, maybe change the source network (if it is even defined). You would expect the rule to work. In an out-of-the-box setup, it currently doesn't.

So then i went and read about the automatic reply-to rules to better understand their purpose. In a multi-wan scenario i think it's good that they are there - they probably saved many admins with multi-wan setups (including myself) hours of troubleshooting, perhaps unkowingly so. I also understand that there are OpenVPN scenarios, where a reply-to rule is also nice to have (think NATing something from a remote site's WAN to a local server via a P2P VPN - it'll just work).
However in roadwarrior server setups, a reply-to rule is also automatically generated for rules configured on an assigned interface. As already mentioned by somebody else in the thread i linked above, there are valid reasons to assign OpenVPN interfaces and add rules to each interface, rather than just using whole OpenVPN group. Especially when there are more than just a handful of rules, one could argue that it's even necessary. Robustness against human error (such as accidentally declaring a wrong source network, or even "*" on a rule) is probably the best argument here.

I'm comparing pfSense and OPNsense a lot to understand the differences in detail. I have a pfsense setup that has been running and gone through upgrades since early 2018. I can't really pinpoint when, but at some point pfsense must have started creating gateways for OpenVPN server daemons. All i can say is that when i initially set that box up, the gateways weren't there. With the current version, newly created daemons and ones where i change and save the config will create a gateway, always assuming that an interface is assigned, of course. With the gateways also came the automatic reply-to rules. Except that they don't seem to cause any trouble on pfsense.
This "new" behaviour is what OPNsense does, too. I'm not a long-time user so can't tell if it was always like that. Anyway, combining the gateway creation with the automatic reply-to feature, we end up with firewall rules that match and pass traffic from connected OpenVPN clients, but no reply traffic actually ever reaches the client. This is described in the issue above.

I don't know why it works on pfsense, but i don't think it's too relevant anyway. Because after thinking a little more about this, why would a gateway be needed for an OpenVPN roadwarrior server anyway? Bear in mind that the gateway IP address is the 1st address in the subnet anyway, AKA OPNsense's own address, so i currently fail to see a common use case for it.

Describe the solution you'd like
Hence i would like to request the ability to block gateway creation for OpenVPN servers (maybe also clients?) completely. For Roadwarrior serves, "disabled" should even be the default. If somebody requires a gateway in an exotic scenario, they should know that they do, and can simply enable it. A migration/upgrade should also enable it, for backward compatibility.
This feature is also present in pfSense since v2.4.3. I believe that it would be an elegant way to tackle the reply-to issue. It also solves a couple of UI/UX problems (such as mentioned in the pfsense redmine ticket, having a ton of bogus gateways in the list that do nothing but distract an admin's view).

Describe alternatives you've considered

• Disable automatic reply-to generation globally: tends to introduce issues in multi-wan setups. In my test lab i saw immediately why the automatic reply-to is a good idea: PINGs came in through one WAN inteface but the reply traffic left through the other - not good. Also i could not make any use of this hint because unlike it suggests, i couldn't find an option to actually specify reply-to for a specific rule.
• Try getting rid of the Gateway to avoid the automatic reply-to: As suggested in this thread. It's not possible to set an IP configuration on a tunnel interface and hence i can't
• Do not generate reply-to rules for Roadwarrior OpenVPN Server interfaces: Seems like a complicated piece of logic to implement. Would also solve the problem though. Given that with reply-to, the rules effectively render the VPN connection unusable anyway, it's probably my second-favourite approach

Additional context
It could also be that even with reply-to enabled, the firewall rules should work. I saw a remark somewhere that pfsense uses a custom patch for that though, so i don't know if that's something OPNsense would like to do. Everything works on pfsense at least as far as i can observe it. When i find time i'm also going to spin up OPNsense 20.1 (which seems still based on HBSD 11). It could be that it's a bug that was introduced either with HBSD 12 or with a newer vesion of OpenVPN. If that's the case, i'll open a bug report for that.
Damn, the more i think about it, it probably should work. I know it contradicts what i wrote above, but: One could come up with a setup where branch offices connect to one road-warrior server in an HQ location, and then they NAT certain traffic towards the HQ. Not saying i'd consider this a particularly clean way of designing a network, but it could be done. And then the reply-to rule would become necessary and would have to work, which it currently doesn't.

One last note: i feel like it's not that difficult to implement this feature. I'd be willing to work on it and submit a PR, but i'm currently a bit uncertain as to how i could set up a testing environment with as little effort as possible. Do i just install OPNsense into a VM, pull a couple of magic PKGs so i can build locally and then clone the core repo? What's a for-dummies way to get to a state where i can make a change, build and test it, and then create a PR from it? I couldn't really find an answer to that question in the docs yet, but maybe i'm blind

[mimugmail]

You actually tell your real use case?
It's neither really described in other issue, nor here.

I mean, I set up countless Firewall in Business for so different needs, I never need to assign an interface.

So what is especially yours, not the other ones

[marcquark]

A bit of context: Multiple client networks, each with a different set of permissions (= firewall rules). For each client network there's a corresponding road-warrior VPN. Two actually for dualstack, until a last fix for multihome makes it into a release. Also a P2P OpenVPN connection is in the mix, where due to a very specific business requirement i need to use one of the WAN connections of Site A for internet access from servers on Site B via this tunnel.

Use cases for assigned interfaces instead of the OpenVPN group:

• An additional safety net, e.g. when i accidentally configure a rule with the wrong source subnet or even "*" it will not lead to unintended access
• The assigned interfaces can be grouped together with their corresponding VLAN interfaces so firewall rules can be implemented in a DRY (Don't-Repeat-Yourself) manner

I hope that explains it enough. I think if the ability to use assigned interfaces is there, it should work without too much assle out-of-the-box, shouldn't it? I'm aware of all the possible workarounds, but they are just workarounds. Getting rid of unnecessary gateways solves the issue with automatic reply-to rules that shouldn't be there, and also unclutters the gateway overview. Win-Win?

[AdSchellevis]

Just a quick recap to see if I understand your problem, when you disable reply-to you are not able to set reply-to for a specific rule to a specific gateway (which I think is indeed the case).

So the feature request is to be able to not only disable reply-to but also to set the correct gateway on a rule, which would in this case mean the "disable" option would either be a fixed gateway, none or default.

[marcquark]

@AdSchellevis first paragraph: Yes, correct. Although the docs suggest it, it seems impossible to re-enable reply-to on a per-rule basis when it's disabled globally.

Second paragraph: Not quite sure i understand what you mean, but it's not my FR. My FR is the ability to disable the automatic Gateway creation for OpenVPN interfaces (putting that into the OpenVPN settings rather than the interface settings seems appropriate to me but could of course be discussed)

Again, i think it's good that we have automatic reply-to for WAN interfaces, and i'd rather leave it enabled. But then my only option is to disable reply-to for every rule on every assigend OpenVPN interface (except P2P, it works there).
In the forum i saw a couple of comments that suggest setting the upstream gateway to "automatic" or "none" on the interface, but that's not possible with tunnel interfaces. The two logical options to solve this are

• Introduce a special interface setting only for tunnel interfaces to disable generation of automatic reply-to (i.e. increase rule generation complexity, sounds like something that should be avoided to me)
• Just get rid of the unneeded auto-generated gateway for the assigned OpenVPN interfaces - don't need to touch any firewall rule logic

The latter solves the reply-to problem and has a nice side-effect. Hence the decision to formulate the FR as i have - config option for OpenVPN to disable automatic gateway creation.

[AdSchellevis]

as much as I would like to remove the automatic gateways for OpenVPN clients, it would break peoples setups. it might be easier / more consistent to disable reply-to and make sure you can actually set the property on individual rules. you can always disable gateways on individual bases already, which should more or less have the same affect.

[marcquark]

That's why i would explicitly make it a per-VPN setting :) A sane default in my personal opinion would be don't create gateway for Roadwarrior servers, but do create gateway for everything else. That's certainly up to individual taste though, and for the sake of introducing a non-breaking change, it could also be made the default to always create gateways, leave it to the admin to tick/untick a box.

Thanks for pointing out that the auto-created gateways can be disabled. That's a very fine solution i hadn't thought of yet. Makes at least my life a lot easier!

My point still stands, a feature to control gateway creation in the OpenVPN config would be a useful addition and unclutter the gateway overview. Would you be fine if i created a PR that doesn't touch existing setups but adds this capability?
If yes, i'd still be glad to hear recommendations for setting up a testing environment. From the docs it reads like for every little change i make, i'll have to rebuild and reinstall OPNsense to a test VM - but there surely is a simpler approach to develop against master?

[AdSchellevis]

you can make upgrade on core (when installed on the same box) https://github.com/opnsense/core#make-upgrade

I don't mind discussing the feature within a PR, but I'm not really sure it would really easy maintenance given that you can already disable unwanted automatic gateways (when adding a toggle to the openvpn client, the number of actions would be roughly the same, which doesn't really help). A PR for the docs explaining how the current options can help in your type of setups might be more practical to be honest.

[kulikov-a]

Hello everybody!
can I get in? Regarding the reply-to directive. Both for VPN cases and not.
There are also such cases:
https://forum.opnsense.org/index.php?topic=20175.0
It seems to me that the people do not even press the "Advanced Options Show / Hide" button. And even less interested in the purpose of this directive.
Perhaps some of the problems could be solved by: a) moving this option from the hidden area b) giving it a more obvious name (for example, "force symmetric routing") c) adding the display of this directive to the rules table?

[marcquark]

@AdSchellevis you've convinced me. I've submitted a PR to the docs

@kulikov-a i think that's a slightly different case. Maybe it's best if u create a seperate issue for your suggestions? I do agree btw that a visual indication in the rules overview whether or not reply-to is created could help draw attention to this very intrinsic detail.