For a longer period of time, we have security/openvpn deployed with a "multihome" runtime option for failover and redundancy. With one[1] simple PF rule redundancy is achieved. The tun(4) driver supports this mode still fine in stable/14, whilst ovpn(4) can also send and receive unencrypted packets on the LAN side, the encrypted ones don't show up on the right interface. They appear on the main interface instead of $backup_if and thus the rule[1] is silently ignored. [1] pass in quick on $backup_if reply-to ($backup_if $backup_gw) proto udp to ($backup_if) port $ovpnport
There is also a positive side of this bug: "multihome" is ignored but harmless to DCO on FreeBSD, users of other OSes are not that lucky[1]. [1]https://github.com/OpenVPN/openvpn/issues/390
In other words, the outgoing interface for encrypted traffic is chosen on the basis of the FIB lookup instead of preserving the IP address for the VPN connection and sending the traffic from the same interface it was received on.
I have submitted similar the report to OvpeVPN DCO: https://github.com/OpenVPN/ovpn-dco/issues/47
The issue was transferred to https://github.com/OpenVPN/openvpn/issues/409
After investigating it a bit further I was told by OpenVPN devs that "multihome will ensure that the UDP source IP is the one that the other end sent its packets to". It's not yet supported by FreeBSD DCO implementation which only performs simple route lookup and sends the packets with the source IP of the outgoing interface. It's a minor bug of our DCO module, perhaps it will be fixed in the future, but apparently, Linux implementation does support "multihome" just fine.