Bug #11231
closedOpenVPN tunnel exiting wrong interface
0%
Description
In a multi-WAN environment with multiple OpenVPN tunnels, it seems the tunnels can egress the incorrect WAN interface (not the interface they are manually assigned to). I tested by building two OpenVPN tunnels between FW-A and FW-B.
From client (LHS) to server (RHS)
FW-B WAN1 --> WAN1 FW-A
FW-B WAN2 --> WAN1 FW-A (deliberately WAN1 again on server)
On both firewalls, WAN1 is the system default gateway with a failover to a WAN2.
Without any firewall filter rules both tunnels establish. Can ping, route etc.
I know that for the ISPs used for the WANs there is no uRPF enabled at their end (I used to work there).
Now I decide to strengthen my filter rules to stop incorrect behaviour with my own uRPF setup... with the following two floating tab "Block" rules:
1) Interface: WAN1. Source address: WAN2. Direction "out"
2) Interface: WAN2. Source address: WAN1. Direction "out"
This is clearly to stop source address leakage of WAN1 source IP leaving WAN2, and vice versa.
When enabled, this kills the "FW-B WAN2 --> WAN1 FW-A" tunnel. It seems that that this tunnel wants to source the FW-B WAN2 address (which is good), but route it out the FW-B WAN1 interface as per the default gateway (which is not good, as I told it not to).
To be absolutely clear for this "FW-B WAN2 --> WAN1 FW-A " tunnel I have set "WAN2" as the Interface on the client in the GUI where it says "The interface used by the firewall to originate this OpenVPN client connection" and definitely not "Any", "WAN1" or any gateway group. So correct IP, wrong interface. I double-checked NAT rules and port forwarding, and nothing should be interfering - there's no port forwards, and only the LAN subnet is natted out the WAN, with seperate source NAT rules for WAN1 and WAN2. Should all be fine.
I cannot explain this behaviour other than as a bug.
Seen in production running 2.4.5p1. Replicated in the lab with both 2.4.5p1 and 2.5.0 latest snapshots (7th Jan 2021). I am at your disposal and happy to help. Thank you kindly.