Connecting two ASUS routers point to point via OpenVPN TUN and server can't ping client

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Ed B.

Occasional Visitor
Spoiler: While I was putting together my question, I managed to come up with the right combination of configs to allow my two ASUS routers to talk to each other via OpenVPN TUN. I'm leaving my original question and final config out here for anyone else who is trying to do the same. I have also added some questions in BLUE so hopefully someone can help me understand the few points I'm confused on.

Over the past 4+ years I have tried many many times to connect two ASUS routers via OpenVPN TUN and talk in both directions between the server and client networks. Every time has ended with dozens of hours lost, painful sleep-deprived headaches, and hours of depression counseling trying to sort through deep rooted feelings of inadequacy, explaining for my 110 minute double-sessions that I shouldn't have to use TAP.

My criteria is I want to use standard ASUS firmware, via GUI only. <- Note that all other guides I found on the internet either used a flashed firmware, or required using SSH or another means to modify the router outside of its web interface. If anyone knows of another guide (that works) for setting up two asus routers in site to site OpenVPN, without flashing or SSH, please let me know!

Ideally I would like to have 2-3 ASUS client routers connect to one ASUS server router via site to site (point to point) and have them all be able to talk to each other, but right now I'd be thrilled if I could even get one client and server to ping each other.

My latest attempt is with a GT-AX11000 as the server and an RT-AC86U as the client.

Server Setup:
upload_2019-1-31_1-29-42.png


Client Setup:
upload_2019-1-31_1-29-29.png


Client .ovpn file:
Code:
remote XXXXXXX.asuscomm.com 31234
dev tun
proto udp

resolv-retry infinite
keepalive 15 60
persist-key
persist-tun
float
nobind

sndbuf 0
rcvbuf 0
comp-lzo adaptive
auth-user-pass
client
auth SHA1
cipher AES-128-CBC
ns-cert-type server

verb 5

<ca>
-----BEGIN CERTIFICATE-----
XXX
-----END CERTIFICATE-----

</ca>

<cert>
-----BEGIN CERTIFICATE-----
XXX
-----END CERTIFICATE-----

</cert>

<key>
-----BEGIN PRIVATE KEY-----
XXX
-----END PRIVATE KEY-----

</key>

Server Routing Table:
Code:
Destination     Gateway         Genmask         Flags    Metric Ref    Use Type Iface
default         171.22.22.1     0.0.0.0         UG       0      0        0 WAN0 eth0
10.1.2.0        10.1.2.2        255.255.255.0   UG       0      0        0      tun21
10.1.2.2        *               255.255.255.255 UH       0      0        0      tun21
10.100.100.0    *               255.255.255.0   U        0      0        0 LAN  br0
10.100.101.0    10.1.2.2        255.255.255.0   UG       0      0        0      tun21
171.22.22.0     *               255.255.248.0   U        0      0        0 WAN0 eth0
171.22.22.1     *               255.255.255.255 UH       0      0        0 WAN0 eth0

Client Routing Table:
Code:
Destination     Gateway         Genmask         Flags    Metric Ref    Use Type Iface
default         169.11.24.1     0.0.0.0         UG       0      0        0 WAN0 eth0
10.1.2.0        10.1.2.5        255.255.255.0   UG       0      0        0      tun15
10.1.2.5        *               255.255.255.255 UH       0      0        0      tun15
10.100.100.0    10.1.2.5        255.255.255.0   UG       500    0        0      tun15
10.100.101.0    *               255.255.255.0   U        0      0        0 LAN  br0
169.11.24.0     *               255.255.240.0   U        0      0        0 WAN0 eth0
169.11.24.1     *               255.255.255.255 UH       0      0        0 WAN0 eth0

Pings:
Code:
[Client Router] to [Server Router VPN - 10.1.2.1]:
  SUCCESS:  64 bytes from 10.1.2.1: seq=0 ttl=64 time=54.669 ms

[Client Router] to [Server Router VPN - 10.1.2.2]:
  FAIL:  1 packets transmitted, 0 packets received, 100% packet loss

[Client Router] to [Server Router VPN - 10.1.2.5]:
  FAIL:  1 packets transmitted, 0 packets received, 100% packet loss

[Client Router] to [Client Router VPN - 10.1.2.6]:
  SUCCESS:  64 bytes from 10.1.2.6: seq=0 ttl=64 time=0.144 ms

[Client Router] to [Server Router IP]:
  SUCCESS:  64 bytes from 10.100.100.100: seq=0 ttl=127 time=54.266 ms

[Client Router] to [Computer attached to Server Router]:
  SUCCESS:  64 bytes from 10.100.100.201: seq=0 ttl=127 time=54.480 ms

[Computer attached to Client Router] to [Computer attached to Server Router]:
        C:\>ping 10.100.100.201
        Pinging 10.100.100.201 with 32 bytes of data:
  SUCCESS:  Reply from 10.100.100.201: bytes=32 time=172ms TTL=126

[Server Router] to [Server Router VPN - 10.1.2.1]:
  SUCCESS:  64 bytes from 10.1.2.1: seq=0 ttl=64 time=0.122 ms

[Server Router] to [Server Router VPN - 10.1.2.2]:
  FAIL:  1 packets transmitted, 0 packets received, 100% packet loss

[Server Router] to [Server Router VPN - 10.1.2.5]:
  FAIL:  1 packets transmitted, 0 packets received, 100% packet loss

[Server Router] to [Client Router VPN - 10.1.2.6]:
  SUCCESS:  64 bytes from 10.1.2.6: seq=0 ttl=64 time=50.703 ms

[Computer attached to Server Router] to [Computer attached to Client Router]:
        C:\>ping 10.100.101.1
        Pinging 10.100.101.1 with 32 bytes of data:
  SUCCESS:  Reply from 10.100.101.1: bytes=32 time=51ms TTL=62

Here is where I got stopped in my tracks! Prior to this, the Server Router was never able to ping the Client Router, and certainly a computer on the Server network could never ping a computer on the Client network!

Luckily I think I know what I fixed! In creating this post, I wanted to get a clean set of logs from the server showing the progresssion from enabling the VPN through the client connection. To do this, I turned off the VPN (flipped the 'Enable OpenVPN Server' switch to 'OFF'), cleared the system logs, then turned the VPN back on. Doing this clears the list of 'Allowed Clients', so I had to put the Keyport entry back in and this time I inadvertantly set 'Path' to 'No'. Note that I had tried 'No' in the past, so something else must have been blocking me at that time. I then went along my merry way and lo and behold when I got up to the pings they worked!

I have not checked if setting the Path back to Yes would recreate the issue, but I can confirm that using all of the above configuration (but with Path set to No) has successfully worked.

Below I will clarify how I think the IP addresses are used in the VPN Tunnel. Here is my analysis, but hopefully someone more knowledgeable can confirm:

The VPN Tunnel is set up the moment you turn 'ON' the VPN, before any client connects. This can be seen in the Server log as "ifconfig tun21 10.1.2.1 pointopoint 10.1.2.2 mtu 1500", So:
10.1.2.1 is the server side of the VPN Tunnel
10.1.2.2 is the client side of the VPN Tunnel, reserved for Keyport


A
route is added on the server "add -net 10.100.101.0 netmask 255.255.255.0 gw 10.1.2.2". This occurred because of the 'Allowed Clients' entry. And it makes sense since everything with a 10.100.101.x should be sent over to the Keyport-side of the VPN tunnel.
Another route is added on the server "add -net 10.1.2.0 netmask 255.255.255.0 gw 10.1.2.2". This does not make sense to me. Why should everything with a 10.1.2.x be sent to the Keyport-side of the VPN tunnel? What if there are other clients attached at the same time? They would all also start with 10.1.2.x Unless 10.1.2.2 just refers to the VPN tunnel and not specifically to the Keyport-client? If so, then how would the 10.1.2.2 void in the middle of the VPN tunnel know where to send the 10.100.101.x crap that was sent to it from the other route that was created (see paragraph above)? Wouldn't it then need an iroute to tell it which client endpoint to send to? I feel like I'm so close to understanding this stuff, but just don't get it. Wait, I think I do see the iroute... When Keyport connects, this line happens on the server "internal route 10.100.101.0/24 -> Keyport/169.11.24.85:57870", but why the heck would it be using Keyport's IP address and port in that definition since we're already inside the tunnel? Arghhh. Or is that done by the "primary virtual IP for Keyport/169.11.24.85:57870: 10.1.2.6" line above?

It is clear that server pushes the client an "ifconfig 10.1.2.6 10.1.2.5", So:
10.1.2.6 is the IP address of the local (keyport client) VPN endpoint
10.1.2.5 is the IP address of the remote (server) VPN endpoint.
No idea why .6 would respond to pings, but .5 wouldn't then? Would this be dependent on the 'respond to ping from wan' setting the firewall page, who knows! And on that note, why the heck would .1 respond to pings, but not .2? Grrrr.


And what the heck is this line about: "IFCONFIG POOL: base=10.1.2.4 size=62, ipv6=0" since there is literally no other mention of .4 anywhere!

Ok, that's all I have for now. Any help on understanding how the VPN IP addresses are used is appreciated.

Other Notes:
- All IP Addresses, port numbers, etc. in this post have been obfuscated.
- In the client log you may see 'GT-AC5300'. I believe this occurs because I exported my OpenVPN configuration file from a 5300 and imported it into the 11000.

 

Attachments

  • upload_2019-1-31_1-4-9.png
    upload_2019-1-31_1-4-9.png
    305.2 KB · Views: 521
  • upload_2019-1-31_1-24-37.png
    upload_2019-1-31_1-24-37.png
    99 KB · Views: 520

Ed B.

Occasional Visitor
Relevant Logs From The Server:
Code:
02:34:36 rc_service: httpd 19130:notify_rc restart_openvpnd;restart_chpass;restart_samba
02:34:37 vpnserver1[1684]: OpenVPN 2.3.2 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [EPOLL] [eurephia] [MH] [IPv6] built on Nov 20 2018
02:34:37 vpnserver1[1684]: PLUGIN_INIT: POST /usr/lib/openvpn-plugin-auth-pam.so '[/usr/lib/openvpn-plugin-auth-pam.so] [openvpn]' intercepted=PLUGIN_AUTH_USER_PASS_VERIFY 
02:34:37 vpnserver1[1684]: Diffie-Hellman initialized with 2048 bit key
02:34:37 vpnserver1[1684]: Socket Buffers: R=[524288->524288] S=[524288->524288]
02:34:37 vpnserver1[1684]: TUN/TAP device tun21 opened
02:34:37 vpnserver1[1684]: TUN/TAP TX queue length set to 100
02:34:37 vpnserver1[1684]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
02:34:37 vpnserver1[1684]: /sbin/ifconfig tun21 10.1.2.1 pointopoint 10.1.2.2 mtu 1500
02:34:37 vpnserver1[1684]: /sbin/route add -net 10.100.101.0 netmask 255.255.255.0 gw 10.1.2.2
02:34:37 vpnserver1[1684]: /sbin/route add -net 10.1.2.0 netmask 255.255.255.0 gw 10.1.2.2
02:34:37 vpnserver1[1689]: UDPv4 link local (bound): [undef]
02:34:37 vpnserver1[1689]: UDPv4 link remote: [undef]
02:34:37 vpnserver1[1689]: MULTI: multi_init called, r=256 v=256
02:34:37 vpnserver1[1689]: IFCONFIG POOL: base=10.1.2.4 size=62, ipv6=0
02:34:37 vpnserver1[1689]: Initialization Sequence Completed
02:34:37 Samba Server: smb daemon is stoped
02:34:37 dnsmasq[1712]: warning: no upstream servers configured

02:34:51 vpnserver1[1689]: 169.11.24.85:57870 TLS: Initial packet from [AF_INET]169.11.24.85:57870 (via [AF_INET]171.22.22.54%eth0), sid=f9e40761 b1dffcf8
02:34:52 vpnserver1[1689]: 169.11.24.85:57870 PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
02:34:52 vpnserver1[1689]: 169.11.24.85:57870 TLS: Username/Password authentication succeeded for username 'Keyport' [CN SET]
02:34:52 vpnserver1[1689]: 169.11.24.85:57870 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
02:34:52 vpnserver1[1689]: 169.11.24.85:57870 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
02:34:52 vpnserver1[1689]: 169.11.24.85:57870 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
02:34:52 vpnserver1[1689]: 169.11.24.85:57870 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
02:34:52 vpnserver1[1689]: 169.11.24.85:57870 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA
02:34:52 vpnserver1[1689]: 169.11.24.85:57870 [Keyport] Peer Connection Initiated with [AF_INET]169.11.24.85:57870 (via [AF_INET]171.22.22.54%eth0)
02:34:52 vpnserver1[1689]: Keyport/169.11.24.85:57870 OPTIONS IMPORT: reading client specific options from: ccd/Keyport
02:34:52 vpnserver1[1689]: Keyport/169.11.24.85:57870 MULTI_sva: pool returned IPv4=10.1.2.6, IPv6=(Not enabled)
02:34:52 vpnserver1[1689]: Keyport/169.11.24.85:57870 MULTI: Learn: 10.1.2.6 -> Keyport/169.11.24.85:57870
02:34:52 vpnserver1[1689]: Keyport/169.11.24.85:57870 MULTI: primary virtual IP for Keyport/169.11.24.85:57870: 10.1.2.6
02:34:52 vpnserver1[1689]: Keyport/169.11.24.85:57870 MULTI: internal route 10.100.101.0/24 -> Keyport/169.11.24.85:57870
02:34:52 vpnserver1[1689]: Keyport/169.11.24.85:57870 MULTI: Learn: 10.100.101.0/24 -> Keyport/169.11.24.85:57870
02:34:54 vpnserver1[1689]: Keyport/169.11.24.85:57870 PUSH: Received control message: 'PUSH_REQUEST'
02:34:54 vpnserver1[1689]: Keyport/169.11.24.85:57870 send_push_reply(): safe_cap=940
02:34:54 vpnserver1[1689]: Keyport/169.11.24.85:57870 SENT CONTROL [Keyport]: 'PUSH_REPLY,route 10.100.100.0 255.255.255.0 vpn_gateway 500,route 10.1.2.0 255.255.255.0,topology net30,ping 15,ping-restart 60,ifconfig 10.1.2.6 10.1.2.5' (status=1)
02:34:54 vpnserver1[1689]: MULTI: Learn: 10.100.101.101 -> Keyport/169.11.24.85:57870
 

Ed B.

Occasional Visitor
I did some more research and I think I've answered my questions. 10.1.2.1 is the server router. 10.1.2.2 is the server router's side of the VPN tunnel. 10.1.2.4 is the start of a pool of addresses for the VPN tunnel to assign as clients connect. 10.1.2.5 is the client router's side of the VPN tunnel. 10.1.2.6 is the client router.

I put together an infographic to allow people to see how this works. It shows the internet, vpn, routes, and iroutes within the VPN. Let me know if I'm incorrect on anything and I'll update the image.
VPN-Route-IP-Addresses.png
 

Klueless

Very Senior Member
Thank you for posting all of this. I'm trying to do similar and having similar issues. I'm going to study your post Tuesday. Maybe I'll get lucky. Thanks again!
 

Gingernut

Senior Member
I did some more research and I think I've answered my questions. 10.1.2.1 is the server router. 10.1.2.2 is the server router's side of the VPN tunnel. 10.1.2.4 is the start of a pool of addresses for the VPN tunnel to assign as clients connect. 10.1.2.5 is the client router's side of the VPN tunnel. 10.1.2.6 is the client router.

I put together an infographic to allow people to see how this works. It shows the internet, vpn, routes, and iroutes within the VPN. Let me know if I'm incorrect on anything and I'll update the image.
View attachment 16104

I have my Asus 86U setup as a VPN server and it works just fine, true, I'm not using another Asus router as the client and use OpenVPN as the client on Windows but it does connect flawlessly.

I've attached my setup, note that I have to have the channel encypted to get through my works DPI firewall.
 

Attachments

  • Anotación 2019-02-02 082003.jpg
    Anotación 2019-02-02 082003.jpg
    70.4 KB · Views: 417

Ed B.

Occasional Visitor
Gingernut, thanks for the screenprint. You've set things up a little bit different, so it's good to know it works with that configuration. And yes, the big problem here is the bi-directional communications across two routers in point-to-point. Connecting to a server router from a windows machine has worked for me as well. I can also confirm that ASUS Routers are able to simultaneously act as both a server and a client at the same time. (I have been able to VPN into my 86U from my laptop running OpenVPN at a different location, then establish a client link from the 86U to my AC5300 at yet another location, then access the network behind my AC5300 from the laptop (through the 86U) - fun!

It's the router-to-router / point-to-point / site-to-site that has given me a lot of trouble. I spent the weekend futzing around and I think I've found most of the pitfalls now. I've put together a guide which I will be posting shortly...
 

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