Questions to Migrate OpenVPN Servers legacy to Instances New

[beneix]

I recently migrated from the "legacy" OpenVPN client configuration to the "instance" one.

I have an existing, working client setup under legacy that it would be nice to be able to migrate, but since the old one was set up with the help of the wizard and includes both the VPN setup, firewall rules and a dedicated interface, I am a bit daunted how to replicate the legacy client in the new Instances setup, without the wizard to guide me.

The documentation I found mentions two examples (site-to-site tunnel and road warrior) but neither fits my scenario. I just need to route traffic from a specific client on my LAN to a tunnel to my VPN provider.

Has anyone found improved documentation to guide them?

[dish]

As a long time user and having seen OPNsense grow; it certainly shows a level excellence and quality from the team(s) and everyone contributing; thank you - keep up the good work.

Time to time though its frustrating when things get simplified to a point its confusing/ less usable. The UI is keeping up with the times but removing configurability doesnt make it polished, i expect many rely on some of the lesser used functions...  As a backup we had the 'insecure' option in some places that have too many options to cover but it continues to gets phased out and this is one of them; imo an authentic 'advanced' feature for those that needed it. Its been asked too frequently over the years to keep it and it makes sense in certain places.

My earlier experience with instances was successful but finicky; anyway its looks better now and I tried to setup a client vpn and i am missing the following few things:

explicit-exit-notify - please add; my provider requires it to close session
bind address - option to select interface instead of specifying an address
fast-io - not sure if still relevant
key-direction - useful for vpn in some countries
data-ciphers / data-ciphers-fallback / tls-cipher - option to select
pull-filter

[bandit8623]

Hi all,

It looks like the options are much more robust now than when i looked last.  eventually ill be migrating over. 

Thanks

[stargazer]

Has anyone tried using a DNS name instead of an IP for the binding address?

According to the OpenVPN, the two options are host or IP. I looked around some on my router using legacy, and the config file in use had the local option (where the binding is set) to the address assigned by my providers DHCP server, so someone is doing some kind of magic.

The OpenVPN 2.4 manual does not allow assigning an interface, as far as I can tell.

[DanVsTheUniverse]

Old 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.