Questions to Migrate OpenVPN Servers legacy to Instances New

[teo88]

Hello,

i have updated now to 24.1_1 without any problems so far. Now i want to migrate my OpenVPN
Server configuration from legacy to the new Instances. But some Settings in the New Configuration are
not clear yet, and i hope someone can point me in the right direction.

Old Configuration:
Interface: WAN

New Configuration:
Bind Address:

As i have a static WAN Address, do i need to add as Bind Address the Static WAN Address (similiar in the Legacy Configuration choosing the WAN Address) ?


Old Configuration:
IPv4 Tunnel Network:

New Configuration:
Local Network:

Is in the New Configuration the Local Network the IPv4 Tunnel Network the similar setting?


Old Configuration:
Redirect Gateway = marked

New Configuration:
local
autolocal
default
bypass dhcp
bypass dns
block local
ipv6 (default)
not ipv4 (default)

What is the correct setting similar to Redirect Gateway marked in the legacy config to route all traffic from the client through the VPN Server?


Old Configuration:
Advanced Configuration:

allow-compression no

New Configuration:
options

Do i understand this correct, that now the allow-compression no is the default parameter, and thats why in the New Configuration under options not included / selectable anymore?


Thanks a Lot!

[teo88]

Really, no one?

[bandit8623]

im in kinda same boat.
i deleted my old server openvpn.  and in the menus it still say legacy...  why does it show legacy in menus.  how do i get it to let me setup non legacy?  sorry to hijack your thread,  but once i get that figured out ill play with new settings to help you as well.

[teo88]

Hello bandit8623,

the "new" setting you find under OpenVPN - Instances - Add new - Role select Server

br

[cs1]

A good point to start is the configuration guide for the new instances model: https://docs.opnsense.org/manual/vpnet.html#new-vpn-openvpn-instances

• Bind address: if you don't have to bind to a certain interface you can leave this unset and the openvpn daemon will bind to all interfaces.
• Local network: this is the part where you define which routes to push to the client if you want to have a split tunnel. Leave this unset if you plan to have a full tunnel (i.e. send all client traffic through the tunnel).
• Redirect gateway: this is where you define which gateways to redirect. For a full tunnel for IPv4 you select "default", for IPv6 you select "ipv6 (default)", for dual-stack you select both.

AFAIK compression has been deprecated in recent openvpn versions hence there's no option to enable it. Regarding selectable options: if you want to allow multiple simultaneous logins with the same cn, make sure to check the "duplicate_cn" option in the options selector.

If you work without client certificates and just with username/password login, you might also want to enable "advanced mode" when configuring the server instance and enable "Username as CN" to have the username in the dashboard and logs.

[teo88]

Hello cs1,

thanks for the information. Adapted yet my settings, but the Bind address is still not 100% clear.

Within the OpenVPN Legacy Server and OpenVPN Legacy Client (OpenVPN out) Settings, under Interface i can select a specific Interface, localhost, or any. I had in both Legacy Configs the WAN Interface specified.

In the new Instance Configs like Server or Client, if i want to bind the interface to my WAN Interface (like in Legacy Setups) i can just add my Public IP address to the bind address Field, but not select anymore Interfaces?

Thx
br

[cs1]

Yes, that seems to be the case. You can't select an interface but only add an IP. As a workaround you can leave this empty and have it bind to all interfaces and set up firewall rules that only allow access via WAN. I'm not sure what the design decision is behind not being able to select an interface but I suspect it has something to do with dynamic IPs on interfaces (e. g. if there's no fixed WAN IP).

[teo88]

Yes, that seems to be the case. You can't select an interface but only add an IP. As a workaround you can leave this empty and have it bind to all interfaces and set up firewall rules that only allow access via WAN. I'm not sure what the design decision is behind not being able to select an interface but I suspect it has something to do with dynamic IPs on interfaces (e. g. if there's no fixed WAN IP).

Thx cs1 for the update on this

It would be really nice, if @Franco could give us a hint whats behind that change?

[wewall]

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?

[AlexS]

Note 1:
Leave empty to bind to all addresses assigned to this machine or use a loopback address combined with a port forward when the external address is not static. (from here: https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html )

I'm trying to set up OpenVPN with instances too (posted here: https://forum.opnsense.org/index.php?topic=39912.0 but we can continue here)
didn't found more information about this case and faced some troubles, but i think it will be a better solution when it is done.

[jbhorner]

I just found this thread via a search, after seeing the "legacy" notation in OpenVPN on OPNsense. The only thing I can say is that the current documentation is so awful, and the UI in OPNsense so bad, it leaves users in a situation where they will at some point be forced to spend a significant amount of time to "migrate" to the new instances. Seriously, I can't express how bad the documentation is. As an example, there is a network diagram with IP addresses (ALL private, I'll add) and a table later in the document that displays IP addresses that are not anywhere in the network diagram. (Or earlier descriptions.) It's not only amateur, it's sloppy and wrong.

I've yet to find any meaningful reason (defined as a justification as to why anyone would devote time to this) why the change to "instances" is on the roadmap at all. Though it should be obvious, I will bet that it is a very, very small set of individuals that are going to want to spend a significant amount of time trying to understand the "new way." The "old way" worked. But at some time it will not. For anyone who uses this functionality frequently, the looming death knell is far from comforting.

What a disaster.

[keeka]

I am revisiting opnsense and grappling with the new openvpn options to migrate a server to an instance. What I have noticed is, if I leave bind interfaces blank, it does not seem to bind to the desired interface to which traffic is being forwarded:
I port forward udp/1194 from WAN to an opt interface (DMZ), and the only way I can get a client connection is if I explicitly set the bind field to the DMZ IP. I haven't checked yet to see what interfaces openvpn is actually listening on when I leave the bind interface field empty. But so far, seems it is not listening on at least one of the OPT interfaces.
Also I prefer not to hard code IP addresses where possible, but this seems to have become increasingly necessary.

[bradforr]

I'm having a major issue using the new "Interfaces" system... It seems that there is a shiny one pager that is supposed to do everything but what is now lacking is the wonderful little Wizard that guided you through creating all the SSL certs and things.

I also cannot seem to get it to work... I then discovered a whole lot of firewall entries that were there under previous versions (assuming created by the wizard) that just don't appear to be there under a fresh install of the new OPNSense...

Serious downgrade.

At least I can use Wireguard because otherwise I'd be in a tough spot... I cannot get this to work in any stable way because documentation and ease of setup have just gone down the toilet.

[franco]

> Serious downgrade.

To add irony: OpenVPN and WireGuard are now quite similar in configuration workflow and UX.

[lostpacket]

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

I'm not skilled enough to give a valuable opinion about which one is best. However since migrating I'm having a strange issue, that I believe could be because of the "Bind address" mentioned earlier in this thread.

I'm playing with multiple OpenVPN and Wiregard clients; most of them are in use at random times during the day and I strongly suspect some connections are not keeped-alive continuously.

From time to time, one of the clients will randomly (and silently) redirect all traffic through another one; which mostly shows up on the "Traffic" bandwidth graphs, where one interface clearly correlates the other in both directions. The problem is resolved by restarting one of the two clients involved.

I do believe this can be caused by the "Bind addresses" being left empty - most of the time, connection or keep-alive is done through WAN ; but not always.

I'm lucky enough to have a fixed IP address; I've set up the field accordingly, restarted all OpenVPN clients - works fine so far. As I stated before it is a random issue (sometimes days before it happens), I'll keep you all posted with the results  :)

EDIT. Didn't work :( same behavior all over again, this time between a Wiregard client and an OpenVPN one. Looks like OpnSense is using the OpenVPN tunel to establish the Wiregard connection; but there's not "Bind address" option in the later, so I guess it's not the same issue after all.

EDIT 2. Finally found it :) the issue was indeed caused by migrating from the legacy client configuration to the new one... My OpenVPN provider is pulling routes when establishing a connection, leading all further traffic - including other VPN connections, such as Wireguard - to use it to access the larger network :P This behavior was previously corrected by the "Don't pull routes" option, but in the new interface one has to define the "route-nopull" option.