For a UDP server without local-host, server.conf.j2 renders multihome. With openvpn 2.6 this sent each reply back out the interface the request arrived on. With openvpn 2.7, plain multihome keeps the source address of the arrival interface but lets the routing table pick the egress interface; the old behaviour needs multihome same-interface. On a dual-WAN router whose default route leaves by WAN1, a client connecting to the WAN2 address gets replies out WAN1 with WAN2's source address. Upstream anti-spoofing or reverse-path filtering drops them and the client never connects.

Steps:

1. OpenVPN server, mode server, protocol udp, no local-host, two uplinks eth1 and eth2.
2. Route to the client's address points out eth2; the client connects to the server's eth1 address.
3. Capture UDP 1194 on eth1 and eth2 on the server.

Server packets per interface (openvpn 2.7.8):

L040-COUNTS host=lat278-peer route-dev=eth2 server-sent eth1=0 eth2=13 ; received eth1=17 eth2=0

With strict source validation on the client's interface, the client does not connect:

L040-CLIENT-CONNECTED: no

With openvpn 2.6.14 the same setup replies on eth1 only and the client connects.

Workaround: set interfaces openvpn vtunX openvpn-option "--multihome same-interface". Replies then leave by eth1 and the strict client connects.

Impact: dual-WAN and policy-routed OpenVPN servers that work on 1.5.x can stop accepting clients on the secondary uplink once openvpn 2.7 ships.

Suggested fix: render multihome same-interface instead of multihome in server.conf.j2.