Setting up Tomato to connect to entry domain name

[TurdFerg 1]

Hello, I use a Tomato router to connect to AirVPN (Linksys E3000 with Shibby 1.28.0000 MIPSR2-140 K26 USB Mega-VPN)  

I have successfully configured the router's OpenVPN client to connect several times, using the excellent instructions in the Tomato How-To.  However the instructions involve picking out one single server in the configuration generator, and then resolving that server's individual IP to enter into the client's "Server Address/Port" field in settings.  This works great until, a month or two later, the server I'm connecting to disappears off the face of the earth & causes my client to no longer be able to connect to AirVPN.  I then have to go through the whole configuration process again, picking a different server, generating new keys etc,  which then gets me going until the new server also disappears at some point later on. 

What I would really like is to setup the router's client to use one of the country-specific entry domains, for example generate keys/certs for Canada & then use CA.vpn.airdns.org in the Server Address section of the Tomato OpenVPN Client Config.  This way, I know that I'll be pointed toward a (random) working server in a specific country each time I connect.  But this doesn't seem to work.  Interestingly, it seems to "almost" work -- if I go into Client Area > Overview on this web site, I can see the session listed (meaning the client has connected and AirVPN sees the client), however no traffic traverses & then after a minute or two the session ends. 

Can anyone help me get this working?  I have generated the keys/certs, entered them as normal, and put CA.vpn.airdns.org into the Server Address field on the router.  I have also left the Server Address blank and tried entering "remote CA.vpn.airdns.org 443" in the Custom Configuration tab on the router.  Same result both ways.  

Thanks!

[Flx 76]

7 hours ago, TurdFerg said:

I have also left the Server Address blank and tried entering "remote CA.vpn.airdns.org 443" in the Custom Configuration tab on the router.  Same result both ways.  

Don't leave that "blank". Pick 1 serverIP and paste it in Server Address. Pick a port 80/443/2018 etc.
Custom Configuration:
--------these IPs--are--for----entry2------define your own list of servers---for remote serverIPs--------
remote-random
remote 104.254.90.204 443
remote 184.75.223.196 2018
remote 184.75.221.116 2018
remote 184.75.214.164 2018
remote 184.75.223.220 2018
remote 184.75.221.4 2018
resolv-retry infinite
remote-cert-tls server
comp-lzo
auth-nocache
verb 4
--------these IPs--are--for----entry2------define your own list of servers---for remote serverIPs--------
Administration/Admin Scripts:Firewall
-------------------tun11-------------------------
iptables -I FORWARD -i br0 -o tun11 -j ACCEPT
iptables -I FORWARD -i tun11 -o br0 -j ACCEPT
iptables -I FORWARD -i br0 -o vlan2 -j DROP
iptables -I FORWARD -i br0 -o ppp0 -j DROP
iptables -I INPUT -i tun11 -j REJECT
iptables -t nat -A POSTROUTING -o tun11 -j MASQUERADE
-------------------tun11-------------------------
-------------------tun12-------------------------
iptables -I FORWARD -i br0 -o tun12 -j ACCEPT
iptables -I FORWARD -i tun12 -o br0 -j ACCEPT
iptables -I FORWARD -i br0 -o vlan2 -j DROP
iptables -I FORWARD -i br0 -o ppp0 -j DROP
iptables -I INPUT -i tun12 -j REJECT
iptables -t nat -A POSTROUTING -o tun12 -j MASQUERADE
-------------------tun12-------------------------

[Flx 76]

Dns1 server: 10.4.0.1
Dns2 server: 10.5.0.1
Dns3 server:
if you want to use and resolve "CA.vpn.airdns.org 443 " that..you need a global DNS.
Pick a server from OpenNIC/Uncensored DNS etc. or your own custom DNS. and paste it in DNS3.
Regards,
Flx
 

[Staff 9972]

@Flx

Hello,

just a note: 10.5.0.1 is no more used since a long ago. VPN DNS server primary address matches VPN server gateway, secondary address is 10.4.0.1 (regardless of the subnet you are in). 10.4.0.1 is not reachable by ping, but only DNS queries. https://airvpn.org/specs

Kind regards
 

[OpenSourcerer 1435]

And another note to OP: You don't have to regenerate keys, just adjust the IP address in the settings. There is no such thing as server-specific keys.

[TurdFerg 1]

Hello all, thanks for the suggestions, I appreciate them very much.  I wanted to provide an update and ask a further question. 

First, the issue was not related to the settings or the certs/keys, it was that the OpenVPN Server was attempting to push IPv6 routes to my client, even though I do not have IPv6 enabled.  This was not specific to my own issue from the original post, it was rather a new general server-side behavior started within the recent past (I suspect related to a OpenVPN version upgrade on AirDNS).  And was also causing my "normal" method of connection to fail (specific server's IPv4 address in settings) -- nothing at all was working.  I didn't notice that when I posted this question.  Once I figured that out, I opened a Support Request with AirVPN and they quickly identified and resolved the issue on their side -- kudos to them!

For anyone else that comes across this thread and wonders if if I ever got it working, I also want to report that I did.  In the end all I needed to do was simply enter CA.vpn.airdns.org:443 in the "Server Address / Port" field in the Tomato OpenVPN Client settings, instead of a specific server's IP address.  Everything else stayed exactly the same as I had previously set it in the "Using AirVPN With Tomato" topic in the How-To section on these forums.  And it just worked. 

Now, for my question.  In one of the posts above the staff mention 10.4.0.1 should be a secondary DNS address & to set the primary to match server gateway.  In the "Using VPN With Tomato" How-To tutorial it lists this differently, to set 10.4.0.1 as primary DNS and set something else (I used an OpenNIC DNS) as Secondary DNS.  My version of tomato does not have provisions available in the GUI for 3rd DNS, so I only use those two.  This works with the above. But should I change the order and/or do something different -- and if so why? 

[OpenSourcerer 1435]

This was a wholesole summary of how you resolved your issue through means outside this thread. Thank you very much for this! I wish more people would do that instead of writing "thanks all, I fixed it" or being downright mum.

By using the gateway address as DNS address, you might avoid creating certain attack scenarios for you. 10.4.0.1 is accessible from all subnets, therefore, Staff's scenario suggests using AirDNS only. Taking the recent experience with AirDNS into account (AirDNS returning SERVFAIL errors in rare circumstances when resolving certain names) I would not suggest using it alone, just like you're doing it already. It's generally a very good idea to have such an upstream server configured, especially on a router. Keep in mind though that your DNS queries are travelling unencrypted through the net if the router falls back to the secondary DNS.

[Staff 9972]

4 hours ago, giganerd said:

Keep in mind though that your DNS queries are travelling unencrypted through the net if the router falls back to the secondary DNS.

Or not: it depends on whether they are tunneled. In Linux based systems with global DNS (i.e. without on-link DNS simulation) DNS queries to any public DNS will be tunneled. In Windows there is no global DNS concept so  such queries in general will not be tunneled. That's also the reason why DNS leaks don't exist in Linux, unless it's deliberately configured to emulate rickety broken DNS implementation, but they are common in Windows and patched client-side by OpenVPN based software.

As a side note fir the OP: remember that DNS settings on the devices behind the router will determine the finala ddress to send queries to. Only if they query the router address in the local network, then the DNS servers set on the router will be queried. If they query any other DNS, their DNS queries will be anyway tunneled by Tomato router (and our VPN servers will then send them to the final destination, get the reply, and send the reply to you).

About the original problem experience by OP: OpenVPN server pushes IPv6 routes even when the client does not explicitly require them. Together with the fact that if "ip" (or any similar command) fails with IPv4, even if it's successful with IPv4, OpenVPN quits immediately, you can understand how gross and questionable this behavior is: any client without machine IPv6 support will be unable to connect.

So, we will force OpenVPN to NOT push IPv6 routes, unless IPv6 is explicitly required. The patch has been implemented and deeply tested, it is safe and compact, and will be deployed in all servers progressively but swiftly. Currently only 40 servers still pose the problem caused by the "original OpenVPN behavior".

Remember that the problem affects only systems which lack IPv6 support (they don't exist anymore but someone might disable IPv6 at system level for any reason, or use very old systems, so we are working to fix the issue quickly in the whole infrastructure).

To get OpenVPN IPv6 push you will need necessarily the following directives:

push-peer-info
setenv UV_IPV6 yes

The Configuration Generator already works accordingly and adds the proper directives if you require IPv6 over IPv4.

Kind regards