Asus RT-AC68 router OpenVPN setup

catcamstar said:
Hi te2k,
TAP are mostly used for same-segment extensions (eg having the same subnet information left side and right side) - basically for site2site VPN situations. That's the reason why mobile apps don't support TAP. My conclusion so far is that your OpenVPN server does work well (otherwise you wouldn't be able to connect by TAP either). So it comes down to either the post-routing when tun VPN is opened, either firewall inbetween (eg block internet access on NVR), or a combination of both.

I suggest you work in a pragmatic step by step approach, between 2 "more debugable" devices, eg 1 PC (win/lin) and NAS (samba share).
Step 1: put pc on 100% LAN and open samba share: this should work
Step 2: configure openvpn tun for router, put pc on tethered 4G, and connect VPN client: this should work
Step 3: try to open samba share: this should work
Step 4: put NAS in "block internet access mode"
Step 5: try to open samba share: this should work

If In between step 3 and step 5, the services are broken, you have discovered the "root cause". Finding a solution is more difficult (eg vlanbased which is not something OOTB with Rmerlin).

Good luck!
CC
Click to expand...
Thanks for the reply CC. However I am a complete networking noob. Also I do not have a NAS and having a brief read on Samba Share it seems to be a sharing network between a linux and windows machine. I only have windows pc and laptop. so I am unsure if I would be able to replicate your steps above.

I've also tried the TUN Configuration with "block internet access" on NVR turned off but that gave me no joy as well.
If it helps, the below is my router routing table when I set the OpenVPN server to TUN:

Destination Gateway Genmask Flags Metric Ref Use Type Iface
10.8.0.2 * 255.255.255.255 UH 0 0 0 tun21
210.x.x.x * 255.255.255.255 UH 0 0 0 WAN0 eth0
210.x.x.x * 255.255.255.252 U 0 0 0 WAN0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun21
192.168.1.0 * 255.255.255.0 U 0 0 0 LAN br0
default 210.x.x.x 0.0.0.0 UG 0 0 0 WAN0 eth0
 
te2k said:
Thanks for the reply CC. However I am a complete networking noob. Also I do not have a NAS and having a brief read on Samba Share it seems to be a sharing network between a linux and windows machine. I only have windows pc and laptop. so I am unsure if I would be able to replicate your steps above.

I've also tried the TUN Configuration with "block internet access" on NVR turned off but that gave me no joy as well.
If it helps, the below is my router routing table when I set the OpenVPN server to TUN:

Destination Gateway Genmask Flags Metric Ref Use Type Iface
10.8.0.2 * 255.255.255.255 UH 0 0 0 tun21
210.x.x.x * 255.255.255.255 UH 0 0 0 WAN0 eth0
210.x.x.x * 255.255.255.252 U 0 0 0 WAN0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun21
192.168.1.0 * 255.255.255.0 U 0 0 0 LAN br0
default 210.x.x.x 0.0.0.0 UG 0 0 0 WAN0 eth0
Click to expand...

No problem, we all were noobs :) If you have 2 windows pc's, my test is still feasible (however, in windows 10 file & printer sharing is a bit more difficult, but still doable). As long as you disable the file sharing afterwards, it is ok. Quick steps to file sharing:
Step 1: open explorer
Step 2: create a temporary folder (eg c:\temp)
Step 3: rightclick - properties - second tab: sharing
Step 4: Press "share" button - this is the most difficult part for windows10: if you have the same username / pass combo on your two windows pc's, it is easy: you pick that one. Otherwise you might need to create a new (local) user, with a password (without it won't work!). Within step 4, you'll see that that directory gets an UNC path (eg \\your-pc-name\temp).
Step 5: on the same pc, try that path in explorer (just paste: \\your-pc-name\temp) - this should open that directory
Step 6: go to the other pc: repeat step 5 (just paste: \\your-pc-name\temp) and voilà, you have just tested if that file sharing service works.

Then you retake the guide above with the VPN tunnel active, and you'll quickly discover if all is good (or not).

From your routing table, this looks OK, you'll notice the 10.8 subnet for the VPN, the 192.168.1 for your LAN, and your WAN 210. Personally I would counteradvice to use the 192.168.1.x because if you would ever go to places (friends/family) who happen to have the same subnet, you'll run into routing issues anyway. Use something exoctic (192.168.212.x).

Good Luck!
CC
 
catcamstar said:
No problem, we all were noobs :) If you have 2 windows pc's, my test is still feasible (however, in windows 10 file & printer sharing is a bit more difficult, but still doable). As long as you disable the file sharing afterwards, it is ok. Quick steps to file sharing:
Step 1: open explorer
Step 2: create a temporary folder (eg c:\temp)
Step 3: rightclick - properties - second tab: sharing
Step 4: Press "share" button - this is the most difficult part for windows10: if you have the same username / pass combo on your two windows pc's, it is easy: you pick that one. Otherwise you might need to create a new (local) user, with a password (without it won't work!). Within step 4, you'll see that that directory gets an UNC path (eg \\your-pc-name\temp).
Step 5: on the same pc, try that path in explorer (just paste: \\your-pc-name\temp) - this should open that directory
Step 6: go to the other pc: repeat step 5 (just paste: \\your-pc-name\temp) and voilà, you have just tested if that file sharing service works.

Then you retake the guide above with the VPN tunnel active, and you'll quickly discover if all is good (or not).

From your routing table, this looks OK, you'll notice the 10.8 subnet for the VPN, the 192.168.1 for your LAN, and your WAN 210. Personally I would counteradvice to use the 192.168.1.x because if you would ever go to places (friends/family) who happen to have the same subnet, you'll run into routing issues anyway. Use something exoctic (192.168.212.x).

Good Luck!
CC
Click to expand...

Ok tried the above and it worked when laptop was connected via wifi and failed to work when connected to VPN via tethered 4G connection :(
 
te2k said:
Ok tried the above and it worked when laptop was connected via wifi and failed to work when connected to VPN via tethered 4G connection :(
Click to expand...

Great! This means it is not related to the NVR but purely network related.

Now we can start debugging!

Step 1: open ssh to your asus. In that prompt: ping both pc's (your share will be on 192.168.1. something, your openvpn pc on 10.8.0.x). Do both reply?
Step 2: open prompt on LANpc and ping 10.8 device: does that work? In an elevated command prompt try traceroute 10.8.0.x: what is the output?
Step 3: open prompt on VPNpc and ping 192.168.1 device: does that work? In an elevated command prompt try traceroute 192.168.1.x: what is the output?
 
catcamstar said:
Great! This means it is not related to the NVR but purely network related.

Now we can start debugging!

Step 1: open ssh to your asus. In that prompt: ping both pc's (your share will be on 192.168.1. something, your openvpn pc on 10.8.0.x). Do both reply?
Step 2: open prompt on LANpc and ping 10.8 device: does that work? In an elevated command prompt try traceroute 10.8.0.x: what is the output?
Step 3: open prompt on VPNpc and ping 192.168.1 device: does that work? In an elevated command prompt try traceroute 192.168.1.x: what is the output?
Click to expand...

Failed on Step 1. Able to ping main pc on 192.168.1.x but unable to ping 10.8.0.x
 
te2k said:
Failed on Step 1. Able to ping main pc on 192.168.1.x but unable to ping 10.8.0.x
Click to expand...
Make sure that your windows firewall is turned off on VPNpc? It is not safe, but for this test we must avoid having firewalls interfering with the test. Your router MUST see the 10.8.0.x device when the VPN tunnel is open!
 
catcamstar said:
Make sure that your windows firewall is turned off on VPNpc? It is not safe, but for this test we must avoid having firewalls interfering with the test. Your router MUST see the 10.8.0.x device when the VPN tunnel is open!
Click to expand...

Even with firewall turned off on VPNpc, router still unable to ping 10.8.0.x device. OpenVPN server shown as connected on router server page.

VPNpc able to ping router on 192.168.1.1 but not the main pc on 192.168.1.x
 
te2k said:
Even with firewall turned off on VPNpc, router still unable to ping 10.8.0.x device. OpenVPN server shown as connected on router server page.

VPNpc able to ping router on 192.168.1.1 but not the main pc on 192.168.1.x
Click to expand...

OK! Good! What is the output of a traceroute from that VPNpc?
Step 1: "traceroute 8.8.8.8"
Step 2: "traceroute 192.168.1.1"
Step 3: "traceroute 192.168.1.x (LANpc)"

Please post full output (except remove your 210.x wan address in that hop).
 
te2k said:
Even with firewall turned off on VPNpc, router still unable to ping 10.8.0.x device. OpenVPN server shown as connected on router server page.

VPNpc able to ping router on 192.168.1.1 but not the main pc on 192.168.1.x
Click to expand...

ok after switching from TUN to TAP just to test the router, and back to TUN I am now able to achieve Step 1 and Step 2. Tracert from Step 2:

Tracing route to VPNPC [10.8.0.6]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms router.asus.com [192.168.1.1]
2 58 ms 38 ms 51 ms VPNPC [10.8.0.6]

Step 3 is where I fail this time. Unable to ping 192.168.1.x from VPNPC
 
te2k said:
ok after switching from TUN to TAP just to test the router, and back to TUN I am now able to achieve Step 1 and Step 2. Tracert from Step 2:

Tracing route to VPNPC [10.8.0.6]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms router.asus.com [192.168.1.1]
2 58 ms 38 ms 51 ms VPNPC [10.8.0.6]

Step 3 is where I fail this time. Unable to ping 192.168.1.x from VPNPC
Click to expand...

Can you post the output of Step 3? I would expect to see at least a try to connect to 10.8.0.2, then 192.168.1.1 (because from VPNpc you were able to ping the asus router) and thén time-out.
 
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 4 ms 8 ms 5 ms 172.20.10.1
2 * * * Request timed out.
3 * * * Request timed out.
4 65 ms 36 ms 27 ms Bundle-Ether11.win-edge901.melbourne.telstra.net [139.130.111.101]
5 44 ms 60 ms 24 ms bundle-ether11.win-core10.melbourne.telstra.net [203.50.11.107]
6 66 ms 35 ms 38 ms bundle-ether12.ken-core10.sydney.telstra.net [203.50.11.122]
7 43 ms 47 ms 31 ms bundle-ether1.ken-edge903.sydney.telstra.net [203.50.11.173]
8 66 ms 36 ms 38 ms 72.14.212.22
9 * * * Request timed out.
10 68 ms 67 ms 45 ms 209.85.243.242
11 33 ms 40 ms 30 ms 216.239.40.255
12 126 ms 30 ms 38 ms google-public-dns-a.google.com [8.8.8.8]

Trace complete.

Tracing route to router.asus.com [192.168.1.1]
over a maximum of 30 hops:

1 52 ms 33 ms 35 ms router.asus.com [192.168.1.1]

Trace complete.

Tracing route to LANPC [192.168.1.x]
over a maximum of 30 hops:

1 40 ms 36 ms 45 ms 10.8.0.1
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.

Trace complete.
 
te2k said:
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

<snip>

Trace complete.
Click to expand...

Good! This confirms my thoughts. From the first trace you can see that the VPNpc does not enter the tunnel, goes across your tethered (internal) IP on 172.20 and finds the google server. From the latter, you can see that without any hop, it enters the VPN tunnel and finds your router. But the second trace confirms it lands in the VPN tunnel, but stays on the router never arriving on your LANpc.

Can you check in the (advanced) settings of your VPN server that the option "Redirect Internet Traffic" is set to "All Traffic"? What this does: it forces all traffic (on VPNpc, and your mobiles) to pass through the VPN tunnel, using your home ISP to access the internet. It has a (hopeful) positive sideeffect that your routing table on the ASUS gets preconfigured to fit these requirements. As all traffic MUST pass by 192.168.1.1, I foresee (hopeful) positive access to the LANpc. To know where this option is:

Then retry the 3 step traceroutes, they should appear differently.
 
Sigh CC. Apologies. I realized that when i change from TUN to TAP to TUN, somewhere in between, the VPNPC disconnected from my 4G network and connected to the home wifi. That's why it was working. Now that I've reconnected to the 4G network, this is what I get:

Tracing route to 192.168.1.1 over a maximum of 30 hops

1 * * * Request timed out.
2 * * * Request timed out.
3 10.4.151.139 reports: Destination net unreachable.

Trace complete.
 
te2k said:
Sigh CC. Apologies. I realized that when i change from TUN to TAP to TUN, somewhere in between, the VPNPC disconnected from my 4G network and connected to the home wifi. That's why it was working. Now that I've reconnected to the 4G network, this is what I get:

Tracing route to 192.168.1.1 over a maximum of 30 hops

1 * * * Request timed out.
2 * * * Request timed out.
3 10.4.151.139 reports: Destination net unreachable.

Trace complete.
Click to expand...
But that's technically impossible?! In step 3 you posted:

Tracing route to LANPC [192.168.1.x]
over a maximum of 30 hops:

1 40 ms 36 ms 45 ms 10.8.0.1
2 * * * Request timed out.
3 * * * Request timed out.

If your VPNpc happened to be on your Home Wifi (being on 192.168.1.y), there was absolutely no reason why he should hit 10.8.0.1 first when doing the traceroute to 192.168.1.x.

So roll back a bit, make sure you are on TUN (not TAP, because even if we fixed it on TAP, you will not be able to use it on your mobile), tethered with 4g and OpenVPN is connected. Retry the 3 traceroutes and REDO them when you changed the "redirect gateway" setting in my previous post. Then we can compare both outputs.
 
Hrmm..so I redid the tracerts and made sure it was server was set to TUN and for my router there was only Redirect clients to redirect internet traffic: Yes / No. Originally set at No, and now I've set it to Yes. Watching my wifi connection making sure its tethered to 4G network and the following are my tracerts

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 44 ms 28 ms 37 ms 10.8.0.1
2 48 ms 37 ms 35 ms 210.x.x.x
3 53 ms 38 ms 36 ms te3-3.mburndist02.aapt.net.au [203.131.61.32]
4 37 ms 57 ms 40 ms bu9.mburnbrdr11.aapt.net.au [202.10.14.37]
5 48 ms 38 ms 36 ms nme-apt-bur-wgw1-be-30.tpgi.com.au [203.219.107.205]
6 62 ms 49 ms 45 ms 203-219-155-193.tpgi.com.au [203.219.155.193]
7 56 ms 56 ms 51 ms syd-gls-har-crt1-be-10.tpgi.com.au [202.7.171.173]
8 70 ms 53 ms 53 ms 203-221-3-69.tpgi.com.au [203.221.3.69]
9 56 ms 47 ms 47 ms 72.14.197.162
10 60 ms 47 ms 48 ms 108.170.247.65
11 51 ms 47 ms 48 ms 216.239.41.187
12 48 ms 47 ms 50 ms google-public-dns-a.google.com [8.8.8.8]

Trace complete.

Tracing route to router.asus.com [192.168.1.1]
over a maximum of 30 hops:

1 58 ms 38 ms 36 ms router.asus.com [192.168.1.1]

Trace complete.

Tracing route to DESKTOP-10D32KE [192.168.1.42]
over a maximum of 30 hops:

1 36 ms 37 ms 36 ms 10.8.0.1
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
Basically Request timed out to 30 hops.
 
te2k said:
Hrmm..so I redid the tracerts and made sure it was server was set to TUN and for my router there was only Redirect clients to redirect internet traffic: Yes / No. Originally set at No, and now I've set it to Yes. Watching my wifi connection making sure its tethered to 4G network and the following are my tracerts

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 44 ms 28 ms 37 ms 10.8.0.1
2 48 ms 37 ms 35 ms 210.x.x.x
3 53 ms 38 ms 36 ms te3-3.mburndist02.aapt.net.au [203.131.61.32]
4 37 ms 57 ms 40 ms bu9.mburnbrdr11.aapt.net.au [202.10.14.37]
5 48 ms 38 ms 36 ms nme-apt-bur-wgw1-be-30.tpgi.com.au [203.219.107.205]
6 62 ms 49 ms 45 ms 203-219-155-193.tpgi.com.au [203.219.155.193]
7 56 ms 56 ms 51 ms syd-gls-har-crt1-be-10.tpgi.com.au [202.7.171.173]
8 70 ms 53 ms 53 ms 203-221-3-69.tpgi.com.au [203.221.3.69]
9 56 ms 47 ms 47 ms 72.14.197.162
10 60 ms 47 ms 48 ms 108.170.247.65
11 51 ms 47 ms 48 ms 216.239.41.187
12 48 ms 47 ms 50 ms google-public-dns-a.google.com [8.8.8.8]

Trace complete.

Tracing route to router.asus.com [192.168.1.1]
over a maximum of 30 hops:

1 58 ms 38 ms 36 ms router.asus.com [192.168.1.1]

Trace complete.

Tracing route to DESKTOP-10D32KE [192.168.1.42]
over a maximum of 30 hops:

1 36 ms 37 ms 36 ms 10.8.0.1
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
Basically Request timed out to 30 hops.
Click to expand...

So the good news: from trace 1, we can see that effectively your traffice is entering the tunnel, hops from 10.8 directly to 210 and goes on the internet. Trace 2 confirms you have direct access to the 192.168.1.1 gateway. But Trace 3 confirms you get stuck on the 10.8.0.1 gateway. I hoped that setting the "redirect gateway" option would have "repaired" the missing routing step between 10.8.0.1 and 192.168.1.x.

Just one final check before we move on:

https://i.stack.imgur.com/H1wnQ.png --> do you have "push LAN to client" settings turned on like in the screenshot?

One last thing I got in my sleeve is static routes: can you check under settings - LAN - Route that the "Enable Static Routes" is enabled? Restart of the OpenVPN server may be required!
https://i.stack.imgur.com/LQeRh.png
 
catcamstar said:
So the good news: from trace 1, we can see that effectively your traffice is entering the tunnel, hops from 10.8 directly to 210 and goes on the internet. Trace 2 confirms you have direct access to the 192.168.1.1 gateway. But Trace 3 confirms you get stuck on the 10.8.0.1 gateway. I hoped that setting the "redirect gateway" option would have "repaired" the missing routing step between 10.8.0.1 and 192.168.1.x.

Just one final check before we move on:

https://i.stack.imgur.com/H1wnQ.png --> do you have "push LAN to client" settings turned on like in the screenshot?

One last thing I got in my sleeve is static routes: can you check under settings - LAN - Route that the "Enable Static Routes" is enabled? Restart of the OpenVPN server may be required!
https://i.stack.imgur.com/LQeRh.png
Click to expand...

Yes and Yes.
 
catcamstar said:
Really strange. I did some further Google, and found even more strange answers (eg Help! Can't access local network w/OpenVPN) - can you try to disable compression and regenerate the .ovpn file and import on the VPNpc?

I have an appointment now, if nobody drives by in the meantime, I'll be back in an hour of 3-4.
Click to expand...

I have already disabled compression. I've read that post as well. Same thing with Enable Static Route :)
I also have to head to bed and will be up in around 8 hours time before heading to work.
Thank you so much for your help so far. Really appreciate it.
 
te2k said:
I have already disabled compression. I've read that post as well. Same thing with Enable Static Route :)
I also have to head to bed and will be up in around 8 hours time before heading to work.
Thank you so much for your help so far. Really appreciate it.
Click to expand...

You're welcome. Can you share your server.conf and client.ovpn files here? Do remove any 210.x address from it, leave private 192.168/10.8 addresses. Then we know which routes/DNS the server is trying to push towards the client.
Thanks & goodnight!
CC
 
You must log in or register to reply here.
Top Bottom