OpenVPN firewall rules, when using an assigned interface

[Gauss23]

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.

Describe the bug
OpenVPN server on OPNsense (20.7.2 and 20.7.3) with assigned interface: when creating rules in the firewall section of this interface, packets are not flowing through the OPNsense like they should. Rules are evaluated and the packets are visible in the firewall log with "pass" but they never reach their destination.
Creating the same rule in the OpenVPN group will let the packets go through.

To Reproduce

1. Create an OpenVPN server
2. Assign an interface to that OpenVPN server (without IP definition)
3. Add firewall rules for that interface
4. connect a client to the OpenVPN server
5. see how no traffic is flowing: in live-view you´ll see the packets marked as pass, no blocks, but no traffic is reaching its destination
6. move the firewall rules from step3 to the OpenVPN interface
7. see how traffic is flowing

Expected behavior
Traffic should move without creating rules for the OpenVPN group interface if a specific interface is used.

Additional context
Forum threads:
German: https://forum.opnsense.org/index.php?topic=9150
English: https://forum.opnsense.org/index.php?topic=19424

Environment
1st box:
OPNsense 20.7.3 (amd64, OpenSSL).
AMD EPYC 7702P 64-Core Processor
Network vtnet KVM guest

2nd box:
OPNsense 20.7.2 (amd64, OpenSSL).
Intel(R) Core(TM) i3-9100F
Network vmx VMWare guest

[Gauss23]

Some screenshots:

Interface assignment:

Simple firewall rule to allow all incoming traffic from that interface:

As you can see, rules are evaluated and traffic is passing:

Rule being processed on the right interface and marked as passed, but traffic is not going through:

Traffic only flows, it this rule is added:

After adding, you see the new rule is evaluated:

And here is the live view of the new OpenVPN group rule:

[kulikov-a]

@Gauss23
can i ask why you need to assign interface for ovpns* if opnsense already create OpenVPN group for you.
and where should i propose an answer. here or forum?

[Gauss23]

@kulikov-a
Answering here is ok.

Because it gives an extra layer of security (missing or omitting the right source network might lead to a lot more unwanted traffic) and helps to keep the rules in the OpenVPN group clean if one interface has a lot of rules. I know about "Categories" but why not seperate it by interfaces if the possibility is there.

[kulikov-a]

IMHO when you assign intreface to ovpns* and restarts OpenVPN opnsense (filter.inc ) writes your OVPN-RW-RULE like:
"pass in log quick on ovpns3 reply-to ( ovpn3 10.4.3.129 ) inet from {any} to {any} keep state "
try to set "disable reply-to" option in your OVPN-RW-RULE. should help imho

Because it gives an extra layer of security (missing or omitting the right source network might lead to a lot more unwanted traffic)

sorry. imho it only adds complexity to reading rules. networks can be restricted through network aliases and rules

[Gauss23]

Wow, you solved this issue. "disable reply-to" was the correct hint. It now works. Perfect. Thank you!

[marcquark]

was this behaviour introduced recently with a newer kernels

i'm comparing the ruleset against pfsense, where it works without ticking "disable reply-to". the generated rules look the same. so should this issue be considered a bug?

it's unintuitive to have to tick that box for every rule on an assigned openvpn interface. reply-to is not added when moving the rule to the openvpn group.
if it used to work on earlier versions, then this can definitely catch people off guard, imagine all your openvpn traffic just stops after an upgrade...

[marcquark]

also to add a couple more observations because i spent an afternoon scratching my had until i found this issue.

inbound traffic seems to pass through OPNsense successfully, just the reply packets seem to sort of "die" on the last mile (i.e. when they should leave the openvpn interface towards the client).

• pinging client--(openvpn)-->OPNsense, i saw the echo requests but no echo replies
• pinging client--(openvpn)-->OPNsense--(ipsec)-->OPNsense2, i saw the echo requests, they were forwarded out the ipsec interface correctly and replies came back in through the ipsec interface, but then failed to leave the openvpn interface towards the client

[AdSchellevis]

@marcquark I don't expect so, no (haven't seen evidence of a change either). The reply-to for multiwan scenario's can be misleading sometimes, which you can easily disable in full from the advanced settings page. If you want more fine grained control, best disable these types of automatic rules (which we inherited from pfSense), since it's impossible they will fit every ones use-case.

[AdSchellevis]

p.s. we usually don't respond to closed tickets, if there's evidence of a change or misbehaviour which wasn't handled in the original ticket, best open a new ticket containing all the details and steps to reproduce.

[marcquark]

@Gauss23 as the discussion in my other issue revealed, you can disable the automatically generated gateway(s) of your assigend OpenVPN interface, which is probably what you want in your situation. Then you don't need to disable reply-to on a per-rule basis.