"Quote from: wewall on March 31, 2024, 05:31:49 PMQuote from: teo88 on February 02, 2024, 09:35:53 AMOld Configuration:
Interface: WAN
New Configuration:
Bind Address:
I also don't understand what the design decision is behind not being able to select an interface for binding.
I would be particularly interested what are the recommended settings if I want to bind an OpenVPN instance (client) to only one specific WAN interface with dynamic IP?
In the case of a dynamic WAN IP what bind address should be entered at all?
2 years late with this but posting in case anyone else is looking for a solution. I had exactly the same problem - my notes and solution below (dodgy hack using PBR firewall rule and NAT). Trying to move everything over last minute before the legacy VPN config is deprecated....
Old 'legacy' setup had an option to select an interface for a client VPN. So you can have an OpenVPN client configured on OPNsense, force it via a specific WAN, and that traffic will stay on that WAN.
Probably a very specific situation to people using multi-WAN who want VPN client traffic to stay on the secondary WAN, so their primary WAN is dedicated to non-VPN traffic.
That's no longer straightforward with instances, however it is possible with a dodgy workaround :)
1. Configure the client as normal, verify it connects. Assign the OpenVPN interface itself (the device), configure the gateway and whatever else you would've done anyway.
2. Add a floating rule:
Firewall → Rules → Floating → Add
Direction: out
Interface: WAN1, WAN2 (you want this on BOTH interfaces, so it matches VPN traffic going out via either)
Quick: checked (IMPORTANT, otherwise default rules are hit first and this wont apply)
Action: Pass
Proto: UDP
Source: This Firewall
Destination: <vpn server dest IP> IP address of the destination server (remote) address configured in the VPN client.
You can use an alias with multiple IP if needed, if you do, use this in the NAT rule as well.
Port: 1194
Gateway: WAN2_Gateway (whatever this is named, mine is WAN2_DHCP)
Description: PBR: Re-route OpenVPN to WAN2
3. Now if you go to Firewall > Log Files > Live View, filter on "dstport" 1194.
In another tab, go to VPN > OpenVPN > Instances. Make sure the client is enabled.
Go to VPN > OpenVPN > Connection Status, restart the client to get it to connect.
Refresh and it's probably stuck waiting.
Back in the Live View tab, you'll see it hit the rule, with the description, HOWEVER the IP will likely be the WAN1 IP. That will never work as it's now routing traffic over WAN2, with the WAN1 IP applied as source via NAT.
4. FIX: NAT rule
Go to Firewall > NAT > outbound
New rule:
Interface: WAN1
TCP/UDP Version: IPv4
Source: This Firewall
Source port: *
Destination:
Single host or Network
Address: <vpn server dest IP> (same as in the Floating firewall rule)
Destination port: 1194
Translation / target:
Address: WAN2 address
Port: static-port enabled (important for OpenVPN/UDP)
Description: PBR force OpenVPN to WAN2 (NAT)
This rule will match the traffic when it tries to exit WAN1, apply the NAT as IP of WAN2, then the PBR rule will hit and redirect to exit via WAN2 - everything matches.
Now re-start the VPN client, check the live log again, and with any luck you should now see it using the WAN2 IP, and hitting the PBR ACL rule :)
It should connect!
If you then replace the <vpn server dest IP> with an alias, then the only thing to change if you update the VPN remote server is the alias, and all rules are sorted.
Not ideal that something so basic requires this complexity but good old policy based routing and NAT allow for this dodgy workaround! If anyone knows another way around this, would be good to know. This removes the need the configure a static WAN IP binding in the VPN client which is rubbish if yours is dynamic (as are most non-business WAN IP), and that also doesn't seem to work properly for client instances anyway.
