Tutorial Ultimate Guide to setting up Bi-Directional VPN using two Asus Routers via OpenVPN in TUN mode

[Ed B.]

The Ultimate Guide to setting up Bi-Directional VPN using two Asus Routers via OpenVPN in TUN mode - Part 1

This guide will help you connect two ASUS routers in Site To Site (also know as Point To Point) mode. I'm listing literally every step I take so you should be able to just follow along without thinking, then once you're VPN is up and running you can go back and make any changes needed and deal with the aftermath of angering Commciniculum, the Evil God of VPN, offspring of Sterculius and Kauket.

Step 1) Obtain two ASUS Routers. The ones I have worked with so far and really like are: GT-AX11000 (tested and works excellent as a Server, not tested as a Client but I think it would fail for the same reason as the GT-AC5300), GT-AC5300 (tested and works excellent as a Server, Fails as a Client because VPN Fusion does not set up Routes - I talk about this more in the 'Client' section below and I'm open to suggestions!), RT-AC86U (tested and works excellent as both a Server or Client), RT-AC3100 (tested and works excellent as both a Server or Client), RT-AC66U (Only tested as a client, but it works great for that)

Step 2) Reset routers (if not new) by holding down reset button during power on.

Step 3) Plug in the router you will be using as the Server-Side for the OpenVPN connection. From here on in I will refer to this router as the 'Server' or 'Server Router'.

Step 4) Use a laptop to connect to the Server's wifi (which will be unsecured if you successfully reset your router in step 2), or connect via a wired computer.

Step 5) In a browser window, open the Server's default IP Address, ex. 192.168.50.1 or 192.168.1.1 (If you can't open one of those, do a cmd->ipconfig to see what's listed as the Default Gateway.)

Step 6) Exit the setup wizard as fast as possible and get to the normal configuration pages.

• On a GT-AX11000 or GT-AC5300 (at the time of this writing) this means clicking: Advanced Settings -> Choose operation mode -> Wireless router mode -> 'No' for Internet username and password -> 'Automatic IP' for internet IP address -> uncheck 'Separate 2.4GHz and 5GHz', then enter 'ServerVPN' and a password, then click Apply -> enter a Login Name and password x2, click Next
  
  
• On an RT-AC86U or RT-AC3100 (at the time of this writing) this means clicking: Advanced Settings -> Choose operation mode -> Wireless router mode -> 'No' for Internet username and password -> 'Automatic IP' for internet IP address -> (uncheck 'Separate 2.4GHz and 5GHz' if checked), then enter 'ServerVPN' and a password, then click Apply -> enter a Login Name and password x2, click Next

Step 7) Close the 'AiMesh' popup window (if it appears) by clicking the 'x'

Step 8) Plug in the WAN side of the Server into your Cable Modem or other ISP (Internet Service Provider) device. Do any additional config required by your ISP to get your router online (WAN -> Internet Connection -> username, password, static IP, etc.)

Step 9) Administration -> Firmware Upgrade -> Check; then press the 'Firmware Upgrade' button if it appears. My firmwares, the latest versions at the time of this writing, are 3.0.0.4.384_5252-g66a5aae on the GT-AX11000, and 3.0.0.4.384_45149-g467037b on the GT-AC5300, RT-AC86U, and RT-AC3100.

Step 10) Set your internal (LAN-side) IP Address and subnet. The LAN side (including Wifi) of your router is currently set to something like 192.168.50.1 or 192.168.1.1 or whatever it is you've been using to connect in the web browser. You're going to have to make a choice here and decide if you want to change that. I changed it to 10.100.100.100 and 255.255.255.0, but you can choose any 'private' IP address that you like, or even just leave it as your current 192.168.x.x address. Just remember two things 1) whenever I refer to 10.100.100.100 I am referring to the Server's internal LAN-side IP address, so you'll need to translate my 10.100.100.100 to whatever number you enter here, and 2) THIS IS VERY IMPORTANT, every point-to-point Client Router that connects to your Server Router will need to be on a different subnet! This means that if you choose 192.168.50.1 and 255.255.255.0, your Server network will be using addresses from 192.168.50.1 - 192.168.50.255, so your Client Router will have to use something else that does not overlap, like 192.168.51.1 and 255.255.255.0. That's the whole point of a point-to-point or site-to-site tunnel - in OpenVPN this is the 'TUN' mode. We can have a whole conversation about connecting in TAP mode (and why you probably shouldn't) later.​

IMPORTANT: Once your change your LAN-side IP Address and subnet mask you will need to use that new IP Address to connect to your Server Router! Also, your router's DHCP, which has been assigning the IP address to your computer (or whatever device you're accessing your router from) will need to be allowed to update as well (but don't worry you'll be prompted for that). SO, pick an IP Address for your router and do the following (substituting in your IP Address for the 10.100.100.100):

Pick a 'Private' IP Address - it must start with "10.", or "192.168.", or "172.16.", etc. (use google to learn about private IP Addresses)
LAN -> LAN IP -> IP Address: 10.100.100.100 , Subnet Mask: 255.255.255.0 -> Apply -> You will get a popup saying "LAN IP address and subnet mask has changed. IP Pool of addresses should be updated. Would you like to update IP Pool of addresses automatically?" -> MAKE SURE YOU CLICK 'OK' !!!

Reconnect to your Server Router's Wifi (if needed), then log back into its web interface using it's new IP Address.​

 

[Ed B.]

The Ultimate Guide to setting up Bi-Directional VPN using two Asus Routers via OpenVPN in TUN mode - Part 2

And now for a brief interlude to talk about IP Addresses. In Part 1 I talked about setting my LAN side of the Server to 10.100.100.100 and 255.255.255.0 so let's talk about what that means since there may be different levels of expertise reading this. There is a massive amount on information on the web about subnets and how they work, and you should really go read about that if you're not 100% familiar with the topic. However, just in case you're not going to go do your homework, I'll make a few points which you MUST understand. Note that I am NOT a network administrator, and this is NOT meant to be too technical or perfect. It's meant to help someone who is just starting out with VPNs understand how all this crap works. Also, If any of these points are unclear to you, then you really should take the time to learn about mac addressses, IP addresses, gateways, routes and how they all work, even if a lot of it is confusing, just to get a basis. Anyhow here are the points. (Keep in mind this is for learning, so I'm outlining the simplest, most common, setup. And keep quiet all you smartie-pants, we all know it gets more complex than this. My point in outlining this is that a lot of people, like me, work with this stuff for a long time before really understanding it, and I want to hit all levels.)

- We'll start simple, your router has two IP Addresses, WAN and LAN. The WAN address is for the outside internet, the LAN address is the routers's internal IP address on your network. As far as the LAN goes, connecting via an ethernet cable or WiFi makes no difference, once you're connected you're attached to the LAN.

- On a new router your WAN address is not set since that will be up to your ISP, but your LAN address will be set to 192.168.1.1 or something like that.

- When you connect your WAN Port to your ISP's device (cable modem, FIOS box, whatever), your router asks for a WAN IP Address. Your ISP then assigns your router an IP address and subnet - this assignment is done using a technology called DHCP, which basically just means 'I don't have an IP address, so give me one!'. Also note that every IP Address must have an associated subnet, I'm sure you've seen that, and we'll get more into that in a minute. If all works properly, you will see the WAN IP address shown on the 'Network Map' page of your ASUS router. At the same time, your ISP tells your router a 'Gateway' address. This is the address that your router will pass requests to when it doesn't think they are local (like if you're looking for snbforums.com). It will also pass your router an address of a DNS Server. This is a server that you can use to ask questions about the IP address of a domain name. For instance, if you go to Network Tools -> Network Analysis -> Nslookup -> and type in snbforums.com, on the first line your will see the IP Address of the DNS Server your router is using (mine is 75.75.75.75 since I'm on comcast, 8.8.8.8 is google's famous one, etc.) and then later down in the results you will see 104.25.235.15 which is the IP Address of snbforums.com (at least at the time of this writeing anyhow).

- So how does your router know what's 'local' and what's not? For example, how did it know to go out to the internet to get to 8.8.8.8 to ask for snbforums.com's address? and how did it know to go out to the internet to get to 104.25.235.15? That's where the beauty of subnets and gateways comes in.

- Your subnet tells you what's local. Everything else gets passed to the gateway. So here's how you should think of it... Lets say we're the server router. We have a WAN IP of 171.22.22.54 255.255.255.252 with a gateway of 171.22.22.53 that was given to us by our ISP, and a LAN of 10.100.100.100 255.255.255.0 which we chose (there is no gateway on the LAN-side since we ARE the gateway for the LAN). The WAN's 255.255.255.252 is a bitmap that says the WAN side can be directly used for any IP addresses in the range 171.22.22.52 - 171.22.22.55 (I won't get into bitmaps here, but you should read up on it and understand it since it is both interesting and helpful. Otherwise just google 'subnet calculator' to figure out the range of IPs and note that these calculators will typically leave off the lowest and highest numbers since these are reserved (but in actuality often usable). I'm also not getting into how mac addresses work, but again this is something that should be googled and learned for fun.). The LAN's 255.255.255.0 bitmap says the LAN side can be directly used for any IP addresses in the range 10.100.100.0 - 10.100.100.255. Finally, the gateway is what's used for 'anything else' the server doesn't know what to do with. So basically, if the router has something to say to 171.22.22.52 - 171.22.22.55 the it sticks it out on the WAN port and hopes it gets picked up; if it has something to say to 10.100.100.0 - 10.100.100.255 it sticks it out on the LAN port and hopes it gets picked up; and if it has anything else, it packages it up and sends it to 171.22.22.53 (it's gateway). Note that once it's packaged up, it's easy to get it to 171.22.22.53 by simply dumping it out on the WAN port - you should see from this that our WAN IP must be in the same subnet as our gateway (since our WAN port can only talk to stuff that's in our subnet).

- You will see subnets referred to in 'shorthand' like this: 10.100.100.0/24 - the 10.100.100.0 refers to the start of the subnet and the 24 refers to the 24 "1's" in the 255.255.255.0 so together it shows that the subnet ranges from 10.100.100.0 - 10.100.100.255. Likewise, the 171.22.22.52 - 171.22.22.55 range could be written as 171.22.22.52/30. If you're not sure about any of this, Google!

- Everything we just talked about is referred to as 'Routing' and it's literally what a 'router' does. It takes a packet of info, looks at where it's going, and send it on its merry way.

- These 'Routes' are stored in a 'Routing Table'. You can see my Server and Client Routing Tables in my original post above. Let's break down the lines that refer to the stuff we just talked about using 'friendly' terms...

Destination Gateway Genmask Flags Metric Ref Use Type Iface
10.100.100.0 * 255.255.255.0 U 0 0 0 LAN br0
The '10.100.100.0' and '255.255.255.0' say that this line applies to anything from 10.100.100.0 - 10.100.100.255. The 'LAN' says to send it to the LAN side (br0 refers to a 'bridge' that connects the LAN Ports and Wifi). The '*' says to just dump it out there - it doesn't need to be packaged and shipped through a gateway since we expect stuff with 10.100.100.x numbers to be directly connected to our LAN Ports and Wifi.

Destination Gateway Genmask Flags Metric Ref Use Type Iface
171.22.22.0 * 255.255.248.0 U 0 0 0 WAN0 eth0
Ok, so these aren't exactly the numbers I gave in my original post or examples. That's because 171.22.22.54 isn't actually my IP address. I obfuscated (changed, made bogus) my IP address. But let's break down this line anyhow... The '171.22.22.0' and '255.255.248.0' says that this line applies to anything from 171.22.16.0 - 171.22.23.255 (we could write this as 171.22.16.0/21). The 'WAN0' says to send it to the WAN port (This router has the ability to use two WAN ports; I'm guessing that's why it's WAN0 instead of just WAN). The '*' says to just dump it out there on the WAN port - it doesn't need to be packaged and shipped through a gateway since we expect stuff with 171.22.16-23.x numbers to be directly connected to our WAN Port.

Destination Gateway Genmask Flags Metric Ref Use Type Iface
default 171.22.22.1 0.0.0.0 UG 0 0 0 WAN0 eth0
This line says "All the other crap I don't know what to do with should be packaged and sent to 171.22.22.1" 'WAN0' is listed, but technically we already know that 171.22.22.1 is on the WAN (from the line above).

Destination Gateway Genmask Flags Metric Ref Use Type Iface
171.22.22.1 * 255.255.255.255 UH 0 0 0 WAN0 eth0
This line says "Dump anything for 171.22.22.1 out on the WAN Port" Again, it seems superfluous since we already know that 171.22.22.1 is on the WAN (from the line two above).​

Ok, that's all for IP Addresses and stuff. Let's get back to our guide...

​

 

[Ed B.]

The Ultimate Guide to setting up Bi-Directional VPN using two Asus Routers via OpenVPN in TUN mode - Part 3

Step 11) WAN->Enable UPnP->NO->Apply (shouldn't matter for VPN, but that's how I set it)

Step 12) Next you need to set up a Dynamic DNS Entry (unless you have a static WAN IP from your ISP). A Dynamic DNS Entry is an entry maintained by someone else's DNS server (in this case ASUS's server). Your Server Router will continually update this entry with your WAN IP address (since it is sporadically changed by your ISP). It lets you advertise your router with a friendly name, like NegasonicTeenageWarhead.asuscomm.com and whenever your client router goes looking for that name, ASUS (more or less) provides it with your Server's current IP address so the client can find the server. So, pick a name and then...
WAN->DDNS->Set Enable the DDNS Client to Yes; Set Host Name to whatever name you chose ->Select 'None' for HTTPS/SSL Certificate->Accept->If a popup appears, check 'I am above the age of 16 years' and Accept

​

Step 13) WAN->NAT Passthrough->Set all dropdowns to 'Disable' and click Apply (shouldn't matter for VPN, but that's how I set it)

Step 14) Firewall->General->Set Enable DoS protection to 'Yes'->Apply (shouldn't matter for VPN, but that's how I set it)

Step 15) Administration->System->Set your timezone; Set 'DST time zone changes starts' to '3','2nd','Sun','2' ; Set 'DST time zone changes ends' to '11','1st','Sun','2' -> Apply (At least that's what it is for the US)

Step 16) Now to the fun stuff! VPN->VPN Server->OpenVPN->Set to 'On'-> Select '2048 bit'; Set 'Client will use VPN to access' to 'Local network only' -> Enter a username and password that your Client Router will use to connect. I chose 'Keyport' as the username for my client router -> Press the '+' to create the row (don't miss this step! The username and password fields should now be blank again!) -> click 'Apply'

Step 17) On the same page... VPN->VPN Server->OpenVPN->in the 'VPN Details' dropdown, select 'Advanced Settings'->

• Interface Type:TUN
• Protocol:UDP
• Server Port:36974 <- Here you MUST PICK A PORT THAT YOUR ISP ALLOWS!!! All I can say is that Comcast (XFinity) in NJ allows this port.
• Respond to DNS:No <-You may want to change this later
• Encryption cipher: AES-128-CBC
• HMAC Authentication: SHA 1
• Compression: Adaptive
• Username / Password Auth. Only:Yes
• Authorization Mode:TLS
• RSA Encryption:2048 bit
• Extra HMAC authorization: Disable
• VPN Subnet / Netmask:10.1.2.0 and 255.255.255.0 <- you can pick a different subnet here if you like, but you may want to use what I chose for consistency since it really doesn't matter
• Push LAN to clients:Yes <- I think this lets the client router know that it needs to router 10.100.100.x stuff through the VPN tunnel
• Direct clients to redirect Internet traffic:No <- I prefer that my client router use it's own internet connection for internet stuff (like google.com, etc.), instead of sending all of the internet requests from its network through the VPN for my server to handle
• TLS Renegotiation Time:-1 <- I think the -1 here forces the VPN channel to be reestablished every hour. Maybe I should up this, or set it to 0 to disable renegotiation?
• Manage Client-Specific Options:Yes
• Allow Client <-> Client:Yes <- Even though this is set to 'Yes', my Client VPNs can't talk to each other yet (but they can talk to the server, and the server can talk to each of them.) My next task is to see if I can add manual routes to let the client VPNs talk to each other.
• Allow only specified clients:Yes <- This makes it so that only clients manually added to the 'Allowed Clients' list are allowed to connect to the VPN. I'm not sure if this is necessary, but I set it to yes since we need to make sure each client has an entry in 'Allowed Clients' anyway, since that's where we specify each client's subnet (which lets the Server know where to find them!)
• In 'Allowed Clients' enter a Common Name for the Client Router. The Common Name must match the Username you specified in the prior step (back when the 'VPN Details' dropdown was set to 'General'). At least I think these should match, I've never tried it differently.
  Enter a subnet and mask for the Client Router. This MUST NOT OVERLAP WITH THE SERVER ROUTER'S IP ADDRESS since the whole point of routing is that the server router recognizes the requests going to the client router's addresses and sends them across the VPN tunnel. If the client and server were in the same subnet, then the routers wouldn't know if addresses in their subnet were local or remote across the VPN tunnel.
  I entered 'Keyport' to match my username from the basic settings, and I set the Subnet to 10.100.101.0 and the Mask to 255.255.255.0 so all of my client router's lan ips will be in the 10.100.101.0 - 10.100.101.255 range.
  Set 'Push' to 'No'!!! Frankly, I'm not sure why Push has to be set to No, but I believe it was the cause of my original problem and setting it to yes will prevent the Server from accessing the Client Router's LAN.
  Make sure you click the '+' button after making your entry, then click Apply.
• Note that no 'Custom Configuration' is necessary at this point.

Step 18) VPN->VPN Server->OpenVPN->'Export OpenVPN configuration file'->Export <-Save the file since you'll need to import it into your Client Router

Step 19) Edit the .ovpn file you just saved and make sure of the following:

1. the first line should read "remote [yourname].asuscomm.com [yourport]" where [yourname] and [yourport] are the entries you specified back in step 12. (or change [yourname].asuscomm.com to your static IP if you pay for a static WAN IP from your ISP)
2. Make sure you have lines for "dev tun" and "proto udp"
3. Screw this line by line thing, just make sure everything above the "<ca>" line looks like this:
   remote [yourname].asuscomm.com [yourport]
   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-----
   
   
4. Don't change anything below the "<ca>" - there should be an entry for a <ca>, a <cert>, and a <key>
   
5. save the file, you'll import it into you Client Router in a bit

Step 20) Check that your asuscomm.com DDNS entry is working properly by:

1. cmd->ping [yourname].asuscomm.com
2. https://www.whatismyip.com/
3. make sure the above two match

THAT'S ALL FOR THE SERVER!

 

[Ed B.]

The Ultimate Guide to setting up Bi-Directional VPN using two Asus Routers via OpenVPN in TUN mode - Part 4

Step 21) Now for the Client... Note I have NOT been able to get the GT-AC5300 to work as a client - I can get it to connect, but I can't ping successfully in both directions due to the fact that VPN Fusion does not automatically set up routes properly, and manually adding the routes has not worked either. I expect the GT-AX11000 and any other 'VPN Fusion' router would have the same issue, so for now, stick to the 'normal' line of ASUS routers. I believe only 'GT-' routers have VPN Fusion, so any recent Asus router that starts with 'RT-' should work fine as a Client.
Note that in the steps below I'll still break out the steps for configuring an ASUS Router that has VPN Fusion, and I'll point out where things go awry so people can suggest a way to fix it.

Step 22) Plug in the router you will be using as the Client-Side for the OpenVPN connection. From here on in I will refer to this router as the 'Client' or 'Client Router'.

Step 23) Use a laptop to connect to the Client's wifi (which will be unsecured if you successfully reset your router in step 2), or connect via a wired computer.

Step 24) In a browser window, open the Client's default IP Address, ex. 192.168.50.1 or 192.168.1.1 (If you can't open one of those, do a cmd->ipconfig to see what's listed as the Default Gateway.)

Step 25) Exit the setup wizard as fast as possible and get to the normal configuration pages (see step 6 above).

Step 26) Plug in the WAN side of the Client into your Cable Modem or other ISP (Internet Service Provider) device. NOTE THAT THIS MUST BE A DIFFERENT INTERNET CONNECTION THAN THE SERVER. If you don't have two internet connections available, then it is 'possible' to trick the routers into thinking they are connected to an internet, even though they aren't - I won't get into it, but if you're going to try this, just beware that things like DDNS will give you trouble, and you'd be better off MacGyvering up another connection through yet another router and your phone's mobile hotspot.
Do any additional config required by your ISP to get your client router online (WAN -> Internet Connection -> username, password, static IP, etc.)

Step 27) Administration -> Firmware Upgrade -> Check; then press the 'Firmware Upgrade' button if it appears. The firmwares I tested are listed in step 9 above.

Step 28) Set your internal (LAN-side) IP Address and subnet. This MUST BE THE SUBNET YOU SET ON THE SERVER BACK IN STEP 17! So, if in step 17 you picked 10.100.101.100 and 255.255.255.0 as the subnet, then you must set your client's IP address to something like 10.100.101.1 or 10.100.101.100 - I set mine to 10.100.101.100 and the subnet should match also, so enter 255.255.255.0 for the Subnet Mask. And of course, if you picked a different number than me, keep in mind that whenever I refer to 10.100.101.100 I am referring to the Client's internal LAN-side IP address, so you'll need to translate my 10.100.101.100 to whatever number you entered here. And AGAIN, your Client Router's subnet cannot overlap with your Server Router's subnet, so you'll notice that my Server Router's subnet is 10.100.100.0/24 (10.100.100.0-10.100.100.255 255.255.255.0) and my Client Router's subnet is 10.100.101.0/24 (10.100.101.0-10.100.101.255 255.255.255.0) so there is no overlap. These must also be 'Private' IP Address - it must start with "10.", or "192.168.", or "172.16.", etc.

IMPORTANT: Once your change your LAN-side IP Address and Subnet you will need to use that new IP Address to connect to your Client Router! Also, your router's DHCP, which has been assigning the IP address to your computer (or whatever device you're accessing your router from) will need to be allowed to update as well!!! SO, do the following (substituting in your IP Address for the 10.100.101.100):

LAN -> LAN IP -> IP Address: 10.100.101.100 , Subnet Mask: 255.255.255.0 -> Apply -> You will get a popup saying "LAN IP address and subnet mask has changed. IP Pool of addresses should be updated. Would you like to update IP Pool of addresses automatically?" -> MAKE SURE YOU CLICK 'OK' !!!

Reconnect to your Client Router's Wifi (if needed), then log back into its web interface using it's new IP Address.​

Step 29) WAN->Enable UPnP->NO->Apply (shouldn't matter for VPN, but that's how I set it)

Step 30) WAN->NAT Passthrough->Set all dropdowns to 'Disable' and click Apply (shouldn't matter for VPN, but that's how I set it)

Step 31) Firewall->General->Set Enable DoS protection to 'Yes'->Apply (shouldn't matter for VPN, but that's how I set it)

Step 32) Administration->System->Set your timezone; Set 'DST time zone changes starts' to '3','2nd','Sun','2' ; Set 'DST time zone changes ends' to '11','1st','Sun','2' -> Apply (At least that's what it is for the US)

Step 33) Network Tools->Network Analysis->Ping,[yourname].asuscomm.com,1,Diagnose -> make sure it resolves to the same IP Address you saw in step 20. But don't expect the ping to actually work since we did not set your Server Router to respond to pings on the WAN.

Step 34) Now to the fun stuff!

For ASUS routers without VPN Fusion (ex. RT-AC5300, RT-AC86U, RT-AC3100, RT-AC66U): VPN->VPN Client->Add Profile->OpenVPN->Enter a Description (I entered "ToHome"), enter the username and password from Step 16, click 'choose file' and browse to the file your modified and saved in Step 19, click Upload -> MAKE SURE IT SAYS 'Complete' NEXT TO THE UPDATE BUTTON-> Click OK -> Click Activate
For ASUS routers with VPN Fusion (ex. GT-AX11000, GT-AC5300): VPN->VPN Fusion->Click the '+' next to "Server List ( Max Limit : 16)" ->OpenVPN->Enter a Description (I entered "ToHome"), enter the username and password from Step 16, click 'choose file' and browse to the file your modified and saved in Step 19, click Upload -> MAKE SURE IT SAYS 'Complete' NEXT TO THE UPDATE BUTTON-> Click OK -> Click the '-' in the activate column to activate the VPN​

Step 35)

Step 36) Hopefully your VPN Connected, but chances are it didn't. Your next step is to reset your VPN, don't worry this is very easy. At the bottom of this post is a section called "HOW TO PREPARE AND POST YOUR LOGS IF YOUR VPN IS FAILING:". Follow those steps EXACTLY IN ORDER. If you've done everything in this guide, and then performed those steps (which include stopping and restarting your VPN Client and Server), and you still can't connect, then post your logs and hopefully people can help. I'll try to monitor this thread, but I do get busy with work and kids.

Step 37) If by some miracle your VPN is now connected, STOP and do the following:

1. Verbally thank Commciniculum!
   
   
2. Create an account on snbforums.com and let me know it worked <- This is REALLY important and only takes a minute, but lets me know I did a good job and if I need to change anything. It took me a lot of life to learn this stuff, many days to test and debug, many hours testing across multiple routers, documenting in this post, etc. I just need to know if it's still working (or if ASUS made changes that I need to incorporate). Also, if you don't reply to this thread, you will anger Commciniculum who will put a curse on your VPN, causing disconnects, maybe causing you to be hacked, or worst of all, forcing you to use TAP.
   
   
3. Did you leave a reply yet? Seriously, click 'Post Reply' below and type 'It worked'. Don't piss off Commciniculum.

Step 38) SKIP THIS STEP FOR MOST ASUS ROUTERS (If you click 'VPN' and there is no tab named 'VPN Fusion', then you should skip this step!) For VPN Fusion Routers ONLY: There is a problem with routers that have VPN Fusion - they do not automatically create routes back to the Server when they connect to VPN. We need to manually set up those routes. BUT I HAVE NOT BEEN ABLE TO!

I have tried the following unsuccessfully:

1) LAN -> Routes -> 'Enable static routes' -> Yes -> Apply
2) LAN -> Routes -> Add a static routes with the following options:
Network/Host IP Netmask Gateway Metric Interface
10.1.2.0 255.255.255.0 10.1.2.??? 0 MAN <- I tried LAN/MAN/WAN
10.100.100.0 255.255.255.0 10.1.2.??? 500 MAN <- I tried LAN/MAN/WAN
3) None of the routes I created show up in "System Log -> Routing Table", and I'm not able to ping from Client to Server, or from Server to Client​

Step 39) Test the 2-way communications (assuming you're not a VPN Fusion router):

1) On the Client: Network Tools->Network Analysis->Ping,10.100.100.100,1,Diagnose
2) On the Server: Network Tools->Network Analysis->Ping,10.100.101.100,1,Diagnose
3) On a computer connected to the client "ping 10.100.100.100
4) On a computer connected to the server "ping 10.100.101.100
5) From 'computer connected to client' to 'computer connected to server' (ipconfig to find ip addresses, then ping)
6) From 'computer connected to server' to 'computer connected to client' (ipconfig to find ip addresses, then ping)​

Step 40) If all of those pings worked, please click 'Post Reply' and let me know. Or if you need help, post your logs (see 'HOW TO PREPARE AND POST YOUR LOGS IF YOUR VPN IS FAILING' below).​

 

[Ed B.]

The Ultimate Guide to setting up Bi-Directional VPN using two Asus Routers via OpenVPN in TUN mode - Part 5

Additional Notes:

- If you had to make any changes to the above script to get things working, please click 'post reply' and let me know!!!
- If any of my config could be better (more secure, other configs you like, etc.) please let me know
- I'm particularly interested in keeping the VPN secure, but FAST, since I use them for massive data transfer (real-time video streaming for home security cameras, backing up 10TB+ of data, etc.)
- Please refrain from commenting on my explanation of DNS/DHCP/Mac Addrs/IPs/subnets/gateways/routes/etc. As I mentioned it is intentionally simplified so anyone can pick it up and learn. But do let me know if I said anything grossly wrong.
- If you get this working on a different router, please post the router type and firmware level (for both client and server)
- I'm happy to review your server and client logs if I have time, but to make it clear for me (and let me respond faster), please follow these steps:​

HOW TO PREPARE AND POST YOUR LOGS IF YOUR VPN IS FAILING:

1. On the Client
   1. VPN -> VPN Client -> Deactivate
2. On the Server
   1. VPN -> VPN Server -> Open VPN -> On -> VPN Details -> Advanced Settings -> Write down your username, subnet, and mask values
   2. VPN -> VPN Server -> Open VPN -> Off -> Apply
   3. System Log-> General Log -> Clear
   4. VPN -> VPN Server -> Open VPN -> On -> VPN Details -> Advanced Settings -> Allowed Clients -> reenter values for your username, subnet, mask, push=No -> click '+' -> click Apply
3. On the Client
   1. System Log-> General Log -> Clear
      
   2. VPN -> VPN Client -> Activate
   3. Wait a moment
   4. Post the following Client items:
      - Screenprint:
      - Text: System Log -> General Log
      - Text: System Log -> Routing Table
4. On the Server
   1. Post the following Server items:
      - Screenprint: VPN -> VPN Server -> Open VPN -> On -> VPN Details -> Advanced Settings
      - Text: System Log -> General Log
      - Text: System Log -> Routing Table
5. You may choose to obfuscate your mac addresses and external IP Addresses by doing a global find/replace, but please do not change your internal (private 10. 192. 172.) values since there's no point in that, also do NOT change your subnet mask entries (those 255.255.255.0 things). Also, in the client log there are a couple of hash values that look like this: Local Options hash VER=V4: '61373c79', so you may want to search for the word 'hash' and X-out those values.
6. DO NOT POST YOUR .ovpn FILE! IT HAS YOUR SECRET KEYS IN IT!
7. Also, it's cleaner if you wrap your Logs and Routing Tables in
   brackets by clicking the 'Insert->Code' icon in the ribbon bar (just to the left of the little save floppy disk icon).

 

[Ed B.]

The Ultimate Guide to setting up Bi-Directional VPN using two Asus Routers via OpenVPN in TUN mode - Addendum 1 - Using your own DCHP Server

Ok, so using your own DHCP isn't really a big deal and doesn't really warrant its own section, however it's a good prelude to 'Addendum 2', which will be about using your own DNS server (which is necessary for people running their own Windows Domain). Plus, there are still a few key points to think about if you're going to use an external DHCP Server outside of your router, and while they seem pretty obvious, it's worth mentioning them just in case...

1. Your external DHCP server must be connected to your router's LAN. (I know, I know, I said these would be obvious!)
2. You can use an external DHCP connected to your Server Router's network. You can use another external DHCP connected to your Client Router's network. You CAN'T expect devices connecting to your Client Router to tunnel through the VPN to get an IP Address from the DHCP Server that's connected to your Server Router (or vice versa).
   Please skip over this paragraph if you're not sure what TUN vs TAP is. I may write a guide on TAP at a later time if people are asking about it: Note that you could reach across the VPN tunnel for DHCP requests if the VPN was in TAP mode, but this guide is only about TUN mode. In order to do tunneling you have to send a packet to your gateway (which is your Client Router's IP Address) where it can be repackaged into a new IP Address and shipped across the tunnel. This implies that you already need to have an IP Address assigned (so you can't go reach across the VPN Tunnel to get one). Also, note that while you 'can' use a DHCP server across the VPN Tunnel in TAP mode, it's really putting a lot of faith in the VPN Tunnel being 'always up' - otherwise your computer won't get an IP Address assigned and you'll end up having to manually assign it an IP address, even just to open your Client Router's GUI to try and reestablish the VPN link. Therefore it's better to have DHCP servers on both sides of the VPN tunnel (regardless of whether we're in TAP or TUN mode). But keep in mind that in TAP mode (in general) you would want the two DHCP Servers to server up different sets of IP Address, but those IP Addresses would be in the same subnet. In TUN mode you need the two DHCP Servers to be completely different subnets (they should be the subnets you determined for the Server Router and Client Router when you were walking through the Guide in Steps 10 and 28).
3. When you connect your external DHCP Server to your router, make sure to turn off the router's DHCP server (LAN->DHCP Server->Enable the DHCP Server: No->Apply). I'm assuming you're connecting an external DHCP Server because that's what you want to use for serving up addresses, not your router anymore.
4. Your Server Router and Client Router should still have the same LAN IP Addresses and subnets that you chose in Steps 10 and 28 of the Guide.
5. Your external DHCP server must server up IP Addresses that are within the same subnet as your router's LAN IP Address. (In my examples I use 10.100.100.100/24 for my Server Router, and 10.100.101.100/24 for my Client Router. So the external DHCP server connected to my Server Router must serve up addresses between 10.100.100.1-255, and the other external DHCP server (if I had one) connected to my Client Router must serve up addresses between 10.100.101.1-255).
6. If your router's LAN IP Address is within the range of addresses served up by your external DHCP server, don't forget to add an exclusion to make sure your external DHCP server doesn't serve up the router's IP Address to someone else.
7. Your external DHCP server must serve up a Gateway IP Address, which is the router's IP Address. (in my examples the external DHCP server connected to my Server Router must serve up a Gateway Address of 10.100.100.100, and the other external DHCP server (if I had one) connected to my Client Router must serve up a Gateway Address of 10.100.101.100)
8. Your external DHCP server must serve up a DNS Server IP Address. This will really depend on your setup, but some options are: 1) the local IP Address of your own DNS Server that's on your local network (which could be the same server as your new external DHCP server), 2) the IP Address of your ISP's DNS Server (for me that's comcast's 75.75.75.75), 3) the IP Address of your Google's DNS Server (8.8.8.8), 4) the IP address of your router. Option #4 is ESPECIALLY IMPORTANT if you want your remote client network to use a DNS server that resides across the VPN connection (for example, attached to your server router's network) - telling the devices on your client network to use the client router as the DNS will allow the client router to make decisions on what to do depending on if the VPN tunnel is up or down, this is explained in 'Addendum 2' below.
9. If you are running your own DNS server, and you expect your DNS server to resolve the IP Addresses of devices that have been assigned IP's from your external DHCP server, then your DHCP Server must communicate those IP's to your DNS Server by creating/updating entries (A records?) in your DNS server each time it hands out a new IP Address.

​

 

[Ed B.]

The Ultimate Guide to setting up Bi-Directional VPN using two Asus Routers via OpenVPN in TUN mode - Addendum 2 - Using your own DNS Server (Part 1 - Background and Setup)

Ok, so you run a local DNS server on your Server LAN, Client LAN, or Both and you want to know how to set things up so you can use your DNS server(s) from across the VPN tunnel. Maybe you're even having issues where things work, then don't work, when the VPN connection is up or down. This Addendum's got you covered!

First off, if you're running local DNS Servers on both the Server and Client LANs, then all is good, just point server network stuff to its local DNS Server, point client network stuff to its local DNS Server, set up replication between the two DNS Servers so they replicate whenever the VPN tunnel is up, and you're good to go. (We'll trust that you set your DNS Servers up properly to allow DHCP to make entries, that you have correct forwarders set, etc.)

However, if you're running only ONE DNS Server, which we'll assume is on your Server's LAN, and you want your Client stuff to access it when the VPN is up, then read on...

Note that if you're running only one DNS Server and it's on your Client's LAN, and you want your Server stuff to use that DNS Server when the VPN is up, then this addendum will not work for you (since the 'switchover' to using a DNS Server 'across the VPN' verses 'out on the Internet' is triggered for a Client at the time when it connects). Your best bet is to delete the VPN configuration from both your Server and Client routers, then start over from the beginning of the Guide using your Client Router as the Server and your Server Router as the Client - your former client router is now running as the VPN Server and the former server router is connecting to it. This should go pretty quick and hey, luckily someone made you a handy Guide to follow!

So, now you're running only ONE DNS Server, and it's on your Server's LAN. And let's say your Server's LAN is in the 10.100.100.x range (the same 10.100.100.0/24 range I've been using throughout the Guide). Wait... I feel a prediction coming on... The VPN Gods are speaking to me... They say you're also running a full domain on your Server's LAN! Whoah, creepy! Now they're saying that you have Windows Pro computers on the Server's LAN that log into your domain. The VPN Gods are also saying that you're running your DHCP server separately off of your router. They say that your DHCP Server is set up to feed IP addresses to your DNS Server properly. They're saying you want to ping friendly names for the devices attached to your server network. And now the VPN Gods are telling me that you want your client network's devices to be able to use the DNS server on the Server's LAN side whenever the VPN connects. Whoah, now that's creepy - I told you, don't mess with Commciniculum! Let's do an example, we'll assume your Domain Server is also your DNS and DHCP server, and we'll call its IP Address 10.100.100.200 and we'll say that it's connected directly (or through a switch) to your 10.100.100.100 Server Router. We'll say the domain is named mydomain.com and the 10.100.100.200 server is named S0, and thus S0.mydomain.com is its fully qualified domain name (FQDN). We'll add on a laptop EL, a desktop ED, another laptop ML, etc.

A big point here is that if you're using a device attached to the Server's 10.100.100.x network, there is an expectation that you can "ping EL" from that device and it will retrieve the IP Address of the EL laptop, and then ping that IP Address. EL sporadically changes its IP Address due to the fact that it obtains it's IP address via DHCP (from the 10.100.100.200 S0 server) whenever it connects. So, when devices connect, we expect the DHCP server to 1) give an IP Address like 10.100.100.x, 2) give a subnet mask of 255.255.255.0, 3) give a Gateway address of 10.100.100.100, 4) give a DNS address of 10.100.100.200, and 5) update the DNS server with the device's name and corresponding IP address <--- The last two points are key to allowing devices to ping 'friendly names' like EL, ED, ML, etc. since #5 makes sure your DNS know's what IP addresses everyone is using and #4 makes sure everyone uses your local DNS Server to get that information.

So, assuming you have a computer running windows 10 pro that is attached to the "mydomain.com" domain, whenever the computer pings something local, it first attaches ".mydomain.com" to the friendly name, making it "EL.mydomain.com". It then hits S0 with a DNS request for "EL.mydomain.com". The S0 DNS server sees that it knows an IP address for "EL.mydomain.com". (The IP address was fed to S0's DNS server by the DHCP server at the time the DHCP server gave the temporary IP to EL.) The S0 DNS server then passes EL's 10.100.100.x IP Address back to the computer, and the computer pings EL's 10.100.100.x address and gets a response.

The point of the above paragraph is to understand that if the computer did not use 10.100.100.200 as the DNS server, and instead used something like Google's 8.8.8.8 DNS server, it would not get back a 10.100.100.x address for EL.mydomain.com. Instead Google's 8.8.8.8 DNS server might return the public IP address for "mydomain.com" (which is 65.254.242.180 at the time of this writing), or instead it may return an error since really there is no entry for "EL.mydomain.com" on Google's 8.8.8.8 DNS server (it only has an entry for "mydomain.com", not "EL.mydomain.com").
Also note that the S0 DNS server should use 'forwarders' to find out addresses it doesn't know. So if a computer hits it up asking for an address for "www.snbforums.com", then S0 goes out to Google's 8.8.8.8 (or Comcast's 75.75.75.75, etc.) DNS server, obtains the 104.25.235.15 address for "www.snbforums.com" and passes that address back to the computer. All of this happens instantly (as it does all over the web, every time you go to any website).

So this leads me to my VPN point...

When Client Routers are connected, I do NOT want them to send all of their VPN traffic through the VPN and out to the internet through the 10.100.100.100 Server Router. However, when they are connected, I DO want them to send all of their DNS requests across the VPN to the 10.100.100.200 DNS server that is attached to the 10.100.100.100 Server Router. Also, when they are NOT connected, they will have to fall back to using Google's 8.8.8.8 (or Comcast's 75.75.75.75) DNS server. The goal is for the Client Router to obtain an internal address for "EL.mydomain.com" from S0's DNS when it is connected to the VPN, but still be able to resolve sites like "www.snbforums.com" when it is NOT connected to the VPN by using Google's 8.8.8.8 DNS Server. Furthermore, computers connected to the Client Router should be able to obtain an internal address for "EL.mydomain.com" when the Client Router is connected to the VPN, but should also be able to resolve other sites when the Client Router is not connected to VPN.

Note that using the original setup in my Guide above, when connected to VPN your Client Routers will 1) send their internet traffic to their WAN (not across the VPN), and 2) send their DNS requests to their WAN to whatever is set as their WAN's DNS Server (this was assigned dynamically by your ISP, or statically by you). You can check this by connecting your Client to VPN, then going to Network Tools -> Network Analysis -> Nslookup -> Target: www.snbforums.com -> Diagnose. The first two lines of the results will show what your router is using as its DNS server. In my case, it's showing 75.75.75.75 which is Comcast's DNS Server - But I want it to use the 10.100.100.200 DNS Server since I'm connected to VPN!

To fix this let's modify the ovpn file that we edited back in Step 19 of the Guide. If you need to export the .ovpn file again, you can do that using VPN->VPN Server->OpenVPN->'Export OpenVPN configuration file'->Export, but remember to make all of the modifications from Step 19 afterwards!

The additional change we want to make is:

dhcp-option DNS 10.100.100.200​

This line tells the Client Router to use 10.100.100.200 for DNS requests ONLY WHEN IT'S CONNECTED TO VPN. When it's not connected to VPN it will continue to use the DNS Server that's set in its WAN.

I added this line into my ovpn file above the 'verb 5' line, so that part of the file now looks like this:

.
.
.
client
auth SHA1
cipher AES-128-CBC
ns-cert-type server

dhcp-option DNS 10.100.100.200

verb 5
<ca>
.
.
.​

Once the file is modified, you'll have to load it into your Client Router, so do the following:

1) VPN->VPN Client->Deactivate
2) VPN->VPN Client->Press '-' to delete the entry->Press 'OK'
3) Follow Steps 34 - 40 from the Guide
​

 

[Ed B.]

The Ultimate Guide to setting up Bi-Directional VPN using two Asus Routers via OpenVPN in TUN mode - Addendum 2 - Using your own DNS Server (Part 2 - Testing)

Once you've loaded the updated .ovpn file into your Client, and your VPN is back up, test the setup by doing the following:

1) Drop your Client Router off of VPN (VPN->VPN Client->Deactivate)
2) Network Tools -> Network Analysis -> Nslookup -> Target: www.snbforums.com -> Diagnose. The first line should show the DNS Server assigned to your WAN (the one dynamically assigned by your ISP, or statically assigned by you)
3) Connnect your Client Router to the VPN (VPN->VPN Client->Activate)
4) Network Tools -> Network Analysis -> Nslookup -> Target: www.snbforums.com -> Diagnose. The first line should show now show your internal DNS Server (the one you set in the 'dhcp-option' line in the ovpn file)
5) Network Tools -> Network Analysis -> Nslookup -> Target: [something only your internal dns server would know (but make sure it's a fully qualified name, like 'EL.mydomain.com' instead of just 'EL')] -> Diagnose. The first line should show show your internal DNS Server, later in the results it should show the IP Address that your internal DNS resolved. For instance, my 'EL.mydomain.com' resolved to 10.100.100.30, which only my internal DNS server would have provided.​

If that's all working, the next step is to see if a computer attached to your Client Router works also. You'll need to make sure the computer obtains an IP address from the Client Router (or external DHCP server attached to the client router). For me, the client router is 10.100.101.100 and IP config shows that my computer is at 10.100.101.199 with a Gateway of 10.100.101.100 and a DNS Server of 10.100.101.100, which is super important since it means that my computer is going to be looking to the Client Router to process all of its DNS requests! With any luck, if the Client Router is connected to VPN it will take the computer's request and forward it to the internal DNS server (10.100.100.200) and if it's not connected to VPN it will take the computer's request and forward it to the WAN's DNS entry (Google's 8.8.8.8, etc.). So test it all by doing the following:

1) Attach a computer to your client router, either through WiFi or ethernet cable.
2) On the computer (assuming it's a windows PC) do a cmd -> ipconfig /all
- Make sure your Computer's IP Address and Subnet Mask match your Client Router
- Make sure your Computer's Default Gateway Address is the Client Router's LAN Address
- Make sure your Computer's DNS Server Address is the Client Router's LAN Address
4) Disconnect the Client Router from VPN (VPN->VPN Client->Deactivate)
5) On the computer ping something on the web (ex. "www.snbforums.com"), it should ping ok
6) On the computer ping something internal (for me, that was "EL.mydomain.com"), it should NOT ping ok, or at least if it does ping it should return a non-internal number (ex. it might return the public IP Address of "mydomain.com"). This failure is expected since your client router is disconnected from the VPN, so it used the DNS from it's WAN.
7) Connect the Client Router to the VPN (VPN->VPN Client->Activate)
8) On the computer, flush the computer's DNS entries to force it to have to ask the DNS server for the IP Addresses again. (ipconfig /flushdns)
8) On the computer ping something on the web (ex. "www.snbforums.com"), it should ping ok
9) On the computer ping something internal (for me, that was "EL.mydomain.com"), it should now ping ok and return its internal address (for me, that was 10.100.100.30). Note that it could only have gotten this internal address from your internal DNS Server, so everything is working properly.

​

 

[coxhaus]

A network drawing would be nice.

 

[Ed B.]

The Ultimate Guide to setting up Bi-Directional VPN using two Asus Routers via OpenVPN in TUN mode - Parts 1-5 - Images

This thread was split off from another thread, so the images were still back over there. Here they are.

Note that all of the following images are the results after performing all steps in the main Guide (Parts 1-5, Steps 1-40). These do NOT include the Addendums, since those are specific to each person's particular situation.


Here is an image showing the Server's Configuration:

Here is an image showing the Client's Configuration:

The final .ovpn file with the domain name, certificates, and keys XXXXXX's out:

remote XXXXXX.asuscomm.com 36974
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-----
XXXXXX
-----END CERTIFICATE-----

</ca>

<cert>
-----BEGIN CERTIFICATE-----
XXXXXX
-----END CERTIFICATE-----

</cert>

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

</key>

Log File from the Server showing successful connection:

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
Thursday at 6:18 PMEditDeleteReport#2Reply

The Server's Routing Table:

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

The Client's Routing Table:

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

The Pings showing it all works:

[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 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 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 [Client Router VPN - 10.1.2.6]:
  SUCCESS:  64 bytes from 10.1.2.6: seq=0 ttl=64 time=50.703 ms

[Server Router] to [Client Router IP]:
  SUCCESS:  64 bytes from 10.100.101.100: seq=0 ttl=64 time=51.078 ms

[Server Router] to [Computer attached to Client Router]:
  SUCCESS:  64 bytes from 10.100.101.1: seq=0 ttl=63 time=52.426 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

And the network drawing showing all of the main routes that exist outside of the tunnel, as well as the main iRoutes that exist within the VPN tunnel:

Enjoy and Good Luck!

 

[Klueless]

Wow. What a heroic effort! Thank you.

It might be useful if you mentioned why you deviate from the defaults when you do; especially if it meant the difference between working or not working. E.g.; you use RSA Encryption = 2048 rather than the default of 1024?

Tim Higgins played with OpenVPN back in 2014. Here's his report ==> https://www.smallnetbuilder.com/oth...nd-using-openvpn-on-asus-routers?limitstart=0

Myself I'm trying to go client PC to Asus Router Server. Similar issues. Will try stealing a couple of your ideas over the next few days. If things work I may try using the other Asus router as a client (rather than a single PC as a client). If not I may have to try TAP (bridge) instead of TUN (router)?

 

[Ed B.]

Wow. What a heroic effort! Thank you.

My pleasure, glad to give back.

It might be useful if you mentioned why you deviate from the defaults when you do; especially if it meant the difference between working or not working. E.g.; you use RSA Encryption = 2048 rather than the default of 1024?

For my scenario, I'm continually transmitting real-time security camera footage, and periodically transmitting hard drive backups. So I was looking for "the best security I can get without sacrificing throughput". My understanding is that the "RSA Encryption" setting is for the initial handshake and password/key exchange encoding, and the "Encryption Cipher" setting is for the ongoing packet encryption once the VPN is up. I really need someone to clarify that though!!! So, I set the RSA Encryption to the highest level, since it only occurs once, or at least really infrequently (it may be occurring every 3600 seconds, but that's negligible) . I set the "Encryption Cipher" to "AES-128-CBC" since it dictates the amount of processing needed to encrypt all packets ongoing, and I didn't want to bog down my server and client routers - there's a lot of video data for the client router, and there are multiple VPNs attached to the server router. Plus I'm much less concerned about someone grabbing one of my packets and brute force unencrypting "AES-128-CBC" to retrieve a packet of video data. I'm more concerned about someone unencrypting my keys or password and gaining access to my network. Again, for full transparency, I have't finished my homework in this area yet, so figure only 80% of what I'm saying here is accurate.
Anyhow, I'll go back and try to add some clarification wherever I deviate from the original settings, that's a good idea, thanks!

Myself I'm trying to go client PC to Asus Router Server. Similar issues. Will try stealing a couple of your ideas over the next few days. If things work I may try using the other Asus router as a client (rather than a single PC as a client). If not I may have to try TAP (bridge) instead of TUN (router)?

Here I've got you covered. Just follow the Guide up to Step 20. Then install the OpenVPN client onto your laptop, which can be found here: https://openvpn.net/community-downloads/ (I'm using version "2.4.6-I602"). Then just right click the OpenVPN icon in the notifications section of your taskbar and import the file you created in Step 19. It should work without any modifications needed, just give it the password you set up in Step 16. You could also log in using the admin username and password of your router if you want. Also, you may want to turn off "Allow Client <--> Client" and "Allow only specified clients" if you're only connecting with one laptop.

Once connected, your laptop should be able to ping items on the server network. I've also been able to ping the laptop from the server (and I believe from devices attached to the server). The OpenVPN client pops up a window with your computer's assigned IP Address (ex. 10.1.2.6) when it connects, so you have to ping that address. I've since changed my config so unfortunately I can't confirm how I had it set up. Also, if you're going to try to ping your laptop, you'll need to allows pings through the laptop's firewall (https://kb.iu.edu/d/aopy) - I know that's obvious, but it's still better to mention it.

One other thought... I have always used TAP in the past due to my utter failures in setting up router-to-router in TUN mode. My laptops have connected via TAP with no issues. I know that throughout the Guide, I've mentioned you should avoid using TAP, but in your scenario I think it would be better than TUN. If I was only connecting computers to the VPN, then I'd prefer TAP since being 'directly on the network' would allow my laptop to use the same 10.100.100.x IP address it always does, it would allow it to get that address from the DHCP server that's attached to my Server Router, the DHCP server would update my DNS server, this allows other computers on the network to ping my laptop using its friendly name, etc. Let me know if you go that route and I can post how I set it up.

Either way, let me know if you have any issues!

 

[Klueless]

Once connected, your laptop should be able to ping items on the server network.

That's where I'm stuck. From my client PC I can ping the printers on my server network, print to them and even log into them. What I can't do (yet) is ping my laptops, ping our database server or log into our database server.

If/when I get back to work I've since gleaned a couple things to try. I'm also going to try your 10.1.2.x idea just on the off chance there's something out there that doesn't like zero subnets. Maybe I'll get lucky.

RSA Encryption

Thanks for the explanation ... think I'll just leave mine at default. I'll probably disable compression while I'm at it. Maybe just the reboot will help.

If not I guess I might try port forwards. Or setting up my other Asus as a client network. Last resort TAP.

 

[doczenith1]

I see that you are using stock Asus firmware which I believe does not support the newer AES-128-GCM cipher (don't quote me but I think stock is using openvpn 2.3). Perhaps an alternate configuration method might include using Asuswrt-Merlin firmware which supports AES-128-GCM (I believe Asuswrt-Merlin is using openvpn 2.4). It is my understanding that higher throughput is achievable using the GCM cipher vs the CBC cipher. The configuration screen is similar on Asuswrt-Merlin.

 

[Klueless]

I'm not at work so going from my fading memory;

My goal is Asus Open VPN client router to Asus Open VPN server router using "TUN". In preparation I decided to go Open VPN PC client to Asus server router.

It works, kind of. When the laptop is onsite I see a bunch of stuff and can connect to our database server. When I take the laptop offsite and connect through Open VPN I can see "some" stuff, I can connect to "some" things but cannot see other things and cannot log into our database server.

The PC has the latest release of OpenVPN client and the Asus 86U is running current stock. I've used your guide (and others) to tweak my settings but to no avail.

I was about to try port forwarding but that seems a little silly? Or redundant?

So I'm thinking about trying "TAP" instead.

Let me know if you go that route (TAP) and I can post how I set it up.

I guess my first question, using TAP, can the client network still use a different private network address than the server network (as you recommended) in using TUN?

 

[RMerlin]

Check the firewalls on the systems you are unable to reach.

 

[Klueless]

Check the firewalls on the systems you are unable to reach.

Thanks. I'll look into that.

 

[Ed B.]

My goal is Asus Open VPN client router to Asus Open VPN server router using "TUN". In preparation I decided to go Open VPN PC client to Asus server router.

So I'm thinking about trying "TAP" instead.

TAP is definitely not the way to go if your long term goal is two Routers that are always up. I used to have to use TAP until I finally got this up and running. I tested the Guide with multiple ASUS routers so it really should work. Plus I've invested too much time in the Guide, so I really need to make sure it's right!

So, here are the debugging steps that I'd like you to try:

1. I agree with Merlin that checking the Firewalls is your first step. The simplest way (ideally), is to turn off the Firewall altogether while you test.
   
   
2. Your mention of 'printerS' (plural), 'laptopS' (plural), and a separate database server, is making me thing you're connecting to a decent sized network. You also mention 'logging into' the database server. So I'm guessing you're on a domain at work. If so, you need to use Addendum 2 above and add dhcp-option DNS 10.100.100.200 to your .ovpn, or push "dhcp-option DNS 10.100.100.200" to the Custom Configuration edit box on your Server Router. (obviously replace the 10.100.100.200 with your DNS server's IP Address). To test if the DNS is being picked up properly:
   
   1. Connect your laptop to your network without DNS. Do a cmd -> ipconfig /all
      Record your DNS Server Address
      Ping your DNS Server from your laptop to make sure it answers pings!
   2. Connect your laptop via VPN (using the .ovpn file that has the dhcp-option DNS [your IP] line in it, or having added push "dhcp-option DNS [your IP]" to your ASUS Router's OpenVPN Custom Configuration). Do a cmd -> ipconfig /all
      Make sure the DNS Server Address was picked up properly.
      Note that your Gateway may be blank - as long as you can ping your DNS Server it's all good (assuming your DNS Server answers pings!).

I just dropped my laptop off my wifi, connected to my cellphone's mobile hotspot, started a VPN tunnel to my Server Router (using my .ovpn file that has the dhcp-option line in it). An ipconfig shows my 'Wi-Fi' Adapter with the IP address my wireless carrier assigned, and the Gateway, DHCP, and DNS addresses of my wireless carrier. My 'Ethernet' adapter shows an IP address of 10.1.2.10, a BLANK Gateway, a DHCP Server of 10.1.2.9, and a DNS Server of 10.100.100.200 (which is the DNS Server / Domain Controller on my network). I was able to

1. ping 10.100.100.200, even though I'm not in its subnet! (The 10.1.2.x packets got routed through the Server router and I'm guessing they take on the Server Router's 10.100.100.x IP Address, but I'm not 100% sure on that?)
2. use SSMS on my laptop to connect to SQL Server on my database server (which is also my 10.100.100.200 domain controller). I was able to connect to it using just it's friendly 'S0' name.
3. do a 'switch user' on my laptop and log in as another user that has never used my laptop. <--- This test proves I'm attached to the domain since it was able to verify the other user's credentials.

If it's not working for you, can you please go back and make sure that every option on your router is exactly as it's shown in the Guide Steps 1-20; and that your .ovpn file is exactly as explained in Step 19 with the addition of the dhcp-option DNS [your IP] line explained in Addendum 2? If everything's set right and it still doesn't work, then follow the steps in Part 5 to post your 'cleaned and obfuscated' logs and I'll be happy to take a look.

 

[Klueless]

... checking the Firewalls is your first step

This looks promising. Didn't know there's a column for exposing yourself locally and another to expose yourself publicly. That matches with the symptoms I'm seeing. Hopefully it's as simple as that.

... decent sized network

About 15 users, a dozen PCs and about 30 devices all totaled. Client network is about half that.

... debugging steps that I'd like you to try

Sounds good to me. Thank you!

 

[Klueless]

As per suggestions I turned off the firewall but it still didn't work. Upon closer inspection she has three firewalls running (and I only turned off one) so I've more work to do. (Who runs three firewalls?)