Openvpn server on asus merlin - connections but but seem to be enlessly reconnecting

ColHut

Occasional Visitor
G'day,

I have setup an open vpn server on my asus router (merlin firmware) using this guide:


I replaced #!/bin/bash with #!/bin/sh. NB my knowledge of what I am doing is limited, I can spell PUTTY and use it but I do not reallu understand it.

I set the local IP addresses as 192.168.1.6 and .10 for the VPN client NASes - one of which is remote.

1645000220423.png


as you an see at least one client connects but does not seem stable:

It seems to be not connecting properly:

1645000322935.png



Below is the advanced config pane:

1645000510696.png


I cannot ping the clients either from the local LAN on their VPN ip address, and the nases themselves do not show a connection to the vpn server.

Any thoughts?

regards
 

ColHut

Occasional Visitor
Thankyou.

The router is RT-AC86U.

The lan ip ranges is 192.168.0.x. And gateway 192.168.0.1 (this router replaced a TP link one and with many static lan ips it was easier to change the new asus router to match the old TP link LAN ranges). So the vpn ip range and subnet mask should be fine I think.

regards
 

ColinTaylor

Part of the Furniture
OK thanks for the clarification. So the client's LAN network is 192.168.0.x and the server's LAN network is something other than 192.168.1.x. Correct?

What happens if you remove the --client-connect directive. Does the client connect successfully?

Look in the server router's syslog for error messages.
 

eibgrad

Part of the Furniture
It would be my assumption this is the exact same problem the OP posted only a few hours prior to starting this thread.


As I indicated in that other thread, you can't mix static IP assignments based on net30 topology (as described in that other link the OP provided) w/ an OpenVPN server which is presumably using a subnet topology (at least it does by default). One or the other has to be modified to make it consistent.

Seems to me it's time for the OP to make all these details clear; what the server is using for a topology, what the client-connect script is using for a topology, and while we're at it, the IP network of the OpenVPN client, IP tunnel (presumably 192.168.1.0/24), and the OpenVPN server.
 

ColHut

Occasional Visitor
Thanks, for your assistance.

Earlier I had no trouble connecting, it just changed , probably after the firmware upgrade to merlin, to giving out .1 and . 2 ip addresses Instead of the .6 and .10 addresses. I have not consciously made any changes to the topology.
I have tried to set up static client ip addresses based on the above article (see topic starter).

The local lan ip range is 192.168.0.x
The remote lan range (not of interest here) is 10.1.100.x I think.
The vpn server ip range is 192.168.1.x
There is one local machine connected to the vpn server and one remote machine connected to the vpn server.


Based on your previous comments I assumed the router is using the ip range and subnet mask you stated. I did not think that me specifying ip addresses for the clients would change that or matter to the server?

I will take a look at the syslogs.

I hope this helps.

regards
 

ColHut

Occasional Visitor
Part of syslog

Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 TLS: Initial packet from [AF_INET]220.235.75.247:50003 (via [AF_INET]61.245.132.243%eth0), sid=eace4ffe cc683ded
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 VERIFY OK: depth=1, C=TW, ST=TW, L=Taipei, O=ASUS, OU=Home/Office, CN=RT-AC86U, emailAddress=[email protected]
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 VERIFY OK: depth=0, C=TW, ST=TW, L=Taipei, O=ASUS, OU=Home/Office, CN=client, emailAddress=[email protected]
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 peer info: IV_VER=2.4.11
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 peer info: IV_PLAT=linux
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 peer info: IV_PROTO=2
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 peer info: IV_NCP=2
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 peer info: IV_LZ4=1
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 peer info: IV_LZ4v2=1
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 peer info: IV_LZO=1
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 peer info: IV_COMP_STUB=1
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 peer info: IV_COMP_STUBv2=1
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 peer info: IV_TCPNL=1
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 TLS: Username/Password authentication succeeded for username 'NASDEA39D'
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1541'
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 1024 bit RSA, signature: RSA-SHA256
Feb 17 18:06:56 ovpn-server1[24519]: 220.235.75.247:50003 [client] Peer Connection Initiated with [AF_INET]220.235.75.247:50003 (via [AF_INET]61.245.132.243%eth0)
Feb 17 18:06:56 ovpn-server1[24519]: client/220.235.75.247:50003 MULTI_sva: pool returned IPv4=192.168.1.2, IPv6=(Not enabled)
Feb 17 18:06:56 ovpn-server1[24519]: client/220.235.75.247:50003 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_350e32de2a452396.tmp
Feb 17 18:06:56 ovpn-server1[24519]: client/220.235.75.247:50003 MULTI: Learn: 192.168.1.6 -> client/220.235.75.247:50003
Feb 17 18:06:56 ovpn-server1[24519]: client/220.235.75.247:50003 MULTI: primary virtual IP for client/220.235.75.247:50003: 192.168.1.6
Feb 17 18:06:56 ovpn-server1[24519]: client/220.235.75.247:50003 Data Channel: using negotiated cipher 'AES-256-GCM'
Feb 17 18:06:56 ovpn-server1[24519]: client/220.235.75.247:50003 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Feb 17 18:06:56 ovpn-server1[24519]: client/220.235.75.247:50003 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Feb 17 18:06:57 wlceventd: wlceventd_proc_event(527): eth5: Auth 72:08:EE:A3:27:DA, status: Successful (0), rssi:0
Feb 17 18:06:57 wlceventd: wlceventd_proc_event(537): eth5: ReAssoc 72:08:EE:A3:27:DA, status: Successful (0), rssi:0
Feb 17 18:06:58 ovpn-server1[24519]: client/220.235.75.247:50003 PUSH: Received control message: 'PUSH_REQUEST'
Feb 17 18:06:58 ovpn-server1[24519]: client/220.235.75.247:50003 SENT CONTROL [client]: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0 vpn_gateway 500,dhcp-option DOMAIN lan,dhcp-option DNS 192.168.0.1,route-gateway 192.168.1.1,topology subnet,ping 15,ping-restart 60,ifconfig 192.168.1.6 192.168.1.5,peer-id 17,cipher AES-256-GCM' (status=1)
Feb 17 18:06:58 wlceventd: wlceventd_proc_event(508): eth6: Disassoc 72:08:EE:A3:27:DA, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 17 18:06:58 wlceventd: wlceventd_proc_event(508): eth6: Disassoc 72:08:EE:A3:27:DA, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Feb 17 18:06:59 ovpn-server1[24519]: client/192.168.0.200:49409 [client] Inactivity timeout (--ping-restart), restarting
Feb 17 18:06:59 ovpn-server1[24519]: client/192.168.0.200:49409 SIGUSR1[soft,ping-restart] received, client-instance restarting
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 TLS: Initial packet from [AF_INET]192.168.0.200:37844 (via [AF_INET]61.245.132.243%br0), sid=a75bc4c4 c7c63853
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 VERIFY OK: depth=1, C=TW, ST=TW, L=Taipei, O=ASUS, OU=Home/Office, CN=RT-AC86U, emailAddress=[email protected]
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 VERIFY OK: depth=0, C=TW, ST=TW, L=Taipei, O=ASUS, OU=Home/Office, CN=client, emailAddress=[email protected]
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 peer info: IV_VER=2.4.11
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 peer info: IV_PLAT=linux
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 peer info: IV_PROTO=2
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 peer info: IV_NCP=2
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 peer info: IV_LZ4=1
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 peer info: IV_LZ4v2=1
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 peer info: IV_LZO=1
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 peer info: IV_COMP_STUB=1
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 peer info: IV_COMP_STUBv2=1
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 peer info: IV_TCPNL=1
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 TLS: Username/Password authentication succeeded for username 'NAS08BF0B'
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1541'
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 1024 bit RSA, signature: RSA-SHA256
Feb 17 18:07:03 ovpn-server1[24519]: 192.168.0.200:37844 [client] Peer Connection Initiated with [AF_INET]192.168.0.200:37844 (via [AF_INET]61.245.132.243%br0)
Feb 17 18:07:03 ovpn-server1[24519]: client/192.168.0.200:37844 MULTI_sva: pool returned IPv4=192.168.1.2, IPv6=(Not enabled)
Feb 17 18:07:03 ovpn-server1[24519]: client/192.168.0.200:37844 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_32f6e62b59d43e31.tmp
Feb 17 18:07:03 ovpn-server1[24519]: client/192.168.0.200:37844 MULTI: Learn: 192.168.1.10 -> client/192.168.0.200:37844
Feb 17 18:07:03 ovpn-server1[24519]: client/192.168.0.200:37844 MULTI: primary virtual IP for client/192.168.0.200:37844: 192.168.1.10
Feb 17 18:07:03 ovpn-server1[24519]: client/192.168.0.200:37844 Data Channel: using negotiated cipher 'AES-256-GCM'
Feb 17 18:07:03 ovpn-server1[24519]: client/192.168.0.200:37844 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Feb 17 18:07:03 ovpn-server1[24519]: client/192.168.0.200:37844 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Feb 17 18:07:04 ovpn-server1[24519]: client/192.168.0.200:37844 PUSH: Received control message: 'PUSH_REQUEST'
Feb 17 18:07:04 ovpn-server1[24519]: client/192.168.0.200:37844 SENT CONTROL [client]: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0 vpn_gateway 500,dhcp-option DOMAIN lan,dhcp-option DNS 192.168.0.1,route-gateway 192.168.1.1,topology subnet,ping 15,ping-restart 60,ifconfig 192.168.1.10 192.168.1.9,peer-id 0,cipher AES-256-GCM' (status=1)
 

ColHut

Occasional Visitor
This seems to indicate a problem:

20:12:05 ovpn-server1[19402]: client/192.168.0.200:60475 SIGUSR1[soft,ping-restart] received, client-instance restarting
Feb 17 20:12:10 ovpn-server1[19402]: 192.168.0.200:57582 TLS: Initial packet from [AF_INET]192.168.0.200:57582 (via [AF_INET]61.245.132.243%br0), sid=25334283 15e72aaa

regards
 

ColinTaylor

Part of the Furniture
This seems to indicate a problem:

20:12:05 ovpn-server1[19402]: client/192.168.0.200:60475 SIGUSR1[soft,ping-restart] received, client-instance restarting
Feb 17 20:12:10 ovpn-server1[19402]: 192.168.0.200:57582 TLS: Initial packet from [AF_INET]192.168.0.200:57582 (via [AF_INET]61.245.132.243%br0), sid=25334283 15e72aaa

regards
I don't understand why you have a device on the local network (192.168.0.200) that is connecting to the VPN server on the same network via NAT loopback. Apart from appearing to be pointless, accessing the LAN via a VPN loopback connection usually doesn't work in my experience.
 

ColHut

Occasional Visitor
It was the only way I could get the two NASes to see each other with the former router and earlier with one running a QVPN openvpn server. And having it set up and working, it is a massive pita to redo rtrr jobs nas to nas as opposed to rsync jobs which are pretty easy.

regards
 

ColHut

Occasional Visitor
Success eludes me.

I started again and have set up a new openvpn server on the router using the default values.

I have only connected the remote client NAS C to the vpn.

The connection is established to the server.

I can now connect from my local NAS B on 192.168.0.200 to the remote NAS C on 10.8.0.2 and run back up jobs using HBS3 to NAS C.

I cannot connect the other way around from the remote NAC C on 10.8.0.2 back to the local NAS B on 192.168.0.200, nor detect any other local ip.

I am going backwards I think. :(

regards
 

eibgrad

Part of the Furniture
Success eludes me.

I started again and have set up a new openvpn server on the router using the default values.

I have only connected the remote client NAS C to the vpn.

The connection is established to the server.

I can now connect from my local NAS B on 192.168.0.200 to the remote NAS C on 10.8.0.2 and run back up jobs using HBS3 to NAS C.

I cannot connect the other way around from the remote NAC C on 10.8.0.2 back to the local NAS B on 192.168.0.200, nor detect any other local ip.

I am going backwards I think. :(

regards

Well I wouldn't say you're going backwards. As I indicated previously, until you stopped trying to use net30 w/ your static IPs while using a subnet topology on the server (as was evident in the following from the syslog)...

Code:
Feb 17 18:07:04 ovpn-server1[24519]: client/192.168.0.200:37844 SENT CONTROL [client]: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0 vpn_gateway 500,dhcp-option DOMAIN lan,dhcp-option DNS 192.168.0.1,route-gateway 192.168.1.1,topology subnet,ping 15,ping-restart 60,ifconfig 192.168.1.10 192.168.1.9,peer-id 0,cipher AES-256-GCM' (status=1)

... you weren't going to get anywhere.

But it seems NOW you've finally gotten past that issue. And you have connectivity from the OpenVPN client and to the OpenVPN server. For bidirectional (aka site-to-site) purposes, you have to configure Manage Client-Specific Options on the server to tell it what IP network(s) lie behind that OpenVPN client based on the CN (Common Name) of its client cert, which when using the default client cert is named 'client' (no quotes). Otherwise any devices on the server's own IP network have no idea how to route to that IP network behind the client.

Also, if the OpenVPN client is using a Merlin router, you need to also make sure you have "Inbound Firewall" set to Allow (the default is Block) in order for site-to-site to work.
 

ColHut

Occasional Visitor
Thankyou,

much appreciated.

I will look into the client specific options and check the client router setting to, a boblite iinet router.

regards
 

ColHut

Occasional Visitor
Hmmm I still cannot connect the other way around from the remote NAS C on vpn ip 10.8.0.2 back to the local NAS B on 192.168.0.200, nor detect any other local ip.

It is kind of bizarre that I can go from the LAN to the remote NAS but not from the remote NAS to the LAN.

It might be the the remote router, but I cannot access that remotely so checking that will have to wait.

I have “manage client specific Options” on and “allow client to client” on.

, “you have to configure Manage Client-Specific Options on the server to tell it what IP network(s) lie behind that OpenVPN client based on the CN (Common Name) of its client cert, which when using the default client cert is named 'client' (no quotes). Otherwise any devices on the server's own IP network have no idea how to route to that IP network behind the client.”

so ‘client’ should be set to 192.168.0.0 Mask 255.255.255.0? Push left to ‘no’?

no need for a push route?

edit, no joy. Whether push yes or no.

regards

regards
 
Last edited:

eibgrad

Part of the Furniture
so ‘client’ should be set to 192.168.0.0 Mask 255.255.255.0? Push left to ‘no’?

Yes.

no need for a push route?

You push a route (from the server) when you want to tell the OpenVPN client what IP network(s) lies behind the OpenVPN server. You use Manage Client-Specific Options to tell the OpenVPN server what IP network(s) lie behind the OpenVPN client. So in a typical site-to-site configuration, you do BOTH. But they each serve different purposes.

You've never been very specific about the OpenVPN client, but as I said before, if the OpenVPN client is running on Merlin, you need to make sure the Inbound Firewall is set to Allow (the default is Block, which will NOT work w/ site-to-site).
 

ColHut

Occasional Visitor
Thankyou for your patience.

The remote client is a QNAP NAS running QVPN openvpn client.

It sits behind a Boblite router , which is a bastardised version of a TG 789 I believe.

The Boblite router is not running any vpn software.

Only the remote NAS C is running openvpn client Software

use Manage Client-Specific Options to tell the OpenVPN server what IP network(s) lie behind the OpenVPN client.

I have no other ip network beyond the remote client. So I think this means it is not a site to site setup, just a desire for simple two way communication on the vpn.

It looks like I might need a push route.

should I be using tap?

regards. (Edited for clarity)
 
Last edited:

ColHut

Occasional Visitor
Hmmm total failure.

The problem is certainly with the router Settings.

Previously I had this setup on an Archer c59 Running as the open vpn server. It only worked if both remote client and local client NAS were connected to the vpn. It unfortunately had no ability to allow static vpn ip addresses and this needed me to fairly often re-kick a client after network outage to get it to reset to the original vpn ip address, which used net 30, on which all the backups depend for identifying the remote QNAP backup servers.

I have made no changes to the remote router, which is not playing a part in this.

I might try the standard firmware.

At this stage this has been a huge waste of time and money.

regards
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top