FreeBSD ovpn(4) DCO module doesn't support "multihome" option correctly

[mzary]

From my observation, when ovpn(4) DCO driver is used, the outgoing interface for encrypted traffic is chosen on the basis of the FIB lookup instead of preserving the IP address of the VPN connection socket and sending the traffic from the same interface and address it was received on. Such a flaw breaks the "multihome" server since encrypted incoming and outgoing packets don't match the destination/source IP and thus can't pass firewall processing. The tun(4) driver supports this mode still fine in the recent FreeBSD stable/14.
I have no possibility of testing it on Linux with DCO on a "multihome" server.

[mzary]

I have submitted a PR[1] on FreeBSD Bugzilla, but it looks like a more general flaw

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273664

[cron2]

Mmmh. The userland code does indeed copy the interface ID as well as the dest/source IP around, so for packets created by userland, on FreeBSD(!), it might respect source/dest interface (Linux does not care, as far as I remember). Not sure how routing would work, then - do you have two default routes, one per outgoing interface?

Towards the kernel, we only pass the IPv4/IPv6 address, so interface ID is lost. Which might be because "Linux does not care anyway".

On FreeBSD, to get the desired effect, using pf(4) with reply-to might work, for the moment.

[mzary]

There are two WAN interfaces, the interfaces are in different subnest. We have deployed redundancy with the PF rule many years ago:
pass in quick on $backup_if reply-to ($backup_if $backup_gw) proto udp to ($backup_if) port $ovpnport
and it still works fine for tun(4), while with ovpn(4) DCO interface, the source adress for replying packets instaead of $backup_if is the addres of the main WAN inteface holding default route. So it definitelly breaks "multihome". If Linux cares to use right IP for replyinig packtes, then only FreeBSD implementation is broken.