Jump to content
Not connected, Your IP: 3.226.97.214

Recommended Posts

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!

Share this post


Link to post

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.

Share this post


Link to post

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---------------

Share this post


Link to post
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

Share this post


Link to post
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. 

Share this post


Link to post

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?

'

 

Share this post


Link to post
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!

 

Share this post


Link to post

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!

Share this post


Link to post
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!
 

Share this post


Link to post

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.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Security Check
    Play CAPTCHA Audio
    Refresh Image

×
×
  • Create New...