Switching from WireGuard to OpenVPN site-to-site due to perf issues

[philote]

After finally figuring out how to get WireGuard site-to-site setup nicely here, I saw multiple threads about performance issues & tested myself to find out... I have the same performance problems. Until it can be fixed, I'm trying to get the same config I had setup with WireGuard, done with OpenVPN instead & would appreciate any feedback as I've been having some trouble. I tried following this guide as well for some reference, but it's not working quite right & I'm not that familiar with the routing configs (& the guide itself isn't that clear).

What I'm trying to do is here:

Site #1:
AX88U Asus Merlin 388.1
LAN: 192.168.25.1
Client will use VPN to access: LAN only (change to both if needed, not needed for my case)
VPN Subnet/Netmask: 192.168.20.0 / 255.255.255.0
Advertise DNS to clients: Yes
Manage Client-Specific Options: Yes
Allow client <-> Client: Yes
Allowed clients: <commonname1> / 192.168.25.0 / 255.255.255.0 / Yes (Push)
Custom configuration:
push "route 192.168.25.0 255.255.255.0"
route 192.168.50.0 255.255.255.0
reneg-sec 432000

Site #2:
AX88U Asus Merlin 388.1
LAN: 192.168.50.1
VPN Client: 10.6.0.2/32
OpenVPN Client Create NAT on Tunnel: No
OpenVPN Client Inbound Firewall: Allow
Accept DNS configuration: Relaxed
Redirect Internet traffic through tunnel: No

Some assumptions & a question:

• Since the server side is pushing Site #1's LAN subnet to the OpenVPN client, the client side doesn't need any routing set up in its Custom configuration setting.
• The server side needs routing set up on its side so that other clients of the server's LAN can access Site #2's LAN subnet
• The config itself has client <> client options, so assuming I don't need to add a route for 192.168.20.0
• Do I need to do any VPN Director routing rules on Site #2?

Something doesn't seem quite right, at best I get unidirectional success (if I turn on Create NAT on Tunnel for Site #2) but not bidirectional. Would anyone have any insight? Help is much appreciated!

 

[ZebMcKayhan]

multiple threads about performance issues & tested myself to find out... I have the same performance problems

Just fyi. The firmware disables nat hw accelleration when wireguard is enabled. Altough several reports shows that this is not needed specifically for site2site setup. Presumably because there are no nat involved. You could try to re-enable nat hw accelleration after wireguard is started by ssh into the router and execute

fc enable

If you dont experience any problems it could be made permanent by putting it in wgs script hooks.

 

[philote]

Just fyi. The firmware disables nat hw accelleration when wireguard is enabled. Altough several reports shows that this is not needed specifically for site2site setup. Presumably because there are no nat involved. You could try to re-enable nat hw accelleration after wireguard is started by ssh into the router and execute

fc enable

If you dont experience any problems it could be made permanent by putting it in wgs script hooks.

Thanks @ZebMcKayhan, that might potentially help with client <> internet connections, as that wouldn't travel through the tunnel, but considering both sites have 1 Gbps connections, & one of them has a Synology NAS, I'd like the speed within the site<>site connection to also be accelerated. I do periodic backups to the 2nd site so throughput is important. From what I can tell with my unidirectional success, the performance for site<>site is significantly better with OpenVPN instead of WireGuard. I just need to figure out the bidirectional routing & should be sorted.

 

[philote]

As an update, still trying to figure this out.

I've tried adding below to the custom config of site #2's OpenVPN client config, that didn't work.

route 192.168.25.0 255.255.255.0

I've also tried adding this static route to Site #2's LAN Route config, & that doesn't work either.

 

[elorimer]

I assume you have access from the client's LAN to the server's LAN but not from the server's LAN to the client's LAN?

Do this and only this: in the "allowed clients" box, enter the client's subnet, not the router's subnet, and push is no. Set inbound firewall to allowed.

 

[philote]

I assume you have access from the client's LAN to the server's LAN but not from the server's LAN to the client's LAN?

Do this and only this: in the "allowed clients" box, enter the client's subnet, not the router's subnet, and push is no.

Unfortunately I can't connect from the client's LAN to the server's LAN either without first setting Create NAT on Tunnel to Yes.

If Create NAT on Tunnel set to No, then I can't connect from either LAN to the other LAN (although the VPN connection does get established).

 

[elorimer]

I have it set to Yes. Not sure why that is unfortunate?

But anyway look here: https://www.snbforums.com/threads/create-nat-on-tunnel.63158/post-567805

 

[philote]

I thought if Create NAT on Tunnel is set to Yes, that means the nodes of the client LAN can connect to nodes of the server LAN, but not the other way around. That's why disabling NAT & having the routing rules are important, so the connection is bidirectional.

@ColinTaylor has a comment in the link you provided that seems to confirm my understanding.

My question is about what those static routing rules should look like, on the server & client side of the VPN connection.

 

[Bearnet]

Here's my working OpenVPN lan-to-lan setup (GT-AX6000 and RT-AX86U) without NAT:
- network 1 (server): 192.168.1.0/24

- network 2 (client): 192.168.11.0/24, 192.168.12.0/24, 192.168.13.0/24

All clients from all subnets are able to communicate with each other. There's no need to set up static routing or anything else besides what's visible in my config. N.B. you must use "client" for the Common Name (CN).

 

[elorimer]

I thought if Create NAT on Tunnel is set to Yes, that means the nodes of the client LAN can connect to nodes of the server LAN, but not the other way around

I think it means that the client router is supplying its own IP address to the server and vice versa. If set to no, it means that the client router is routing directly from a device on the LAN to a device on the server router's LAN. I think that is why Colin specified the conditions where yes wouldn't be a sufficient answer--when you need to use the device's actual IP address.

But Bearnet's config has me confused, because I thought each subnet had to have its own way of differentiating, so .11 doesn't go to the router with .12.