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:
Client Setup:
Client .ovpn file:
Server Routing Table:
Client Routing Table:
Pings:
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:
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.
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:
Client Setup:
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 eth0Client 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 eth0Pings:
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=62Here 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!
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.
