R7800 AirVPN Weird Problem

[ProChemist 0]

Hello, after a lot of work, I managed to get AirVPN working on my R7000 with the latest DDWRT kong build. Recently. I tried to switch over to the R7800 (2/14/18 Kong build) without any luck.

Interestingly, although my browsers won't connect, if I use OpenVPN on Android or Eddie on Windows, my internet connection works again suddenly.

I've tried many things suggested on the forum, including resetting my windows firewall to default, flushing my DNS cache, and several configuration options, but I've had no luck even though I could get things running on my R7000. Does anyone have any advice for this problem? I've tried instructions from the original DDWRT installation instructions, here, and here:

https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321856

https://airvpn.org/forums/topic/26523-howto-setup-airvpn-on-dd-wrt-refreshed-guide/?ct=1575093664

And no luck. Below are my logs:
  Client: CONNECTED SUCCESS

---

Local Address: 10.18.51.19 
Remote Address: 10.18.51.19    Status

VPN Client Stats
TUN/TAP read bytes	199083
TUN/TAP write bytes	584164
TCP/UDP read bytes	607091
TCP/UDP write bytes	238076
Auth read bytes	584308
pre-compress bytes	0
post-compress bytes	0
pre-decompress bytes	0
post-decompress bytes	0

  LogClientlog: 
20200616 18:04:30 W WARNING: file '/tmp/openvpncl/client.key' is group or others accessible 
20200616 18:04:30 I OpenVPN 2.4.4 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Feb 14 2018 
20200616 18:04:30 I library versions: OpenSSL 1.1.0g 2 Nov 2017 LZO 2.09 
20200616 18:04:30 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:16 
20200616 18:04:30 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 
20200616 18:04:30 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 
20200616 18:04:30 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication 
20200616 18:04:30 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key 
20200616 18:04:30 NOTE: --mute triggered... 
20200616 18:04:30 1 variation(s) on previous 3 message(s) suppressed by --mute 
20200616 18:04:30 I TCP/UDP: Preserving recently used remote address: [AF_INET]37.120.132.93:443 
20200616 18:04:30 Socket Buffers: R=[87380->87380] S=[16384->16384] 
20200616 18:04:30 I Attempting to establish TCP connection with [AF_INET]37.120.132.93:443 [nonblock] 
20200616 18:04:31 I TCP connection established with [AF_INET]37.120.132.93:443 
20200616 18:04:31 I TCPv4_CLIENT link local: (not bound) 
20200616 18:04:31 I TCPv4_CLIENT link remote: [AF_INET]37.120.132.93:443 
20200616 18:04:31 TLS: Initial packet from [AF_INET]37.120.132.93:443 sid=57a0643b 390be6cf 
20200616 18:04:32 VERIFY OK: depth=1 C=IT ST=IT L=Perugia O=airvpn.org CN=airvpn.org CA emailAddress=info@airvpn.org 
20200616 18:04:32 VERIFY KU OK 
20200616 18:04:32 NOTE: --mute triggered... 
20200616 18:04:32 5 variation(s) on previous 3 message(s) suppressed by --mute 
20200616 18:04:32 I [Teegarden] Peer Connection Initiated with [AF_INET]37.120.132.93:443 
20200616 18:04:33 SENT CONTROL [Teegarden]: 'PUSH_REQUEST' (status=1) 
20200616 18:04:33 PUSH: Received control message: 'PUSH_REPLY comp-lzo no redirect-gateway def1 bypass-dhcp dhcp-option DNS 10.18.51.1 route-gateway 10.18.51.1 topology subnet ping 10 ping-restart 60 ifconfig 10.18.51.19 255.255.255.0 peer-id 0 cipher AES-256-GCM' 
20200616 18:04:33 OPTIONS IMPORT: timers and/or timeouts modified 
20200616 18:04:33 NOTE: --mute triggered... 
20200616 18:04:33 8 variation(s) on previous 3 message(s) suppressed by --mute 
20200616 18:04:33 Data Channel: using negotiated cipher 'AES-256-GCM' 
20200616 18:04:33 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key 
20200616 18:04:33 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key 
20200616 18:04:33 I TUN/TAP device tun1 opened 
20200616 18:04:33 TUN/TAP TX queue length set to 100 
20200616 18:04:33 D do_ifconfig tt->did_ifconfig_ipv6_setup=0 
20200616 18:04:33 I /sbin/ifconfig tun1 10.18.51.19 netmask 255.255.255.0 mtu 1500 broadcast 10.18.51.255 
20200616 18:04:38 /sbin/route add -net 37.120.132.93 netmask 255.255.255.255 gw 75.80.116.1 
20200616 18:04:38 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.18.51.1 
20200616 18:04:38 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.18.51.1 
20200616 18:04:38 W WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this 
20200616 18:04:38 I Initialization Sequence Completed 
20200616 18:05:00 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20200616 18:05:00 D MANAGEMENT: CMD 'state' 
20200616 18:05:00 MANAGEMENT: Client disconnected 
20200616 18:05:00 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20200616 18:05:00 D MANAGEMENT: CMD 'state' 
20200616 18:05:00 MANAGEMENT: Client disconnected 
20200616 18:05:00 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20200616 18:05:00 D MANAGEMENT: CMD 'state' 
20200616 18:05:00 MANAGEMENT: Client disconnected 
20200616 18:05:00 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20200616 18:05:00 D MANAGEMENT: CMD 'status 2' 
20200616 18:05:00 MANAGEMENT: Client disconnected 
20200616 18:05:00 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20200616 18:05:00 D MANAGEMENT: CMD 'log 500' 
20200616 18:05:00 MANAGEMENT: Client disconnected 
20200616 18:08:12 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20200616 18:08:12 D MANAGEMENT: CMD 'state' 
20200616 18:08:12 MANAGEMENT: Client disconnected 
20200616 18:08:12 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20200616 18:08:12 D MANAGEMENT: CMD 'state' 
20200616 18:08:12 MANAGEMENT: Client disconnected 
20200616 18:08:12 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20200616 18:08:12 D MANAGEMENT: CMD 'state' 
20200616 18:08:12 MANAGEMENT: Client disconnected 
20200616 18:08:12 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20200616 18:08:12 D MANAGEMENT: CMD 'status 2' 
20200616 18:08:12 MANAGEMENT: Client disconnected 
20200616 18:08:12 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20200616 18:08:12 D MANAGEMENT: CMD 'log 500' 
20200616 18:08:12 MANAGEMENT: Client disconnected 
20200616 18:08:19 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20200616 18:08:19 D MANAGEMENT: CMD 'state' 
20200616 18:08:19 MANAGEMENT: Client disconnected 
20200616 18:08:19 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20200616 18:08:19 D MANAGEMENT: CMD 'state' 
20200616 18:08:19 MANAGEMENT: Client disconnected 
20200616 18:08:19 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20200616 18:08:19 D MANAGEMENT: CMD 'state' 
20200616 18:08:19 MANAGEMENT: Client disconnected 
20200616 18:08:19 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20200616 18:08:19 D MANAGEMENT: CMD 'status 2' 
20200616 18:08:19 MANAGEMENT: Client disconnected 
20200616 18:08:19 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16 
20200616 18:08:19 D MANAGEMENT: CMD 'log 500' 
19691231 16:00:00 

 
I'd really appreciate any help on this, as I've been trying for a couple of days. Thank you!

[Flx 76]

Teegarden server relocated to Romania?
nslookup teegarden.airvpn.org or http://en.utrace.de/?query=teegarden.airvpn.org
Gateway-->> San Diego ISP(TimeWarner)-->>http://en.utrace.de/?query=cpe-75-80-116-1.san.res.rr.com
@Staff Please check.

[Flx 76]

What firewall rules have you set? Such as:

-------------tun1---------------
iptables -I FORWARD -i br0 -o tun1 -j ACCEPT

iptables -I FORWARD -i tun1 -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 tun1 -j REJECT

iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE
-------------tun1---------------

[SurprisedItWorks 49]

One more resource re dd-wrt config for AirVPN: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321856
I wrote this as I first brought my first dd-wrt router online with AirVPN, and as a new Air user, I had not yet become familiar with these Air forums.  So it is posted in the dd-wrt forum.

[ProChemist 0]

On 6/17/2020 at 10:14 AM, Flx said:

What firewall rules have you set? Such as:

-------------tun1---------------
iptables -I FORWARD -i br0 -o tun1 -j ACCEPT

iptables -I FORWARD -i tun1 -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 tun1 -j REJECT

iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE
-------------tun1---------------

I have these for my firewall rules:
 

WAN_IF=$(ip r | awk '/^default/{print $NF}')
iptables -I FORWARD -i br0 -o $WAN_IF -j REJECT --reject-with icmp-host-prohibited
iptables -I FORWARD -i br0 -p tcp -o $WAN_IF -j REJECT --reject-with tcp-reset
iptables -I FORWARD -i br0 -p udp -o $WAN_IF -j REJECT

[ProChemist 0]

9 hours ago, SurprisedItWorks said:

One more resource re dd-wrt config for AirVPN: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321856
I wrote this as I first brought my first dd-wrt router online with AirVPN, and as a new Air user, I had not yet become familiar with these Air forums.  So it is posted in the dd-wrt forum.

Hi SurprisedItWorks, if you look in the original post, I actually cited having used your guide, along with several others. Not sure why it says Connected Success but I have no internet browser access.

Yet, when I use an Airvpn client like Eddie, or OpenVPN, that's the ticket that allows me to connect. I've tried many permutations, including no firewall rules, the firewall rules above, some in guides, etc. 

[SurprisedItWorks 49]

Greetings, ProChemist... Ah!  It seems I looked at  your two links and "saw" two air-forum links.  My brain was like your router... connected yet not connected!  So here are some semi-random thoughts to maybe trigger some better thoughts from someone or some interesting data from your setup.

First, the key here may be your build.  As you no doubt know, Kong stopped providing new builds, so your old (2 and 1/3 years) build may be the issue.  There could be build quirks at issue, especially as you are working with really old versions of the OpenVPN and OpenSSL clients in that old build.  I've never learned about the specifics of Kong builds, as they are not available for my routers, but think about this: In the dd-wrt forums these days, the R7800 with current BrainSlayer builds are widely considered the best dd-wrt "package" one can put together.  Have you considered switching to a current BS build?  (Before you do though, read the associated new-build thread in the atheros dd-wrt forum, so that you are alert for build-specific issues.)  While its certainly true and not just a myth that using BS builds can require a certain amount of bug dodging with workarounds, it's also true that this should be less of an issue with the R7800 than with other routers, as the R7800 appears to be BS's primary development platform.

Second, your log looks great, and you get to the net via openvpn clients on your devices, so your router's vpn connection may be just fine, with Eddie et al. connecting through your router's vpn tunnel to give you a tunnel through a tunnel.  (I don't use Eddie, so I don't know whether Air's code allows this, but I can definitely connect some providers' vpn clients through my router's vpn tunnel.) Makes me wonder whether this is a DNS issue.  Is your Eddie configured to connect via a numeric IP address, so that it doesn't need DNS?  (What about your computer's other openvpn client?)  After all, Eddie et al. on your devices route DNS queries through their own tunnels, bypassing whatever you have set up in the router. Can you browse to a numeric IP address?  Does browsing to 1.1.1.1, for example, bring up a Cloudflare page for you like it does for me?

'

 

[ProChemist 0]

On 6/19/2020 at 7:36 AM, SurprisedItWorks said:

Greetings, ProChemist... Ah!  It seems I looked at  your two links and "saw" two air-forum links.  My brain was like your router... connected yet not connected!  So here are some semi-random thoughts to maybe trigger some better thoughts from someone or some interesting data from your setup.

First, the key here may be your build.  As you no doubt know, Kong stopped providing new builds, so your old (2 and 1/3 years) build may be the issue.  There could be build quirks at issue, especially as you are working with really old versions of the OpenVPN and OpenSSL clients in that old build.  I've never learned about the specifics of Kong builds, as they are not available for my routers, but think about this: In the dd-wrt forums these days, the R7800 with current BrainSlayer builds are widely considered the best dd-wrt "package" one can put together.  Have you considered switching to a current BS build?  (Before you do though, read the associated new-build thread in the atheros dd-wrt forum, so that you are alert for build-specific issues.)  While its certainly true and not just a myth that using BS builds can require a certain amount of bug dodging with workarounds, it's also true that this should be less of an issue with the R7800 than with other routers, as the R7800 appears to be BS's primary development platform.

Second, your log looks great, and you get to the net via openvpn clients on your devices, so your router's vpn connection may be just fine, with Eddie et al. connecting through your router's vpn tunnel to give you a tunnel through a tunnel.  (I don't use Eddie, so I don't know whether Air's code allows this, but I can definitely connect some providers' vpn clients through my router's vpn tunnel.) Makes me wonder whether this is a DNS issue.  Is your Eddie configured to connect via a numeric IP address, so that it doesn't need DNS?  (What about your computer's other openvpn client?)  After all, Eddie et al. on your devices route DNS queries through their own tunnels, bypassing whatever you have set up in the router. Can you browse to a numeric IP address?  Does browsing to 1.1.1.1, for example, bring up a Cloudflare page for you like it does for me?





I somehow managed to find an updated Kong build (I think) "Firmware: DD-WRT v3.0-r40270M kongat (07/11/19)," and that seems to have solved the problem! interestingly, on TCP 443, I get occasional moments where I can't connect to the internet. Restarting my router solves this issue; do you think it may have to do with the mssfix, which is commented out in TCP configuration as per your guide?

I'm not opposed to BS builds; I've just been using Kong ever since I started with AirVPN. As I've gotten the major issue resolved, I probably won't switch for now, but thank you for the advice! I'll consider BS builds in the future, especially if I have other issues. Thank you SurprisedItWorks!
 

[SurprisedItWorks 49]

Hi ProChemist... Great that you got things going!

Re mssfix, my limited understanding (and I'm no networking expert) is that it simply does not apply to TCP. I believe I learned that first from the error message in the log when I left it in for TCP experiments!

[ProChemist 0]

On 6/22/2020 at 10:54 AM, SurprisedItWorks said:

Hi ProChemist... Great that you got things going!

Re mssfix, my limited understanding (and I'm no networking expert) is that it simply does not apply to TCP. I believe I learned that first from the error message in the log when I left it in for TCP experiments!

Hmm, thanks for the info! Interestingly, although my network works most of the time, I do get random disconnects where I lose the server connection and need to reboot the router to get it going again. Seems to be intermittent; I'll need to try to get a screenshot of the log next time it happens. I think I've only had this problem with TCP. I appreciate the help!
 

[SurprisedItWorks 49]

Actually, the OpenVPN client in dd-wrt (like that in other router firmwares, no doubt) exchanges regular pings (every 10s I think) with the VPN server so that ordinarily if the connection goes down or hangs for more than some threshold duration (60s?), either the server or the client will note the missing pings and restart the connection without you needing to get involved.

In late 2019 though there were some Air servers that had a small bug that caused them to push IPv6 parameters to clients that were IPv4-only systems.  Somehow that caused the openvpn process in dd-wrt to crash and terminate completely, so that such ordinary restarts would not be possible.  I know they fixed it on most servers pretty quickly, and most likely they fixed all of them, but if yours is an IPv4-only system, you might want to look at the OpenVPN log the next time it happens (before you reboot) and see if the PUSH command from the server is showing obvious IPv6 stuff.  If it is, there's a workaround (detailed in my AirVPN How-To dd-wrt forum thread).  And you'd want to let Air know they missed a server, so note which it one it is.

The next time it happens, if you are versed in CLI/linux things, also check before you reboot to see whether the openvpn process has died.  Try command "ps | grep [o]penvpn" when it's working so you'll know what you should see.  If the process has crashed, this command will return nothing.  If the process is crashing for some reason other than the IPv6 issue, one can always put a little sentinel code in the Startup section to check every so often to see if the process is there and start it if needed.  I do that on some of my routers.  (Will share if anyone needs.)  It's a dd-wrt or OpenVPN issue, not an Air issue.  I actually had the problem far more often in my pre-Air days when I used NordVPN.

[ProChemist 0]

On 7/12/2020 at 3:31 PM, SurprisedItWorks said:

Actually, the OpenVPN client in dd-wrt (like that in other router firmwares, no doubt) exchanges regular pings (every 10s I think) with the VPN server so that ordinarily if the connection goes down or hangs for more than some threshold duration (60s?), either the server or the client will note the missing pings and restart the connection without you needing to get involved.

In late 2019 though there were some Air servers that had a small bug that caused them to push IPv6 parameters to clients that were IPv4-only systems.  Somehow that caused the openvpn process in dd-wrt to crash and terminate completely, so that such ordinary restarts would not be possible.  I know they fixed it on most servers pretty quickly, and most likely they fixed all of them, but if yours is an IPv4-only system, you might want to look at the OpenVPN log the next time it happens (before you reboot) and see if the PUSH command from the server is showing obvious IPv6 stuff.  If it is, there's a workaround (detailed in my AirVPN How-To dd-wrt forum thread).  And you'd want to let Air know they missed a server, so note which it one it is.

The next time it happens, if you are versed in CLI/linux things, also check before you reboot to see whether the openvpn process has died.  Try command "ps | grep [o]penvpn" when it's working so you'll know what you should see.  If the process has crashed, this command will return nothing.  If the process is crashing for some reason other than the IPv6 issue, one can always put a little sentinel code in the Startup section to check every so often to see if the process is there and start it if needed.  I do that on some of my routers.  (Will share if anyone needs.)  It's a dd-wrt or OpenVPN issue, not an Air issue.  I actually had the problem far more often in my pre-Air days when I used NordVPN.

Thanks for the help! I managed to snag a disconnect and get the log. Any thoughts on this?

[SurprisedItWorks 49]

You don't have a functioning DNS system at the time OpenVPN is trying to start, so it is not able to get the current numeric IP address corresponding to us3.vpn.airdns.org.  I'm not sure how you are trying to set up DNS, but certainly you cannot just set 10.4.0.1 (or whatever the Air DNS server IP is) as the one and only system DNS server, because that won't work until the VPN connection is established, and you can't establish the VPN connection without working access to a DNS server.  I can't get more specific without knowing your DNS setup, but maybe that will get you looking in the right direction.

[ProChemist 0]

23 hours ago, SurprisedItWorks said:

You don't have a functioning DNS system at the time OpenVPN is trying to start, so it is not able to get the current numeric IP address corresponding to us3.vpn.airdns.org. I'm not sure how you are trying to set up DNS, but certainly you cannot just set 10.4.0.1 (or whatever the Air DNS server IP is) as the one and only system DNS server, because that won't work until the VPN connection is established, and you can't establish the VPN connection without working access to a DNS server. I can't get more specific without knowing your DNS setup, but maybe that will get you looking in the right direction.

Ha, I do have 10.4.0.1 set as the static DNS. Any suggestions on what I should change it to? I'm a noob user so it took me a while to set up AirVPN and I try to not to mess with it once I get it working. It's all above my simple brain. 😵

[Flx 76]

2 hours ago, ProChemist said:

Ha, I do have 10.4.0.1 set as the static DNS. Any suggestions on what I should change it to? I'm a noob user so it took me a while to set up AirVPN and I try to not to mess with it once I get it working. It's all above my simple brain. 😵

On how to address/resolve this issue/problem of yours go to DNS section.

[SurprisedItWorks 49]

As Flx's referenced page suggests: 10.4.0.1 as primary.  Then add a secondary beneath it.  The linked page suggests one of the opennic choices.  Personally I'd pick from the major, well-known, fast ones, like Cloudflare at 1.1.1.1, Quad9 (see quad9.net) at 9.9.9.9, or even google at 8.8.8.8.   The choice is not terribly important, as you'll only be using it when Air's DNS server is not responding, which should be rare.

[Flx 76]

1 hour ago, SurprisedItWorks said:

Personally I'd pick from the major, well-known, fast ones, like Cloudflare at 1.1.1.1, Quad9 (see quad9.net) at 9.9.9.9, or even google at 8.8.8.8.   The choice is not terribly important, as you'll only be using it when Air's DNS server is not responding, which should be rare.

@ProChemistThis is your choice and whichever DNS provider you pick is up to you. Cloudflare or Google DNS NOT recommended.
@SurprisedItWorksWhy don't we let the OP here make his own decision. BTW: The first dd-wrt router flashed and setup some years ago was by following your guide. Thank you for that. Lets not turn this topic in another DNS diverse opinion battle.

[SurprisedItWorks 49]

When you think in the future about maybe moving to a new BS dd-wrt build, be aware that DNS handling for OpenVPN client users is much improved now. By default it will prioritize use of the DNS server pushed by the VPN server. With Air you'd make one small config change to be sure access of that server is routed through the OpenVPN tunnel (necessary to reach Air's DNS servers). Your configured Static DNS servers would effectively be backup. And you decide whether to allow -- there's a check box -- the ISP's DNS servers to be the ultimate backup behind it all.  The whole setup has come a long way. 

There's also a solid wireguard client in dd-wrt now, one that can even support multiple tunnels, so we are ready for Air's much hinted at forthcoming wireguard option. For those with such inclinations, it's not even hard to route one tunnel through another. As an experiment, I've run a wireguard tunnel to another provider's server through the OpenVPN tunnel to an Air server. Worked fine. 

[Flx 76]

On 8/10/2020 at 9:18 PM, SurprisedItWorks said:

And you decide whether to allow -- there's a check box -- the ISP's DNS servers to be the ultimate backup behind it all.

Why on any "sort of surface" would you be in need of your ISP DNS servers?

On 8/10/2020 at 9:18 PM, SurprisedItWorks said:

There's also a solid wireguard client in dd-wrt now,

I didn't know that. How solid is it in your opinion? Edited ... by Flx
Please don't twist my words of what was said

[SurprisedItWorks 49]

Flx, what you say everyone here at Air has known for 10+ years has actually been true in dd-wrt for less than a year. The ability to use pushed servers was on the dd-wrt wish list for a very long time. 

My tutorial was used for the very first of something?  I wrote it less than a year ago. 

I'm new (two weeks?) to dd-wrt wireguard, but so far it's been great.  My little WRT1900ACSv2 router is running an OpenVPN client to connect to Air servers, and it's currently running two wireguard "clients" as well, connecting to different servers of another provider. Lots of isolated subnets. I've measured wireguard download speeds (my ISP service is 200/10) up to 180 Mbps. It's also easy enough to route a wireguard tunnel through the Air OpenVPN tunnel. This post will go up through my nested-tunnel experiment.

[Flx 76]

 

5 hours ago, SurprisedItWorks said:

My tutorial was used for the very first of something?  I wrote it less than a year ago. 

If it was not your tutorial; than I followed a similar one. I had to "drop" dd-wrt(router died).
I'll report myself if that will make you happy. Want me to send you an apology? I will.
"Flx, what you say everyone here at Air has known for 10+ years has actually been true in dd-wrt for less than a year. The ability to use pushed servers was on the dd-wrt wish list for a very long time." quote that was not what I said in the first place.  Edited ... by Flx
giganerd and LZ1 mods have been notified. original of what I said sent

[ProChemist 0]

Thank you both for the advice!