HOW-TO: configure the OpenVPN client for AirVPN

Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking
Goto page 1, 2  Next
Author Message
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1444
Location: Appalachian mountains, USA

PostPosted: Tue Oct 29, 2019 20:52    Post subject: HOW-TO: configure the OpenVPN client for AirVPN Reply with quote
[This post will be edited as corrections and needed additions materialize.]

3 Oct 21: This post needs updating to make it compatible with OpenVPN 2.5, which has some different settings. The "OpenVPN Guides" sticky at the top of this forum has a link to OpenVPN 2.5 hints/pointers that will actually get you to the right answers pretty quickly. In particular, I suggest you set First Data Cipher to CHACHA20-POLY1305, Second Data Cipher to AES-256-GCM, Third Data Cipher and Encryption Cipher to AES-256-CBC. With those ciphers I am doing really well with MTU 1434 and mssfix 1406, but the why of those is a long story.

8 Sep 22: At https://airvpn.dev/forums/topic/26523-howto-setup-airvpn-on-dd-wrt-refreshed-guide/?do=findComment&comment=194007 I just posted my own GUI settings for OpenVPN to AirVPN (dd-wrt 49081 with OpenVPN version 2.5.6.) No verbosity this time, just settings, for those who are aaaaaalmost there!

I finally got around to figuring out how to configure dd-wrt's OpenVPN client for AirVPN. Even though I had had NordVPN configured for well over a year, reconfiguring for Air still required help from both the dd-wrt forums (thank you, @egc) and AirVPN staff, so I am sketching up this how-to in hopes of making it easier for others. I began this effort using AirVPN's posted 2015 dd-wrt setup guidance augmented by very helpful 2018 AirVPN forum posts "Howto: Setup airvpn on DD-WRT, refreshed guide" https://airvpn.org/forums/topic/26523-howto-setup-airvpn-on-dd-wrt-refreshed-gui by user Moat and "tls-crypt on DD-WRT: got it working!" https://airvpn.org/forums/topic/31320-tls-crypt-on-dd-wrt-got-it-working/ by user JamBam, but all these posts turned out to be significantly incomplete, so this how-to is much more detailed.

The AirVPN site is at https://airvpn.org/, a .org site rather than a .com site. (If you visit it at https://airvpn.org/?referred_by=483503 even once at any time before you sign up for an account, they'll give me credit for referring you. Your call.) Per their privacy policy, their site uses cookies only for login status, handling referrals, etc, i.e. their own internal management purposes. No third-party cookies or trackers. (NordVPN's main website, by contrast, accesses google-analytics.com.)

I seriously don't want to write an ad here, but by way of orientation as to why I went with Air, they were created by security techies with the priorities that suggests. They have a scary reputation as way complicated and not for beginners, but it's nothing that dd-wrt people will find stressful at all. Their privacy policy was what I wanted, they do not pay for reviews, their servers authenticate vpn connections with encryption certificates and keys rather than usernames and passwords, and they use unpublished certificates. They assert that the shared, published certificates used by most vpn firms are a security hole making those services "for the gullible." You can configure your router to access their servers using UDP or TCP and on any of several ports, with their default being UDP on port 443 (rather than the 1194 openvpn default). The point of using TCP on 443 instead, though it would cost you some speed and make you a bit conspicuous, would be to have your vpn traffic look to your internet provider exactly like https traffic. You can't easily block what you can't easily identify. I'll point out the very small changes to your dd-wrt config needed to move between UDP and TCP.

Their server network is not huge: 37 US servers for example. It's important that the number of servers be commensurate with the size of a vpn firm's client base, so that each server carries an appropriate load. They publish detailed server stats, so I can see that today I am on a server with about 100 active connections and handling, at the moment, roughly a 300 Mbps total in+out data rate out of a 1 Gbps capacity. Their individual servers are generally not listed in the public DNS system, so reverse lookups of the exit IPs don't easily point back to a vpn service. Servers have separate entry and exit IP addresses, making traffic analysis just a little harder. Their Android, Windows, Mac, and Linux apps are named "Eddie" rather than something with "VPN" in the name that could be a red flag in a border search. All these things to me point to thoughtfulness about security details rather than a strictly marketing approach that brags about having a zillion servers (with three users each).

But what kicked me into finally leaving Nord was a deadly combination of two factors. First, Nord required me to use fixed server choices in dd-wrt. There was no way to have Nord choose a good server for me on the fly. Second, Nord kept retiring servers, forcing me to repeatedly update my dd-wrt config and those of family members scattered across the country. I recently read -- unreliable online source -- that Nord is phasing out support of fixed configurations, like routers use, so things are apt to get worse from here. Constantly retiring servers and adding new ones is no problem for their own apps, of course, as those apps have access to a current server list at all times. Such problems went away with Air, because -- see below -- I can configure dd-wrt with an Air server name that is always mapped by DNS, when OpenVPN connects, into the IP address of a working, nonoverloaded server in the country (or continent) of my choice. I don't have to constantly reconfigure.

I have not tried the "Eddie" apps -- online reviews suggest Eddie is comprehensive rather than simpleminded -- but I have set up Air for an iPhone, however, and there's a story there. Air uses the OpenVPN protocols exclusively, because they feel they are the most secure. But licensing requirements for Apple's App store and Air's OpenVPN code library turn out to conflict such that Air cannot legally provide a custom iOS app for AirVPN. In effect, OpenVPN cannot be used in iOS except by the OpenVPN project's official app, OpenVPN Connect. Air does provide custom-generated config files for that app, and each such config enables a simple on/off switch to engage/disengage the vpn, but some now fairly ordinary nice features like exceptions to autoconnect for trusted wifi systems are not there. Mostly for the latter reason, I'm actually keeping Nord for the family's routine iPhone use even while moving the routers to Air, but I do have OpenVPN Connect set up for Air/TCP/443 on our iPhones for when we need to bypass vpn blocks. I'll walk through the setup process for iOS shortly in a followup post, as it has some nonintuitive steps.

I've used configurations developed as discussed here for four Linksys WRT1900ACSv2 routers, at different times on BS builds 39144, 40009, 40784, 41954, and 42926, but this approach should also apply if you have any fairly fast dd-wrt router with openvpn 2.4 or later. (Check your version in the vpn log or with openvpn --version in the CLI.)

With Air you have a choice of having the OpenVPN client use tls-auth or tls-crypt, but not both, when setting up the control channel. The difference is that tls-crypt encrypts the OpenVPN Control Channel the whole time the connection is maintained, while the older tls-auth only uses encryption during that channel's authorization step. Further, per Air staff, "tls-crypt is particularly good at bypassing different block types against OpenVPN. If combined with TCP and port 443, it is quite effective against most blocking techniques targeting OpenVPN and/or UDP." In fact, each Air server has four "Entry" IP addresses to which you can connect, two that support only tls-auth (entries 1 and 2) and two that support only tls-crypt (entries 3 and 4). This guide assumes you want to use tls-crypt, support for which is included in all fairly recent dd-wrt builds.

If your dd-wrt build is so old that your openvpn version precedes 2.4, you will not be able to use tls-crypt. In that case, you'll avoid the protocol-table lines mentioning tls-crypt, and you'll omit the 3 in server designators like us3.vpn.airdns.org below, as that 3 designates entry 3 for tls-crypt compatibility. Then you'll skip the configuration of the tls-crypt key below and will instead enter a tls-auth key in the Static Key window. People with modern builds, ignore this paragraph!

Don't be intimidated by the length of these notes. They are my attempt to be complete rather than brief, to create a single reference for dealing with AirVPN on dd-wrt. Just configuring a router is actually pretty simple once you know what to do. Here then are the steps.
  1. Be sure you have a dd-wrt config backup.

  2. Create an AirVPN account and subscribe. Short terms suitable for a quick tryout are available, but as usual with vpn services, the longer terms are the bargains.

  3. While logged into AirVPN, visit the AirVPN>ClientArea>Devices page. There will be table with one line, which specifies a "key" denoting a device you are presumably about to configure, in this case your router. It's a good idea, though not strictly required, to edit the leftmost field to give that key a name corresponding to your router in their system. This will make it easier to add another device (using another named key) later on if you decide to. These names are strictly internal to AirVPN. They are not visible externally. (See Configuring Multiple Routers Or iOS Devices below to really see what keys are all about.)

  4. While still logged in, go to AirVPN>ClientArea>ConfigGenerator. This tool will generate an .ovpn file, which we will ignore, and the keys and certificates needed by dd-wrt. So...

    1. Check Advanced Mode on the right.

    2. Choose operating system: Router.

    3. Choose your OpenVPN version: >=2.4 (the default).

    4. Set "Need IPv6?" as appropriate: If you have not configured your router for IPv6 with appropriate arrangements with your ISP to support that, stick to IPv4 Only. Air does fully support IPv6, but my router is only set up for IPv4, so I have nothing to offer on anything specific to IPv6 configuration.

    5. On the right, scroll slightly down to Advanced and click Separate keys/certs from .ovpn file.

    6. In the large Protocols box on the left, scroll down until you start to see "tls-crypt, tls1.2" in the Specs column on the right. (Air's posted specs say their main website uses TLS 1.3, so their servers may well do so as well, in spite of the lower version number mentioned here.) The rest of the first row where that appears will be filled in with UDP, 443, 3, and "Recommended for best performance". Each AirVPN server has several "entry IP" addresses. The 3 denotes entry IP number 3, which is the primary entry that is tls-crypt compatible. Check the box on the left in that row.

    7. Scroll to the bottom of that Protocols box, ignoring any notes about ChromeOS, which I get even in Firefox. If you are setting up your first device and so have only one key, move on to the next step. but if you have set up multiple keys, presumably for multiple devices (See Configuring Multiple Routers Or iOS Devices below), there should now be an item "Choose your device/connection" with your key names presented as options. Select the desired key.

    8. The next section is "Choose Servers." Which you choose is not at all critical if you are using the dd-wrt openvpn GUI and not setting up your own .ovpn config file in dd-wrt, because you'll enter the server in the GUI anyway, but their system needs you to pick one or more servers here anyway. The easy option is to find the "By countries" column on the right and select the country where you typically want your router to connect. If you pick the US, for example, the FQDN (domain name) us3.vpn.airdns.org will be written into the .opvn file. Again this won't actually be needed, though it is nice to have a file to poke through to find the FQDN if you forget it at some point.

    9. Scroll all the way to the end of the loooong "Choose Servers" section and click Generate. You'll be presented with a list of several files. There'll be a long .ovpn filename at the end of the list and four short filenames above that one. If you don't see "Entry3", with the 3, in that long .ovpn name, you selected the wrong Protocol. You can scroll on down into a new copy of the generator form and have another go at it. Assuming you are satisfied that all is good at this point, Download each file. The .ovpn will only matter for debugging, so we hope not to use it. You'll need the short-name files for dd-wrt.

  5. Now we'll deal with the form part of the dd-wrt GUI>Services>VPN page. Feel free to Save now and then, but do not Apply yet.

    1. In the OpenVPN Client section, enable "Start OpenVPN Client."

    2. For "Server IP/Name" I entered "us3.vpn.airdns.org" to indicate to connect to whatever US server is lightly loaded, etc. at the time this name is resolved by the DNS system. (More on this timing later.) You can change "us" here to the standard two-letter abbreviation for any country in which they have servers. Specific server IPs will be dealt with later. Best to get things working with one of these whole-country selections for now.

    3. For "Port" select 443. (I believe you are free to change this to other protocols that they support, but I have not experimented.)

    4. For "Tunnel Device" select TUN.

    5. For "Tunnel Protocol" select UDP. We'll deal with the TCP alternative later.

    6. For "Encryption Cipher" select AES-256-GCM if it's available in your drop-down menu and AES-256-CBC otherwise. If you use the latter, the server will push a change to AES-256-GCM anyway, and if your openvpn version is recent (as mine was), you'll get the benefit even without the menu item.

    7. For "Hash Algorithm" select SHA512.

    8. If your dd-wrt has an "Inbound Firewall on TUN" option, there's no harm in checking it. It adds a firewall command to prevent new connections coming through the tunnel from the server to dd-wrt. If Air has done things right, it won't be needed. I checked it.

    9. Disable "User Pass Authentication", as the stronger approach of authenticating with cryptographic keys/certificates will be used instead.

    10. Check "Advanced Options" to obtain some new form items.

    11. For "TLS Cipher" select TLS-DHE-RSA-WITH-AES-256-GCM-SHA384, the first option.

    12. For "LZO Compression" select No.

    13. Enable NAT.

    14. Enable Firewall Protection.

    15. Leave "Tunnel MTU Setting" at the default of 1500.

    16. Disable Tunnel UDP MSS-Fix, as the way dd-wrt implements this is not quite compatible with AirVPN, so we will take care of it in Additional Config later


  6. If your build offers you an "nsCertType verification" option here, leave the box unchecked. If instead it offers Verify Server Cert, check the box.

  7. Put these lines in the "Additional Config" window (you may be adding a bit more later):
    Edit by moderator (egc), you do not need the settings below, the current default MTU size of 1400 should be sufficient

    mssfix 1400
    explicit-exit-notify 5
    route-delay 5

    If you did NOT check the box in the last step, also add the line remote-cert-tls server to do what a checked box would have done.

    Most of these Additional Config lines came from comparing the openvpn.conf file that dd-wrt otherwise generated to the .ovpn file created by Air's configurator above. There are two exceptions. First, the Air .ovpn file also included a auth-nocache command, but (per @egc below) it is unnecessary here.

    Second, without the mssfix 1400 line here, my connection tended to hang now and then and require a restart. There are many online explanations of how to determine what value for the latter command will be low enough for your ISP's network, for example https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn. (Do the test through the vpn tunnel.) Using that site's test, I came up with 1410 for my network on the day I tested (it can vary even on a given network), but mssfix 1410 led to occasional log messages about packets that were too long. Dropping it to 1400 completely eliminated the hanging, but I still get rare too-long messages. Lowering the mssfix value further didn't seem to change that, but that "issue" seemed to cause me no actual trouble, so I left the value at 1400. YMMV, but @egc, who knows way more about these matters than I, offered that this is a reasonable compromise value that should work for most networks.

    On my router I also include an Additional Config line log /tmp/vpn.log, as the last line, just to have the vpn log appear where I can easily find it in the CLI.

  8. Time to install the AirVPN certificates and keys.

    1. First we'll deal with the downloaded AirVPN file tls-crypt.key. The approach to take depends on your dd-wrt build.

      If you have a "TLS Key choice" item and a "TLS Key" window just below it, for "TLS Key choice" select TLS Crypt and copy the AirVPN file into the "TLS Key" window.

      However, if you have no "TLS Key choice" item, you'll have a "TLS Auth Key" window instead of a "TLS Auth Key" window. In that case, make very sure the "TLS Auth Key" window is completely empty, with no blank lines, and add the AirVPN file's contents to the "Additional Config" window enclosed between <tls-crypt> and </tls-crypt> lines, so that the new "Additional Config" material looks like this:

      <tls-crypt>
      -----BEGIN OpenVPN Static key V1-----


      [rows and rows of hexadecimal digits]

      -----END OpenVPN Static key V1-----
      </tls-crypt>


      It makes no real difference where you put it in "Additional Config", but putting it at the end is probably most natural. Blank lines in "Additional Config" are fine, except between the <tls-crypt> and </tls-crypt> lines.

    2. Leave the "PKCS12 Key" and "Static Key" windows empty. Be reeeeally sure there is no whitespace there, especially if you have to remove an existing TLS Auth Key. Residual whitespace in the TLS Auth Key window will make the connection to the AirVPN server fail.

    3. Put the contents of the AirVPN file ca.crt into the "CA Cert" window.

    4. Put the contents of the AirVPN file user.crt into the "Public Client Cert" window.

    5. Put the contents of the AirVPN file user.key into the "Private Client Key" window.

  9. If you have Policy Based Routing set up, leave that window as is.
Hit APPLY to try connecting! Next, some basic checks for proper operation are appropriate.
  1. Go to GUI>Status>OpenVPN and look for "Client: CONNECTED SUCCESS" as the State in the upper left. If something else is there instead, wait a few seconds and refresh the page. You should see success within 30 seconds and probably more like half that.

  2. Look down that same Status page for the Log (or look at /tmp/vpn.log in the CLI, if you specified putting the log there above). There are several things to look for.

    1. The warnings you'll see there will depend on whether you did an Apply as above or simply rebooted. If you rebooted, the dates and times on the left will be bizarrely wrong for many, many lines, until the system has had a chance to sync its time with the internet. Until then you may see warnings like "W WARNING: Your certificate is not yet valid!" or "N VERIFY ERROR: depth=1 error=certificate is not yet valid..." or "N OpenSSL: error" or "N TLS_ERROR: BIO read tls_read_plaintext error" because various things require correct time. Ignore those warnings.

    2. At some point the vpn client will likely give up on this whole messed-up-time thing and likely just restart the client with "I SIGUSR1[soft tls-error] received process restarting". That's just fine. Before much longer, the dates and times should stabilize and be correct.

    3. Once times are correct and things are restarted, ignore the "W NOTE" that "the current --script-security setting may allow this configuration to call user-defined scripts". Same deal. Irrelevant.

    4. If you did an Apply without a reboot, the times should be OK from the beginning, and you'll miss many of those warnings.

    5. Now ignore the many WARNINGs, from the beginning, about "Using --management on a TCP port WITHOUT passwords", which warnings are irrelevant because the router is a single-user (root) system with, presumably a strong password. Likewise, ignore WARNINGs about files that are "group or others accessible". Again, this is a buttoned-up system and no one is going to inappropriately get into those files.

    6. Scan down and look for a line like

      [Alkes] Peer Connection Initiated with [AF_INET]107.167.244.69:443

      where Akles here could be any name of an AirVPN server in the country you specified. You can find all the names and associated locations and Mbit/s loads and capacities at AirVPN>Status/Overview or https://airvpn.org/status/.

    7. Further down the log, near the end, you should see "I Initialization Sequence Completed". You may see "MANAGEMENT:" lines down there also, about connections, disconnections, and status of a management channel, I think internal to openvpn. Ignore those.


  3. Visit AirVPN>ClientArea>Overview at https://airvpn.org/client/ while on the vpn (and logged in to AirVPN) to see their record of your ongoing connection. You might want to bookmark the page or keep it in a tab and where you can reload it after an Apply, and perhaps even now and then in general, as sometimes an active connection that is being abandoned does not get shut down at the AirVPN end. (So far I've only found it to be an issue with Apply steps, not in my overnight reboots.) This AirVPN page will show you if you have multiple connections open and give you a button to terminate any stale ones.

    I've seen stale connections listed after restarting a connection in the CLI with killall -HUP openvpn or (I believe... memory iffy here) killall -USR1 openvpn, the "softer" choice that does not recreate the TUN interface, and I've seen them after powering down a router, but I don't believe I've seen them otherwise. The push from the server includes a request to ping through the tunnel every 10 seconds and to close the connection if 60 seconds passes without receiving a ping, and I believe they are using the same procedure at the server end, so these stale connections don't last long.

    On this status page, you can click on the server name they show to get a nice page with server stats, including a load plot vs time at the bottom. It seems the US servers typically have 50 to 60 connected users each.

  4. You can visit https://www.privateinternetaccess.com/pages/whats-my-ip/ through the vpn to see the exit IP of your new server independent of AirVPN. It will differ slightly in the last digit from the entry IP.

  5. AirVPN's own version of such a site is at https://ipleak.net and shows the exit IP, the name of the server, the location (from a database that is not always reliable), and some notion of the DNS servers you are using. The DNS tests come so fast that some DNS servers will refuse to play and so push you onto your backup servers, so don't be surprised at what you see. See https://airvpn.org/forums/topic/14738-overview/ for more on ipleak.net. (Not .com!) For a better-behaved check of DNS servers in use, try https://dnsleaktest.com.

  6. You can try the speed test at https://www.dslreports.com/speedtest, but don't be surprised if the number seems low. I find the response of AirVPN servers is generally really quick -- very low latency -- but the reported speeds may not be high. I've seen 70 Mbps, but I've also seen under 10 Mbps. Hard to say why.

  7. You can see what DNS servers Air pushed in the log in a very long "PUSH: Received control message: 'PUSH_REPLY..." line. It will have the form 10.x.x.x, which you might compare to your end of the tunnel as revealed by ifconfig tun1 in the CLI. (I believe some routers/builds will use tun0 instead.)



USING TCP

To use TCP instead of UDP, in GUI>Services>VPN in the OpenVPN Client section, change Tunnel Protocol to TCP. Then in Additional Config comment out, with a leading #, each of the first two lines that we put in that window above. Those two lines should then look like this:

#mssfix 1400
#explicit-exit-notify 5


I'm suggesting commenting them out rather than removing them so that you can easily reverse the process.


CONTINENTS, COUNTRIES, AND RANDOM SERVER CHOICE

In the discussion above, I entered us3.vpn.airdns.org as Server IP/Name on the GUI>Services>VPN page to specify use of an AirVPN-recommended Entry-3 (tls-crypt compatible) US server. Here and in the URLs below, us can be replaced with any region name or two-letter code country code supported by Air. (Omit the 3 for Entry-1 servers for tls-auth compatibility.)

Key resources for exploring server specifiers:While the discussion at this last URL says leo3.vpn.airdns.org, for example, specifies the Leo server specifically, such specific-server names may not resolve in the DNS system. You'll likely have to use a numeric IP address to specify a particular server.

As an alternative to simply using one name like us3.all.vpn.airdns.org, you can specify several names to OpenVPN. For example, to randomly choose one of Belgium, The Netherlands, Norway, and Sweden and then use an Air-recommended server within the chosen country, specify one of those countries in Server IP/Name in the GUI and then enter the others in Additional Config. For example, set Server IP/Name to be3.vpn.airdns.org and then add these lines to Additional Config:

remote-random
nl3.vpn.airdns.org 443
no3.vpn.airdns.org 443
se3.vpn.airdns.org 443


There is nothing special about the name entered in Server IP/Name. Internally all four names will be treated identically.

You can use the same approach to specify a random choice from a list of individual servers using numeric IP addresses, for example entering 199.249.230.24 as Server IP/Name for Entry 3 of the Leo US server and then entering something like this in Additional Config to choose randomly from the Entry-3 IP addresses of six specific US servers with the names shown here in # comments:

remote-random
#above in Server IP/Name: 199.249.230.24 443 #Leo Dallas, TX
remote 199.249.230.9 #Mensa Dallas, TX
remote 199.249.223.132 443 #Aquila Fremont, CA
remote 156.96.151.134 443 #Asterion/Metallah Princeton, NJ
remote 64.42.179.69 443 #Libra Atlanta, GA
remote 107.167.244.85 443 #Sabik Los Angeles, CA


With either of these remote-random approaches, if the first name tried does not yield a responsive server, another will be randomly selected and tried. You can get the server name and IP address to which you have actually connected by visiting https://ipleak.net or by looking in the log at GUI>Status>OpenVPN for the word "Connection".

To get numeric IP addresses for other AirVPN servers, use the tools listed above or follow instructions at https://airvpn.org/faq/servers_ip/, noting that "valorize" means to insert a value for. (Yes, I had to look it up.) Individual servers do not appear to be listed in the public DNS system, but I assume they are in the AirVPN DNS servers. (I can't check, as my router redirects all port 53 traffic to a public server.) Per those instructions, you can do, for example, or host us3.all.vpn.airdns.org or nslookup us3.all.vpn.airdns.org in linux and I believe Windows and get a giant list of all US servers' entry-3 IPs. I believe Windows has an nslookup tool as well, but I am not familiar with the details.

I do not recommend the specific-server approach, however, because certain kinds of openvpn problems can result in the OpenVPN client dd-wrt process terminating rather than moving on to another server. This is not specific to Air; I had the same thing happen with NordVPN many times in the course of a year. The Apply button on the GUI>Services>VPN page will generally restart the process (though certain recent BS builds may require using Apply twice).

The AirVPN server recommendation associated with, for example, us3.vpn.airdns.org, is updated every 5 minutes. I verified that this worked in my router in spite of DNS cacheing, so you won't have to, by pasting this into the dd-wrt CLI
Code:
( while sleep 60; do
      THIS=$(nslookup us3.vpn.airdns.org 2>/dev/null | sed -n '$s/^.*: //p')
      [[ "$THIS" != "$LAST" ]] && echo $(date) "$THIS" >>list
      LAST="$THIS"
done ) &
to obtain the numeric IP address to which us3.vpn.airdns.org resolved every minute and then record a timestamp and the IP address whenever the IP address changed. Letting it run for nearly an hour yielded this:

# cat list
Fri Nov 1 17:47:44 EDT 2019 193.37.254.37
Fri Nov 1 17:48:44 EDT 2019 193.37.254.29
Fri Nov 1 17:53:44 EDT 2019 199.249.230.14
Fri Nov 1 17:58:45 EDT 2019 96.47.229.61
Fri Nov 1 18:03:45 EDT 2019 199.249.230.4
Fri Nov 1 18:08:45 EDT 2019 199.249.230.24
Fri Nov 1 18:13:46 EDT 2019 193.37.254.21
Fri Nov 1 18:18:46 EDT 2019 193.37.254.5
Fri Nov 1 18:23:47 EDT 2019 199.249.230.39
Fri Nov 1 18:28:47 EDT 2019 199.249.230.34

(Then of course I did rm list and kill %1.) I use Quad9 DNS 9.9.9.9 (see https://quad9.net), but I expect the same result would have been obtained with Cloudflare 1.1.1.1 or Google DNS 8.8.8.8 or any other choice.


CONFIGURING ANOTHER ROUTER OR AN iOS DEVICE, QUICK START GUIDE

If you want to configure a second AirVPN device that requires key and certificate files, you'll need a second set of files. Each device gets its own. First you go to AirVPN>ClientArea>Devices at https://airvpn.org/devices/, add a new device, and name it. Then go to the AirVPN>ClientArea>ConfigGenerator configuration generator at https://airvpn.org/generator/ again and repeat the config process you did above except choosing the new device name when you get to "Choose your device/connection". Then, for a router at least, proceed as before. (See next post for iOS details.)


CONFIGURING MULTIPLE ROUTERS OR iOS DEVICES, HOW IT REALLY WORKS

On many vpn systems (PIA and NordVPN, for example), your account-login credentials, a username/password pair, double as your server-connection credentials. On AirVPN, however, your account credentials and connection credentials are separate. Your account credentials are a user/pass pair, but your connection credentials are a pair of cryptographic files, user.crt and user.key, presented to you during the configuration process. While you have one set of account credentials (per account), you can have multiple sets of connection credentials, with each such set termed a device key or just device or just key in their system and given its own name by you. Each such device key may or may not correspond to a physical device at your end. That's up to you. You can use their config generator to create as many configurations for a given device key as you like, and each such configuration will contain that device key's user.crt and user.key files along with ca.crt and tls-crypt.key files that are the same for all configurations, yours and everyone else's.

Presumably the latter two files amount to a public key that your openvpn client can use to verify that the server it is talking to has the associated private key and so really does belong to AirVPN and is not some man-in-the-middle attacker. Of course these cryptographic keys are also central to the secure Diffie-Hellman [key] Exchange that establishes the actual data-encryption keys used for the session (with Perfect Forward Secrecy). We are way outside my areas of competency here, but it's not hard to find tutorials on these matters online.

In any case, an Air device key can be added, deleted, or renewed in the Devices section of their site (if you are logged in). You don't see the two associated files at that point. That's all managed behind the scenes. For each device key you see only a line in a device table, and the only thing there that you care about is the name you have chosen for that device key. When you delete or renew (effectively delete then add) a device key, the old server-connection credentials associated with that device key are deleted from the system, so any configurations generated referencing the deleted device key will become nonfunctional, and you'll have to generate and install new configurations.

There are three limits imposed by AirVPN. First, you can have no more than five device keys. Second, each server can only maintain one connection at a time involving any particular device key. Third, an account is permitted no more than five simultaneous connections systemwide.

The natural use of device keys is to use one per physical device. You might name a device key iPhone and create as many configurations for it as you like to represent various combinations of servers and protocols and ports. Since your iPhone is naturally only going to be connected using one configuration at a time, the Second limit above will not impose any real restriction.

But if you have more than five devices to configure, you can share a device key across multiple devices with a little thought. You might have three dd-wrt routers on device key Router but with the first configured to connect to ca3.vpn.airdns.org, the second configured to connect to be3.vpn.airdns.org, and the third configured to connect to nl3.vpn.airdns.org. At any given time, one will be connected to a Canadian server, one to a Belgian server, and one to a Dutch server, so there is no risk of violating the second limit above. Or you could put a remote... line for each of Air's 68 Dutch servers into the Additional Config of only one of the three routers. Again the second limit discussed above will not be a problem, because the routers will never attempt to "share" a server.

The most important limit above then is the third, the maximum number of simultaneous connections. Also note that when you force dd-wrt to change servers using killall -HUP openvpn (see the link in my sig below), dd-wrt's openvpn client will not get the old connection fully shut down at both ends before the new connection is attempted. The old connection persists in the system for several tens of seconds. I have not tested this carefully to see what happens exactly when there are already five connections when the dd-wrt server change is attempted. Best case: perhaps the new connection will initially fail and will automatically be retried at suitable intervals until a connection succeeds (see next paragraph). In this case, there is no problem with having all five allowed connections in use at once. Worst case: perhaps the new connection will have an "authorization failure", and the dd-wrt openvpn process will terminate, as I have seen it do for that error. In the latter case, it might be wise to normally have no more than four connections, so that no auth failure will happen during a forced switch. Or pay attention before switching and disconnect something to bring the count down to four.

Multiple stagnant connections don't generally pile up as you force dd-wrt to change servers as discussed above, because while the connection is active, the server and client each one-way ping the other every 10 seconds. The server and client then each look for those pings to arrive, and if none do for a full minute, the connection is shut down (and, if possible, restarted). So even if dd-wrt neglects to shut down the current connection when moving on to a new server, matters will take care of themselves very soon. This is why powering down the router with an active connection causes no problems.

This discussion has been about devices like routers and iPhones that need configuration files generated for them. I have not experimented yet with the Eddie apps for Android, MacOS, Windows, and linux, but I assume that much of this business of keys and configs is handled behind the scenes so that the user doesn't need to deal with it. I'll update this discussion if I ever figure it out.


DNS SERVERS

When the vpn connects, AirVPN's server will "push" to dd-wrt an IP address that can be used to query one of their own DNS servers, which can be accessed only over the vpn tunnel. That IP is always the same as that of the tunnel gateway and of form 10.x.x.1, so if you are set up to take advantage of a pushed DNS server, as I believe the newest dd-wrt builds are -- in any case it is discussed elsewhere in recent forum posts -- you'll be all set. Using that gateway as DNS server is the best choice "to thwart DNS hijacking attacks" per AirVPN staff in their forums.

However, if you need absolutely need fixed DNS server IPs and want to use AirVPN's nonpublic DNS servers over the vpn, you can use 10.4.0.1 (with 10.5.0.1 as alternate), but of course these won't be available until the tunnel is up, so you will have to use only numeric IPs in the vpn client setup. In earlier dd-wrt builds, it will also be important either to NOT specify a time server -- allowing it to default -- in GUI>Setup>BasicSetup or to provide a separate, public DNS server in DNSMasq's Additional Config specifically to look up the NTP server IP address. (google it.) Note that 10.4.0.1 does not respond to pings.


POLICY BASED ROUTING (PBR)

Excellent new PBR and kill-switch features that provide a great deal more flexibility became available in BS build 41174 in late September 2019 -- see @egc's guide at https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321686 -- but to keep things fairly universal here, I'll only describe the setup of the older functionality that's been in dd-wrt for years.

So suppose you have an unbridged interface, say ath0.1, on subnet 192.168.2.1 with netmask 255.255.255.0, and suppose you want only traffic from that interface to be routed through the vpn tunnel. You can put the one line

192.168.2.128/26

in the "Policy Based Routing" (PBR) window in the OpenVPN client setup at GUI>Services>VPN, and only traffic from IP addresses in the set specified by 192.168.2.128/26 will be routed through the tunnel. If you have a kill switch (next section) set up for ath0.1, all other traffic from that subnet will be unable to reach the internet at all.

The set 192.168.2.128/26 is in CIDR notation (google it), meaning that if we expand each of four numbers in 192.168.2.128 into 8-bit binary, so that it becomes (using spaces instead of dots)

11000000 10101000 00000010 10000000,

the set in question comprises IP addresses for which the first 26 bits match those here. So, in binary it includes IP addresses of the form

11000000 10101000 00000010 10xxxxxx.

The lowest such address is 11000000 10101000 00000010 10000000 or 192.168.2.128, and the highest such address is 11000000 10101000 00000010 10111111 or 192.168.2.191. There are six unspecified bits, so there are 2^6 = 64 possibilities.

If at the bottom of GUI>Setup>Networking the DHCP server for interface ath0.1 is set to start at 128 with a max of 64 addresses, the set of possible IPs that DHCP will assign to ath0.1 clients is precisely 192.168.2.128/26. So if this is what we have specified in the PBR window, then those addresses that DHCP assigns to ath0.1 clients, and only those addresses, will have their traffic routed through the vpn tunnel.

If a second (nonoverlapping) set of addresses, say 192.168.2.96/27, is used for static leases, you can simply add 192.168.2.96/27 as a second line in the PBR window, and these clients also will have their traffic routed through the vpn.

When you use this older PBR capability, dd-wrt is not able to use the DNS server pushed to the OpenVPN client by the vpn server, so you have to specify DNS yourself for a subnet routed through the vpn in this way. The procedure is not obvious, but it is not difficult. In GUI>Wireless>BasicSettings in the section where ath0.1 is created, under Advanced Settings (check the box) at the bottom, the "IP Address" of the subnet gateway is specified as, in this example, 192.168.2.1, and just above it we can set an "Optional DNS Target." If we also set that DNS target to 192.168.2.1, DNS service for ath0.1 will be provided using whatever DNS we have set up for the router as a whole. (See my signature below for a Quad9/DNSCryptV1 option.) Or we can set it to a different public DNS server like 1.1.1.1 for Cloudflare DNS, in which case DNS traffic for ath0.1 (only) would go to Cloudflare, but not through the vpn. If we want DNS queries to go through the vpn, we need to specify an AirVPN DNS server with an IP address somewhere in the set 10.0.0.0/8 which in dd-wrt contains the vpn-tunnel IP addresses. Air provides their own internal DNS server at 10.4.0.1 for just this purpose.

Aside: One of the more exciting features of the new PBR system, the one for builds 41174 and later that we are not using here, is that it has a mechanism that can be used to route traffic for a publicly available DNS server like 1.1.1.1 (Cloudflare DNS) or 9.9.9.9 (see https://quad9.net) through the vpn, thus providing many more options for setting up DNS.


KILL SWITCH

You are likely to want to add a kill switch to the Firewall in GUI>Administration>Commands to keep packets intended for the vpn from exiting through the WAN directly when for some reason the vpn tunnel is down. If you are using build 41174 -- don't use that particular one in a Linksys/Marvell WRT router! -- or later, you need a fancier kill switch than I'm going to discuss below and should follow the second post in https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321686 or the last section of the guide to the new PBR system that you can download from the first post there.

For builds before 41174, many kill-switch variants have appeared in the dd-wrt forums. The simplest I've seen is due to @egc, our local vpn guru:
Code:
iptables -I FORWARD -i br0 -o $(nvram get wan_iface) -m state --state NEW -j REJECT --reject-with icmp-host-prohibited

However, I have one router running in Client Mode for which nvram get wan_iface returns nothing, so test that short command in the CLI first to see whether it returns your WAN interface as is intended. Or you can just replace $(nvram get wan_iface) in the iptables command with the interface name if you know it. On Linksys/Marvell WRT routers it is eth0. On some routers it is vlan2. Just don't guess.

The above one-line kill switch is specific to br0. If you use PBR to route all the action for multiple interfaces through the vpn client, you'l need to duplicate the above for each interface, replacing br0 appropriately in each, or use a loop:
Code:
for i in br0 ath1 ath0.2 ; do
    iptables -I FORWARD -i $i -o $(nvram get wan_iface) -m state --state NEW -j REJECT --reject-with icmp-host-prohibited
done

This example provides the kill switch for packets originating on bridge br0, unbridged interface ath1, and unbridged virtual access point (VAP) ath0.2. That list of three items can be shortened to contain just one interface or bridge or lengthened to contain many, separated by spaces. It makes no difference.

In my own router I use three iptables commands as suggested by NordVPN (but with their error corrected), and I use it in a simple loop to avoid the need to tweak when the PBR config changes, because it actually reads the PBR list to see precisely what to block. (You will need to reboot though after a PBR change.) It does assume that each line in your PBR window is either an individual IP address or is in CIDR notation as discussed above:
Code:
WAN_IF=$(ip route | awk '/^default/{print $NF}')
grep '\S' /tmp/openvpncl/policy_ips \
| while read pbr; do
    iptables -I FORWARD -s $pbr -o $WAN_IF -j REJECT --reject-with icmp-host-prohibited
    iptables -I FORWARD -s $pbr -p tcp -o $WAN_IF -j REJECT --reject-with tcp-reset
    iptables -I FORWARD -s $pbr -p udp -o $WAN_IF -j REJECT
  done

The grep just squeezes blank lines out of the file -- I hope that file has the same name on all dd-wrt systems -- that contains the PBR configuration information. I added it when I discovered that dd-wrt adds a blank line to the file even when the PBR config window has no empty lines. It would certainly be reasonable to use the one-line kill switch in the loop body instead of these three. Just replace -i br0 in that one line with -s $pbr for use here. The WAN_IF construct here is a more-universal alternative to the $(nvram get wan_iface) structure used earlier in this section.

That's it! Enjoy! I'll deal with iOS in a followup post.

_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.


Last edited by SurprisedItWorks on Thu Sep 08, 2022 18:07; edited 47 times in total
Sponsor
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1444
Location: Appalachian mountains, USA

PostPosted: Wed Oct 30, 2019 1:29    Post subject: Reply with quote
Air uses the OpenVPN protocols exclusively, because they feel they are the most secure, but legal constraints imposed by Apple effectively prohibit OpenVPN use in iOS except by the OpenVPN project's official app, OpenVPN Connect, meaning that Air cannot create its own iPhone app. Air does, however, provide custom config files for the OpenVPN Connect app, and each such config enables a simple on/off switch to engage/disengage the vpn. Be aware though that certain nice features common on the competitors' apps, like choosing servers on the fly or autoconnect with exceptions for trusted wifi systems, are just not there. Still, I do have OpenVPN Connect set up for Air/TCP/443 on multiple family phones for when we need to bypass a vpn block.

While it's perhaps a bit odd to have this iOS/AirVPN topic covered in a dd-wrt forum post, since it's not really about dd-wrt, it just seemed that it should be paired with the first post in this thread, which is very much about dd-wrt, because anyone deciding to use AirVPN via a dd-wrt router is likely going to want the option of using AirVPN on a phone as well. Air's site covers the Android case well enough, but their iOS discussion (https://airvpn.org/ios/) is seriously incomplete, so here is how you configure an iOS device like an iPhone to use AirVPN via port 443, their recommendation. (It's fairly obvious how to change ports if you should find a need.) It is based on what AirVPN publishes on their site but includes some steps they missed, steps that happen to be seriously nonintuitive. This discussion covers both UDP and TCP protocol choices.

To understand the relationship between keys, configurations, connections, and limits on numbers of each, see the section on configuring multiple routers or iOS devices near the end of the previous post. How to handle multiple configurations in iOS is then explained at the end below.

I followed this procedure for three phones running iOS 13.1.3 and using the OpenVPN Connect app, version 3.0.3.
  1. Download the OpenVPN Connect app from the App Store. Open it and touch OpenVPN Profile. Agree to the legalese that appears (at least in the US, where corporate lawyers grow like weeds) in a large popup. A screen should appear with two options for acquiring the .ovpn file. The first is "Using iTunes Sync, select your device, go to OpenVPN under the Apps tab, and drop your .ovpn and related cert/key files into the file sharing window" and the second is something about using an email attachment, which certainly would be a bad idea. The first option is actually a pain, however, and there is a hidden third option, which we will use instead.

  2. In Safari on your phone, visit https://airvpn.org. Assuming you already have an account (because you configured your router already, right?), push the three-little-bars menu activator on the upper right, click on Existing user? Sign in, and log in with your AirVPN account's Display Name (or email) and password.

  3. (This one step, but only this one step, could have been done on a computer instead, but keeping it all in Safari is just simpler. On the AirVPN website, push the three-little-bars menu activator again, select Client Area and then Devices. Under the table, click Add a new Key. The table should then show "New device" at the left end of the first row. If you slide the table body left to look at the right end, however, it is apt to show "Creation pending, please reload." In this case, click the circular-arrow reload button on the upper right of the Safari display. If necessary, wait a bit and repeat, with the goal of having the "New device" line of the table move to the bottom. You may have to slide the table body up to see it. Tap "New device" and change its name from "New device" to one of your choosing. This name will only be used internal to AirVPN and will not appear externally. You can also write into the next column to add more information that will appear only in this table but not on the configurator form later. Click anywhere outside the editing boxes to terminate the edits.

  4. Push the three-little-bars menu activator again, select Client Area and then Config Generator. On the config-generator page that then comes up, click at the bottom that you understand their cookie policy, then click the Advanced Mode box near the top and for Choose your Operating System, select iOS. For Choose our OpenVPN version, select >=2.4. Under "Need IPv6?" I suppose any of the three options would be fine, but I chose IPv4 only.

  5. Slide the body of the Protocol table to the left so you can see the rightmost column, then slide the table body up to look further down into the table. Keep going until tls-crypt, tls1.2 appears in the right column. The first two such rows are, if you slide the table rightward to expose the left columns, for UDP and TCP. Each of those rows will have 443 (the port number) in the second colum and 3 (the Entry-IP number) in the third. The fourth TCP column will warn that If you have issue with UDP, Look FAQ 'UDP vs TCP'. Check the box to the left of either UDP or TCP. UDP will give you better speed and will allow you to be more inconspicuous among a server's many users. TCP may make you unique among a server's users and will hurt your speed, but it may get you around an internet-provider vpn block that gives you trouble with UDP connections because TCP/443 makes your traffic look like ordinary https traffic.

  6. Scroll down past the Proxy and Advanced boxes to "Choose your device/connection" and choose the name you gave the new device key in the Devices area earlier.

  7. Scroll down to the "Choose servers" section and pick one server. I suggest here choosing a "By continents" or "By countries" server name, though certainly you could scroll further and pick an individual server. (Or several?) By choosing United States, I'm asking these connections to be made to us3.vpn.airdns.org, which effectively means an Entry-3 IP address (one that is tls-crypt compatible) for Air's choice from among their 37 US servers. They reset the DNS entry for these continent/country servers every 5 minutes to point to recommended physical servers. Their recommendations avoid servers that might be down (they claim 99.98% reliability, however) or that might be having performance issues. I haven't found there to be any noticeable response-time degradation from using a server on the other side of this rather large country.

  8. Scroll to the end of the long server list and click Generate. A popup will ask "Do you want to download BLAH?" where BLAH is the name of a .ovpn file. Click Download.

  9. Open the Files app (part of iOS) on the phone. You should see a "Downloads" folder. Touch it lightly to open it. You should then see the BLAH file downloaded in the last step. Touch it. The name will expand to fill the screen.

  10. Touch the share button on the upper right of the display, the square box with an up-arrow. A display will come up from the bottom with sharing options, and at the top of that box, the filename BLAH will appear. The second row of icons will have AirDrop, Messages, Mail, etc. (The exact list will depend on your Settings). Slide this row all the way to the left and select the "... More" button at the right end of the row. This will list Favorites (the apps whose names we just saw) and Suggestions. Well down into the Suggestions -- you may have to slide the list upward to see it -- will be Copy to OpenVPN. Select it. You will be returned to the OpenVPN Connect app. In the OpenVPN Connect app, you will see the filename BLAH again and the word ADD below it. Select ADD. You'll may get a "Failed to import..." popup message. I did, for two phones. Don't panic. Just re-enter the Files app, re-select Copy to OpenVPN, and when it pops you into OpenVPN Connect again, try touching ADD again. Look for a message "Profile successfully imported" and the BLAH filename. Now there is a white ADD option on the upper right of the display. Select it.

    If things go well, you'll get a popup that says "OpenVPN Would Like to Add VPN Configurations" with a stern but irrelevant warning (google it if curious) from the lawyers (weeds again) that "All network activity on this iPhone may be filtered or monitored when using VPN." Ignore the warning. If things don't go well, you may have to repeat any or all of this step. It took me twice on one phone and three times on the other.

  11. Accept the request to add a VPN Config and provide any necessary fingerprint, passcode, or face to make it happen. Finally you should have a switch beside "OpenVPN Profile," a server name like us3.vpn.airdns.org, and the BLAH filename (without the .ovpn suffix). Above the switch it says DISCONNECTED.

  12. Make sure you are not connected to a router connected to AirVPN -- surely you have one by now, right? -- and tap the switch to turn it on. A popup will ask you whether you want to "Allow OpenVPN to enable VPN connection?" Select Yes. The page with the switch and server/BLAH labels reappears now, with the switch in the on position and CONNECTED showing above the switch. Some "connection stats" appear on the rest of the screen. You are online with AirVPN! In the future the switch will always be there as soon as you select the OpenVPN Profile option on the OpenVPN Connect app's home screen, and you can connect and disconnect at will. The permission popups should no longer appear.

  13. While connected you can visit https://ipleak.net in Safari or other phone browser (Firefox, Brave, etc.) to confirm that you are indeed connected to AirVPN and using an internal AirVPN DNS server.

  14. If you return to the Safari tab where you are logged into AirVPN on their config-generator page, you can scroll back to the top of the page, find the three-little-bars menu enabler, use it to return to the Client Area, and select Overview. It will then show your AirVPN connection or, if you have other devices connected as well, all of your current connections (scroll to find any beyond the first).

  15. I have not experimented with going on and off various wifi systems and "cellular data" while connected, so I have no idea how the connection will fare.

  16. Don't forget to disconnect OpenVPN Connect and log Safari out of AirVPN, in either order. The first time you disconnect, a popup will ask you whether you really wish to disconnect and offer you a checkbox to suppress that popup in the future.

  17. You can create multiple iOS configurations using Air's config generator and install each using the procedure above. You can create those configs completely independently, or you can use the config generator once and check more than one protocol line (TCP and UDP with tls-crypt are adjacent in the table), in which case multiple config files will be created. I have not tried it, but I expect that if during configuration you check multiple countries or servers, you'll end up with a config that will choose a server from that larger list of options.

  18. If you want a second configuration differing from an already-installed first only in your choice of server, you can go into the Files app, hold down on the first config file (you did keep it, right?), select "duplicate", and then install the new file in OpenVPN Connect as before. In OpenVPN Connect edit the name with the pencil symbol and notice there is a "Server Override (optional)" field where you can enter a new server country designator like be3.vpn.airdns.org for Belgium or, I assume, the IP of a particular server. See the last post's section on Continents, Countries, and Random Server Choice for how these country or continent designators work and for how to find the IP address of a server.
The only problem I'm seeing with this finally nice switch-on, switch-off setup is that the connection, when on, is incompatible with the DNSCloak app (of which I am a fan) that I use to manage DNSCrypt and DoH connections to my choice of DNS servers. If you happen to use DNSCloak, switching on OpenVPN Connect's connection will disable DNSCloak's DNS system, even if you have Connect on Demand enabled in DNSCloak's settings. Once you disconnect AirVPN, however, you can just enter DNSCloak and re-enable its DNS system.

This AirVPN forum post offers some suggestions for tweaking OpenVPN Connect after the basic setup above is working, but note that it is an old thread and may be obsolete in places. I have not needed or used any of its suggestions, and everything seems to work fine:
https://airvpn.org/forums/topic/17767-why-no-how-to-guide-for-using-airvpn-with-openvpn-on-ios/
I haven't experimented with it (yet).

_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.


Last edited by SurprisedItWorks on Sun Dec 01, 2019 3:03; edited 6 times in total
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12812
Location: Netherlands

PostPosted: Wed Oct 30, 2019 9:50    Post subject: Reply with quote
Thanks man, great job I will bookmark this thread.

AirVPN looks like a solid choice.

Some remarks use them if you like.
I test openvpn version with:
openvpn --version

I saw you mentioned tls 1.2 if you can choose tls 1.3 in AirVPN then I would prefer that, it uses the TLS ciphersuites instead of the tls-ciphers, has mandatory Perfect Forward Secrecy and has removed lower grade ciphers. DDWRT can use tls 1.3.

OpenVPN 2.4 defaults indeed to AES-256-GCM, I have added those new ciphers in recent builds so you can choose them but is not necessary.

Do not use the auth-nocache option for DDWRT it can prevent reconnecting, besides you do not use a username /password so you do not need it anyway.
The option prevents the storing of username/password in RAM but you have it in a file in plain text anyway.
But as said you do not need it anyway as you do not have a username/password

On recent versions tick the box "Verify Server Cert." this will add the line remote-cert-tls server so you do not need to enter in in additional config. I have updated this in the newer builds.
Older version can enable the box: "nsCertType verification"

Setting the correct MTU size with UDP is troublesome, at home where I have cable and modem in bridge mode no problem with default settings, here at my summer house with crappy ADSL and PPPoE I only could get TCP reliably working.

Kudos to you great job!

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1444
Location: Appalachian mountains, USA

PostPosted: Wed Oct 30, 2019 14:22    Post subject: Reply with quote
Thank you, egc, for the great suggestions, which I have now edited into the original post above (along with a few other improvements)!
egc wrote:
I test openvpn version with: openvpn --version

Yes, it had been so long that I had forgotten this!
Quote:
I saw you mentioned tls 1.2
if you can choose tls 1.3 in AirVPN then I would prefer that, it uses the TLS ciphersuites instead of the tls-ciphers, has mandatory Perfect Forward Secrecy and has removed lower grade ciphers. DDWRT can use tls 1.3.

Air's posted specs at https://airvpn.org/specs/ actually mention supporting TLS 1.3 on their main website, so it's quite possible they support it in their servers as well, with the note in the Protocols table in the configurator perhaps being out of date. In any case, they do not offer a choice of TLS version. It just is what it is.
Quote:
OpenVPN 2.4 defaults indeed to AES-256-GCM, I have added those new ciphers in recent builds so you can choose them but is not necessary.

Nice. I noticed in the log that AES-256-GCM was being pushed and used even though I was unable to actually select it, so I guessed that it was built into the openvpn implementation that my dd-wrt builds used.
Quote:
Do not use the auth-nocache option for DDWRT it can prevent reconnecting...

Ah. I wondered about that, as their generated .ovpn files did include it. I'm running great without it now, though.
Quote:
On recent versions tick the box "Verify Server Cert." this will add the line remote-cert-tls server so you do not need to enter in in additional config. I have updated this in the newer builds.
Older version can enable the box: "nsCertType verification"

I had actually experimented a bit with this and found that in my dd-wrt builds, which do not have the Verify Server Cert option, enabling nsCertType verification led to a log message that this openwrt option would be deprecated in openvpn 2.5 (I am on 2.4.7) and to use remote-cert-tls server instead. You would think they would assume the correct intent and simply use the latter, but no...
Quote:
Setting the correct MTU size with UDP is troublesome, at home where I have cable and modem in bridge mode no problem with default settings, here at my summer house with crappy ADSL and PPPoE I only could get TCP reliably working.

It wasn't (isn't) clear to me whether the 1400 figure I arrived at through testing would be universal or whether others would have to redo that testing. I guessed at universality but included a link that suggested a specific test, just in case.

Also, I updated the DNS discussion in this color a few paragraphs from the beginning of that first post. Learned some new things in the AirVPN forums.

_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.


Last edited by SurprisedItWorks on Wed Oct 30, 2019 19:05; edited 1 time in total
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12812
Location: Netherlands

PostPosted: Wed Oct 30, 2019 18:43    Post subject: Reply with quote
Regarding UDP and MTU, if you want maximum throughput (the largest MTU size), you must set it for your own network connection, you want MTU as large as possible regarding the throughput.

Here in rural France it could even vary per day so I switched to TCP, but UDP is faster (well perhaps not if you have to set it below 1300)

But mssfix 1400 is a good middle point which usual works.

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1444
Location: Appalachian mountains, USA

PostPosted: Wed Oct 30, 2019 22:44    Post subject: Reply with quote
Just a heads-up that (in the first post above) I expanded the DNS discussion and moved it to near the end, where I also added discussions of PBR and iptables kill switches. There have been so many forum discussions on the later two topics that it seems many dd-wrt users need a bit of guidance, and I figured it'd be nice to try to make the post sufficiently complete as to perhaps -- here's hoping but who can be sure -- let someone set up the vpn client with no further information.
_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12812
Location: Netherlands

PostPosted: Thu Oct 31, 2019 8:02    Post subject: Reply with quote
SurprisedItWorks wrote:
Just a heads-up that (in the first post above) I expanded the DNS discussion and moved it to near the end, where I also added discussions of PBR and iptables kill switches. There have been so many forum discussions on the later two topics that it seems many dd-wrt users need a bit of guidance, and I figured it'd be nice to try to make the post sufficiently complete as to perhaps -- here's hoping but who can be sure -- let someone set up the vpn client with no further information.


Nice, maybe it is usefull to add a link to the PBR guide, I have also made an automatic kill script:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321686

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1444
Location: Appalachian mountains, USA

PostPosted: Thu Oct 31, 2019 14:46    Post subject: Reply with quote
egc wrote:
Nice, maybe it is usefull to add a link to the PBR guide, I have also made an automatic kill script:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321686

Done! I found your note when I sat down this morning to add that very thing. You saved me from having to poke around to find that post again. Very Happy

For my WRTblahblah router family anyway, the issue with the new functionality is that it appears in builds, 41174 - 41418 as of this writing, that have been troublesome in other areas. We haven't had a completely solid build since 40009. I have been watching for a new trustworthy one to emerge mostly so I can have access to that new PBR capability.

_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1444
Location: Appalachian mountains, USA

PostPosted: Fri Nov 01, 2019 15:14    Post subject: Reply with quote
When I first posted the HOW-TO, I commented that AirVPN was a nonprofit, something I apparently assumed (my specific memory is weak here, as on most things) from seeing .org in their domain name. I have now corrected the post on that point, because their staff has advised me that
AirVPN wrote:
AirVPN is not a no-profit organization. AirVPN is run by a company. The company operates according to AirVPN mission, only activists are employed by the company, earnings are sent also as donations to mission compatible entities, no money is used for marketing or to buy deceptive bogus reviews, but anyway it's not a no-profit company: it has earnings, pays taxes, pays wages to employees, and anything else like a for-profit company.

So while it certainly seems reasonable to consider them to be on the positive end of the corporate spectrum, they are not a nonprofit organization!

_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1444
Location: Appalachian mountains, USA

PostPosted: Sun Nov 03, 2019 18:16    Post subject: Reply with quote
I have edited the original post above to expand the RANDOM SERVICE CHOICE discussion into one on CONTINENTS, COUNTRIES, AND RANDOM SERVER CHOICE to cover the server-specification options more thoroughly.

The option of specifying a "server name" like us3.vpn.airdns.org to obtain (through the DNS system) an actual, specific server recommended by AirVPN, in this case one of their 37 US servers, is a big part of why I moved to AirVPN from NordVPN, which had no similar option. This way I don't have to be concerned with the risk of picking a server that is down or no longer in existence, something that was a constant problem with Nord. Air updates their region and country server recommendations in the DNS system every five minutes.

_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1444
Location: Appalachian mountains, USA

PostPosted: Mon Nov 18, 2019 0:39    Post subject: Reply with quote
This week I added a third dd-wrt router and a third iPhone to my AirVPN setup, and in the course of that I learned a few things.
  • Not all iPhones will force you to repeat the one tricky setup step until it works. One of the three phones worked perfectly the first time. It was the oldest phone by far. The new phones are apparently so fast that they get into some sort of race condition and trip over themselves.

  • Air is up to 42 US servers now. (Lots of servers elsewhere, too, of course: https://airvpn.org/status/)

  • If you selected IPv4-only in their configurator during the dd-wrt configuration process, ten of those servers (and some number of non-US servers) will at the moment incorrectly push IPv6 commands to dd-wrt's openvpn client, causing the client process to terminate if dd-wrt does not have IPv6 enabled. Air agrees this is a bug and plans to fix it quickly. They were clear that any delay in the process is simply so they can be systematic and careful and minimize disruption, because the fix will require taking affected servers offline temporarily.

  • Apply on the GUI>Services>VPN page will restart the openvpn client.
I am in awe of how quickly -- we're talking under two hours -- AirVPN support staff diagnosed and owned up to the IPv6 problem and then committed to the proper fix, once I properly described the behavior (by email) and sent along my vpn log. Ten days later they posted publicly that the fix had been implemented (it actually required patching the OpenVPN source code), "deeply tested," and had already been deployed to many servers, with only 40 servers worldwide yet to go.

_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1444
Location: Appalachian mountains, USA

PostPosted: Fri Nov 29, 2019 16:35    Post subject: Reply with quote
This is just a heads up to let everyone know that I have edited in a fairly hefty section near the end of the original post on configuring multiple routers or iOS devices that also covers what Air "keys" really are, what limits are imposed by Air, and how to stretch some of those limits when needed. I also clarified the tls-crypt vs. tls-auth business just before the step-by-step begins, mostly to avoid people trying to configure both, which is not possible, but also to be clear that tls-crypt is the way to go if you have that option. Finally, at the end I shared my new kill-switch for routers that use PBR, one that is finally free of the need to be edited when the PBR configuration changes.

I also edited the second post, on iOS configuration, to lay out how to have multiple configurations for connecting to different servers or to use TCP in one and UDP in another, etc.

_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1444
Location: Appalachian mountains, USA

PostPosted: Sun Dec 01, 2019 17:09    Post subject: Reply with quote
SurprisedItWorks wrote:
...at the end I shared my new kill-switch for routers that use PBR, one that is finally free of the need to be edited when the PBR configuration changes.

How embarassing that I had omitted the first line, which sets WAN_IF. Fixed now! Also referred those with recent builds to @egc's much more thorough kill-switch script, one that can handle the new PBR features.

It appears Air is running a Black Friday sale this weekend that drops prices 35% for plans six months and over. They've asserted in their forum that it is the deepest discount offered during the year. FWIW.

_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
SurprisedItWorks
DD-WRT Guru


Joined: 04 Aug 2018
Posts: 1444
Location: Appalachian mountains, USA

PostPosted: Sun Dec 08, 2019 19:24    Post subject: Reply with quote
SurprisedItWorks wrote:
If you selected IPv4-only in their configurator during the dd-wrt configuration process, ten of those servers (and some number of non-US servers) will at the moment incorrectly push IPv6 commands to dd-wrt's openvpn client, causing the client process to terminate if dd-wrt does not have IPv6 enabled. Air agrees this is a bug and plans to fix it quickly. They were clear that any delay in the process is simply so they can be systematic and careful and minimize disruption, because the fix will require taking affected servers offline temporarily.

At this time there are still six US servers (Groombridge, Teegarden, Kruger, Fang, Sneden, and Cursa) with this IPv6 issue, but I have found a workaround and confirmed with Air that it is a reasonable solution. One simply adds three lines to the dd-wrt OpenVPN client's Additional Configuration:

pull-filter ignore "dhcp-option DNS6 "
pull-filter ignore "ifconfig-ipv6 "
pull-filter ignore "redirect-gateway ipv6 "


With these lines added, one could, for example, safely enter us3.vpn.airdns.org as the server and dispense with the alternative of using remote-random and the associated remote ... 443 lines in Additional Config to get a random selection of a US server. The advantage of using us3.vpn.airdns.org instead is that the server it maps to is not random but chosen intelligently based on load, latency, etc. to ensure solid performance.

While this solution works great in openvpn 2.4 (I'm using it on 2.4.7), pull-filter was not available before openvpn 2.4 (per @egc) and will disappear in openvpn 3.x (per Air staff).

_________________
2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.


Last edited by SurprisedItWorks on Mon Dec 09, 2019 14:22; edited 1 time in total
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12812
Location: Netherlands

PostPosted: Mon Dec 09, 2019 6:28    Post subject: Reply with quote
SurprisedItWorks wrote:

pull-filter ignore "dhcp-option DNS6 "
pull-filter ignore "ifconfig-ipv6 "
pull-filter ignore "redirect-gateway ipv6 "



While this solution works great with openvpn 2.4.7, which I am on now, in OpenVPN 3 pull-filter will, per Air support staff, be deprecated.


Do they not mean it is not working in the older OpenVPN 2.3?
Because the pull filter option was only added starting with version 2.4?

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Goto page 1, 2  Next Display posts from previous:    Page 1 of 2
Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum