Persistent connection failures with multi rapid connect/disconnects and dangling sockets in different clients, please help?

Verby · 09/10/2015

Hello the forum!

I have been having what looks to me like the same persistent issue interfering with my connections to airvpn, in both my openvpn connect iPad app (iPad 2 iOS 5.1.1) as well as the openvpn client in my Linksys E1200 router flashed with dd-wrt firmware (v24-sp2 (03/25/13) mega).

With udp connection attempts I see many connect/disconnects, on the airvpn website I look like I have ~7 dangling socket connections, none of which I can use, preventing me from trying again for many minutes whilst they dangle emptily.

With tcp attempts I see similar connect/disconnects, but the airvpn website shows me having only one connection, which is equally multi-minute-persisting, with an equally empty dangle.

I'm thinking the difference in dangling socket number is likely due to the difference between udp and tcp protocols, but I'm open to being mistaken about this.

In my openvpn connect iPad app I've tried connecting with both udp and tcp in ports 443, 2018, and alternative-2018, and to Europe, America, UK and USA servers, always with similar unsuccessful connection behaviours.

So far in dd-wrt I've only tried connecting to the UK server in port 443 with udp and tcp, but I saw the familiar old icky behaviours from my very first attempt.

My ability to make more attempts is limited because I am bed-bound with a chronic illness, it eats most of my energy and makes my hands numb and painful. It interferes with my ability to use a keyboard, so most of my attempts are restricted to iPad only.

I've had this connection problem in my iPad app for over 3 months now, after many months of issue-free happy use it manifested suddenly and never went away. I've only recently managed to get my dd-wrt router connected to the internet and I hoped its vpn client would resolve my vpn connection issues. I saw it doing the same old familiar failures right from the start, so I'm wondering if my isp might be interfering somehow (LLU account with Vivaciti in the UK). Weirdly, I can still connect to airvpn in port 443/udp with the tunnelblick client on my MacBook (OSX 10.6.8 Snow Leopard).

But since my ability to use my laptop keyboard is severely restricted by my illness, I need a more iPad-friendly solution.

I'm hoping you good people might be able to help me connect successfully? Please remember that my illness will reduce my ability to implement many of the available options.

I enclose the dd-wrt log from my most recent attempt to connect to the UK server in port 443 with tcp.

I'm most grateful for any help you can offer. Thank you.

Serverlog Clientlog 20150910 08:01:31 I OpenVPN 2.3.0 mipsel-unknown-linux-gnu [sSL (OpenSSL)] [LZO] [EPOLL] [MH] [iPv6] built on Mar 25 2013

20150910 08:01:31 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:16

20150910 08:01:31 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

20150910 08:01:31 W WARNING: file '/tmp/openvpncl/client.key' is group or others accessible

20150910 08:01:31 W WARNING: file '/tmp/openvpncl/ta.key' is group or others accessible

20150910 08:01:31 I Control Channel Authentication: using '/tmp/openvpncl/ta.key' as a OpenVPN static key file

20150910 08:01:31 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication

20150910 08:01:31 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication

20150910 08:01:31 Socket Buffers: R=[87380->131072] S=[16384->131072]

20150910 08:01:31 I Attempting to establish TCP connection with [AF_INET]84.39.116.179:443 [nonblock]

20150910 08:01:32 I TCP connection established with [AF_INET]84.39.116.179:443

20150910 08:01:32 I TCPv4_CLIENT link local: [undef]

20150910 08:01:32 I TCPv4_CLIENT link remote: [AF_INET]84.39.116.179:443

20150910 08:01:32 TLS: Initial packet from [AF_INET]84.39.116.179:443 sid=c4a16998 b4c55856

20150910 08:01:33 VERIFY OK: depth=1 C=IT ST=IT L=Perugia O=airvpn.org CN=airvpn.org CA emailAddress=info@airvpn.org

20150910 08:01:33 VERIFY OK: nsCertType=SERVER

20150910 08:01:33 NOTE: --mute triggered...

20150910 08:01:37 6 variation(s) on previous 3 message(s) suppressed by --mute

20150910 08:01:37 I [server] Peer Connection Initiated with [AF_INET]84.39.116.179:443

20150910 08:01:39 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)

20150910 08:01:39 PUSH: Received control message: 'PUSH_REPLY redirect-gateway def1 bypass-dhcp dhcp-option DNS 10.5.0.1 comp-lzo no route-gateway 10.5.0.1 topology subnet ping 10 ping-restart 60 ifconfig 10.5.1.133 255.255.0.0'

20150910 08:01:39 OPTIONS IMPORT: timers and/or timeouts modified

20150910 08:01:39 NOTE: --mute triggered...

20150910 08:01:39 5 variation(s) on previous 3 message(s) suppressed by --mute

20150910 08:01:39 ROUTE_GATEWAY 192.168.0.101/255.255.255.0 IFACE=vlan2 HWADDR=b4:75:0e:da:80:15

20150910 08:01:39 I TUN/TAP device tun1 opened

20150910 08:01:39 TUN/TAP TX queue length set to 100

20150910 08:01:39 I do_ifconfig tt->ipv6=1 tt->did_ifconfig_ipv6_setup=0

20150910 08:01:39 I /sbin/ifconfig tun1 10.5.1.133 netmask 255.255.0.0 mtu 1500 broadcast 10.5.255.255

20150910 08:01:39 /sbin/route add -net 84.39.116.179 netmask 255.255.255.255 gw 192.168.0.101

20150910 08:01:39 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.5.0.1

20150910 08:01:39 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.5.0.1

20150910 08:01:39 I Initialization Sequence Completed

20150910 08:02:21 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:02:21 D MANAGEMENT: CMD 'state'

20150910 08:02:21 MANAGEMENT: Client disconnected

20150910 08:02:21 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:02:21 D MANAGEMENT: CMD 'state'

20150910 08:02:21 MANAGEMENT: Client disconnected

20150910 08:02:21 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:02:21 D MANAGEMENT: CMD 'state'

20150910 08:02:21 MANAGEMENT: Client disconnected

20150910 08:02:22 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:02:22 D MANAGEMENT: CMD 'log 500'

20150910 08:02:22 MANAGEMENT: Client disconnected

20150910 08:03:02 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:03:02 D MANAGEMENT: CMD 'state'

20150910 08:03:02 MANAGEMENT: Client disconnected

20150910 08:03:02 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:03:02 D MANAGEMENT: CMD 'state'

20150910 08:03:02 MANAGEMENT: Client disconnected

20150910 08:03:02 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:03:02 D MANAGEMENT: CMD 'state'

20150910 08:03:02 MANAGEMENT: Client disconnected

20150910 08:03:03 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:03:03 D MANAGEMENT: CMD 'log 500'

20150910 08:03:03 MANAGEMENT: Client disconnected

20150910 08:03:27 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:03:27 D MANAGEMENT: CMD 'state'

20150910 08:03:27 MANAGEMENT: Client disconnected

20150910 08:03:27 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:03:27 D MANAGEMENT: CMD 'state'

20150910 08:03:27 MANAGEMENT: Client disconnected

20150910 08:03:27 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:03:27 D MANAGEMENT: CMD 'state'

20150910 08:03:27 MANAGEMENT: Client disconnected

20150910 08:03:27 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:03:27 D MANAGEMENT: CMD 'log 500'

20150910 08:03:27 MANAGEMENT: Client disconnected

20150910 08:04:22 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:04:22 D MANAGEMENT: CMD 'state'

20150910 08:04:22 MANAGEMENT: Client disconnected

20150910 08:04:22 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:04:22 D MANAGEMENT: CMD 'state'

20150910 08:04:22 MANAGEMENT: Client disconnected

20150910 08:04:22 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:04:22 D MANAGEMENT: CMD 'state'

20150910 08:04:22 MANAGEMENT: Client disconnected

20150910 08:04:22 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:04:22 D MANAGEMENT: CMD 'log 500'

20150910 08:04:22 MANAGEMENT: Client disconnected

20150910 08:04:51 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:04:51 D MANAGEMENT: CMD 'state'

20150910 08:04:51 MANAGEMENT: Client disconnected

20150910 08:04:51 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:04:51 D MANAGEMENT: CMD 'state'

20150910 08:04:51 MANAGEMENT: Client disconnected

20150910 08:04:51 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:04:51 D MANAGEMENT: CMD 'state'

20150910 08:04:51 MANAGEMENT: Client disconnected

20150910 08:04:51 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16

20150910 08:04:51 D MANAGEMENT: CMD 'log 500'

19700101 00:00:00

digitalnomad · 09/10/2015

I have similar problem. iOS OpenVPN client silently disconnect very often because more than 3 concurrent (fake) sessions. I think their system doesn't handle too many connections/disconnections in a short time, so... authentication error and the client silently give up and stay disconnected until I see it and manually reconnect. It means very unsafe data leak.

Anyway I opened a well documented ticket 1 week ago, they are investigating. Now I'm sadly happy to not be the only one

Staff · 09/10/2015

On 9/10/2015 at 9:03 AM, Verby said:
I'm thinking the difference in dangling socket number is likely due to the difference between udp and tcp protocols, but I'm open to being mistaken about this.

Hello!

That's correct. UDP is connectionless, so when a client loses the connection to the VPN server and is unable to notify the server, the server has no way to know that the client is no more there. The VPN server will assume that the client is no more connected after the ping timeout and the system will accordingly free up the connection slot. With TCP this problem does not occur because the server almost-immediately knows of a client disconnection, even if not explicitly notified about it by the OpenVPN client.

On 9/10/2015 at 9:03 AM, Verby said:
My ability to make more attempts is limited because I am bed-bound with a chronic illness, it eats most of my energy and makes my hands numb and painful. It interferes with my ability to use a keyboard, so most of my attempts are restricted to iPad only.

I've had this connection problem in my iPad app for over 3 months now, after many months of issue-free happy use it manifested suddenly and never went away. I've only recently managed to get my dd-wrt router connected to the internet and I hoped its vpn client would resolve my vpn connection issues. I saw it doing the same old familiar failures right from the start, so I'm wondering if my isp might be interfering somehow (LLU account with Vivaciti in the UK). Weirdly, I can still connect to airvpn in port 443/udp with the tunnelblick client on my MacBook (OSX 10.6.8 Snow Leopard).

But since my ability to use my laptop keyboard is severely restricted by my illness, I need a more iPad-friendly solution.

Now that you have managed to connect your DD-WRT router to our service, you could connect your iPad to your router and have its traffic tunneled "transparently". Regardless of the amount of the devices connected to the router, our system will only see one connection, thus only one connection slot will be "busy" for your account.

About the strange logs from OpenVPN in DD-WRT (connection/disconnection series warned by the OpenVPN management) that could be just a glitch of the OpenVPN management. To determine whether it's the case, browse (with your iPad connected to the DD-WRT router, while the router is allegedly tunneling traffic) to airvpn.org and verify whether the central bottom box is green or red.

If it's green then the traffic is properly tunneled (airvpn.org sees your connection coming from one of the exit-IP addresses of the Air VPN servers). If it's red something is wrong, in this case feel free to open a ticket and send us at your convenience the screenshots of the DD-WRT OpenVPN client configuration panel and/or re-check configuration with our instructions https://airvpn.org/ddwrt

Kind regards

Verby · 09/11/2015

Thank you very much digitalnomad and Staff for your replies.

On 9/10/2015 at 9:18 PM, Staff said:
Now that you have managed to connect your DD-WRT router to our service, you could connect your iPad to your router and have its traffic tunneled "transparently". Regardless of the amount of the devices connected to the router, our system will only see one connection, thus only one connection slot will be "busy" for your account.

That was totally my plan!

And it all works, except for the VPN part ...

On 9/10/2015 at 9:18 PM, Staff said:
About the strange logs from OpenVPN in DD-WRT (connection/disconnection series warned by the OpenVPN management) that could be just a glitch of the OpenVPN management. To determine whether it's the case, browse (with your iPad connected to the DD-WRT router, while the router is allegedly tunneling traffic) to airvpn.org and verify whether the central bottom box is green or red.

I'm sorry, I guess I wasn't clear, I was trying to describe the VPN connection failures from my openvpn connect iPad app AND from my dd-wrt router, they both are absolutely failing to connect at all.

Yes, the dd-wrt router does connect to the intartoobz, but only nakedly, with the vpn client disabled. The VPN part of my dd-wrt router plan has so far failed every single time. So your kind troubleshooting suggestion is unfortunately beyond my reach. :/

(emo drama)

Oh NOEZ. My iPad and air's VPN service have sadly been torn asunder! ACK.

(insert back-of-hand-on-forehead eyerolls-up-to-heaven woe-is-me pose here)

(/emo drama)

So right now my iPad, which is my only access to the intartoobz, only has a naked connection, and you can see that I really need some kind of a solution. :/

I enclose the logs from another failed TCP/port 443/UK server connection attempt from my openvpn connect iPad app. I can see that this log looks different from the dd-wrt openvpn client log, but I am just as clueless how to fix it. I hope they help you diagnose something.

I really appreciate your help, thank you.

2015-09-11 09:50:33 ----- OpenVPN Start -----

2015-09-11 09:50:33 LZO-ASYM init swap=0 asym=1

2015-09-11 09:50:33 Comp-stub init swap=0

2015-09-11 09:50:33 EVENT: RESOLVE

2015-09-11 09:50:33 Contacting 84.39.117.56:443 via TCP

2015-09-11 09:50:33 EVENT: WAIT

2015-09-11 09:50:33 Connecting to gb.vpn.airdns.org:443 (84.39.117.56) via TCPv4

2015-09-11 09:50:33 EVENT: CONNECTING

2015-09-11 09:50:33 Tunnel Options:V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client

2015-09-11 09:50:33 Peer Info:

IV_VER=1.0

IV_PLAT=ios

IV_NCP=1

IV_SNAPPY=1

IV_LZO=1

IV_LZO_SWAP=1

IV_COMP_STUB=1

2015-09-11 09:50:34 VERIFY OK: depth=0

cert. version : 3

serial number : 3D

issuer name : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org

subject name : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org

issued on : 2014-04-11 10:44:24

expires on : 2024-04-08 10:44:24

signed using : RSA+SHA1

RSA key size : 4096 bits

2015-09-11 09:50:38 Client exception in transport_recv_excode: PolarSSL: SSL read error : SSL - Verification of the message MAC failed

2015-09-11 09:50:38 Client terminated, restarting in 2...

2015-09-11 09:50:40 EVENT: RECONNECTING

2015-09-11 09:50:40 LZO-ASYM init swap=0 asym=1

2015-09-11 09:50:40 Comp-stub init swap=0

2015-09-11 09:50:40 EVENT: RESOLVE

2015-09-11 09:50:40 Contacting 84.39.117.56:443 via TCP

2015-09-11 09:50:40 EVENT: WAIT

2015-09-11 09:50:40 Connecting to gb.vpn.airdns.org:443 (84.39.117.56) via TCPv4

2015-09-11 09:50:40 EVENT: CONNECTING

2015-09-11 09:50:40 Tunnel Options:V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client

2015-09-11 09:50:40 Peer Info:

IV_VER=1.0

IV_PLAT=ios

IV_NCP=1

IV_SNAPPY=1

IV_LZO=1

IV_LZO_SWAP=1

IV_COMP_STUB=1

2015-09-11 09:50:40 VERIFY OK: depth=0

cert. version : 3

serial number : 3D

issuer name : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org

subject name : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org

issued on : 2014-04-11 10:44:24

expires on : 2024-04-08 10:44:24

signed using : RSA+SHA1

RSA key size : 4096 bits

2015-09-11 09:51:24 Session invalidated

2015-09-11 09:51:24 Client terminated, restarting in 2...

2015-09-11 09:51:26 EVENT: RECONNECTING

2015-09-11 09:51:26 LZO-ASYM init swap=0 asym=1

2015-09-11 09:51:26 Comp-stub init swap=0

2015-09-11 09:51:26 EVENT: RESOLVE

2015-09-11 09:51:26 Contacting 84.39.117.56:443 via TCP

2015-09-11 09:51:26 EVENT: WAIT

2015-09-11 09:51:26 Connecting to gb.vpn.airdns.org:443 (84.39.117.56) via TCPv4

2015-09-11 09:51:26 EVENT: CONNECTING

2015-09-11 09:51:26 Tunnel Options:V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client

2015-09-11 09:51:26 Peer Info:

IV_VER=1.0

IV_PLAT=ios

IV_NCP=1

IV_SNAPPY=1

IV_LZO=1

IV_LZO_SWAP=1

IV_COMP_STUB=1

2015-09-11 09:51:27 VERIFY OK: depth=0

cert. version : 3

serial number : 3D

issuer name : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org

subject name : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, emailAddress=info@airvpn.org

issued on : 2014-04-11 10:44:24

expires on : 2024-04-08 10:44:24

signed using : RSA+SHA1

RSA key size : 4096 bits

2015-09-11 09:51:33 EVENT: CONNECTION_TIMEOUT [ERR]

2015-09-11 09:51:33 EVENT: DISCONNECTED

2015-09-11 09:51:33 Raw stats on disconnect:

BYTES_IN : 16358

BYTES_OUT : 15028

PACKETS_IN : 71

PACKETS_OUT : 124

REPLAY_ERROR : 6

SSL_ERROR : 1

KEEPALIVE_TIMEOUT : 1

CONNECTION_TIMEOUT : 1

N_RECONNECT : 2

2015-09-11 09:51:33 Performance stats on disconnect:

CPU usage (microseconds): 10742192

Network bytes per CPU second: 2921

Tunnel bytes per CPU second: 0

2015-09-11 09:51:33 ----- OpenVPN Stop -----

2015-09-11 09:51:33 EVENT: DISCONNECT_PENDING

Staff · 09/11/2015

@Verby

The DD-WRT OpenVPN client logs you posted in your previous message showed a successful connection. Please proceed to test as we told you to, in order to verify whether the traffic is properly tunneled or not. When/if something goes wrong open a ticket.

Kind regards

Verby · 09/13/2015

Hello there,

Staff, after doing some poking around, I am delighted to confirm that you were right about my dd-wrt VPN being connected successfully, that's so awesome!

I thought my vpn was unconnected because when my iPad connected to the dd-wrt router, I couldn't load web pages, ping websites, do DNS lookups nor do traceroutes, which led me to assume that my connection was, well, unconnected.

I'm delighted to be wrong! Woot.

After some initial poking around, I observed that I was able to ping web addresses if I entered them as ip numbers, albeit with no ping replies received (from sites previously pinged successfully from a naked connection). I began to suspect a hostname resolution problem.

I experimented with my iPad network settings, the most functional for me so far is pointing the iPad at the dd-wrt router's own ip address to use as dns server for itself, and pointing the iPad at one of https://dns.watch/index 's dns servers to use when connected to my gateway router. (putting the tcp local VPN server in either and both has so far disconnected the vpn every time)

But before getting my dd-wrt vpn client to connect successfully, I had needed to tweak some of the settings itemised on the http://airvpn.org/ddwrt page

My tweaks in no particular order:

1. On the dd-wrt Settings/Basic Setup page I removed the Static DNS 1, local tcp vpn dns server entry, reverting it to the default all 0's

2. On the Services/VPN page I changed the local ip address field from the dd-wrt router's (as specified at https://airvpn.org/ddwrt ) to the ip address of the gateway router/modem

3. On the Administration/Commands page I deleted the line 3 "-I INPUT -i tun0 -j REJECT" iptables rule

When I try to un-tweak any individual one of those steps back to resemble the airvpn.org/ddwrt page more closely, my VPN disconnects. So ... having now observed evidence of hostname resolution issues, I've been trying to establish alternative routes for domain-name resolution.

Many of my attempted "fixes" ALSO disconnected my vpn.

Surprise!

And ... Oops.

(I lied. Me breaking stuff wasn't really a surprise. Oh well.)

After that, the first thing I tried which didn't also disconnect my vpn (woot!) was replacing the blank Static DNS 1 & 2 entries with server IPs from https://dns.watch/index .

Then I was able to use Net Analyzer (iPad networking app) to do DNS lookups and ping hostnames, though still with no ping replies received. I was also able to initiate traceroutes, also with no server replies received, so more and more empty steps just kept adding onto the route and I had to terminate the operations manually.

However, even with my dd-wrt router's New & Improved ability to resolve hostnames with its openvpn client connected, when connected to it I still can't get any web page to load in any browser, even if entered numerically as an ip address. And Net Analyzer can't complete connection speed tests either.

Via my gateway router's naked connection, I can sign into airvpn.org and see the dd-wrt router's successful VPN connection in the list of clients connected on my account - and when connected that way, the bottom of air's web page has the red "not connected" rectangle, of course.

So far, when intartoobing through the vpn router, web pages remain unreachable to me - so logging into air's website to see if the bottom of it shows my successful connection is still rather problematic for me.

But I'm working on it.

To me, these issues look less like me-specific-airvpn-specific, and more like personal-networking-could-happen-with-any-vpn-service. I could easily be wrong about this, I'm sure. It's just that, when web searching for help, most of the results I found were about vpn dns leaks - relatively few results addressed vpn dns-including-but-not-limited-to-unresolved-hostnames-etc. If this issue does turn out to be the latter, then I thought solving it in this thread might be helpful to somebody in future.

I did find some help on the web, but not enough to fix everything.

Of course, I wouldn't be surprised if I were dns-leaky, and/or my tweaks made me dns-leaky, and/or dns-leaks were my sole problem all along, and/or my issue(s) were something else entirely, or ... So I look forward to learning whatever new knowledge this issue-troubleshoot brings up.

In any case, if this does turn out to be a personal-to-me airvpn-specific issue, then of course I'll open a support ticket for it.

Also, if I could get my openvpn connect ipad app to establish a successful vpn connection, that would be extra awesome too.

Just saying.

Thank you so much, I really appreciate your help.

==========

EDIT:

ps: I forgot to say, I was interested to note that the OBi110 VoIP box I have plugged in by ethernet to my dd-wrt router has been working perfectly, with calls outgoing and received being routed through my chosen service providers and billed correctly just as I'd hope. I don't know what's up with that but I hope it keeps on working.

EDIT 02:

pps: I also forgot to say that in my gateway router, I have port 443 tcp/udp forwarded to the dd-wrt router. If I try any other ports I'll forward those too, of course. Just thought I'd mention it.

Sign In

Persistent connection failures with multi rapid connect/disconnects and dangling sockets in different clients, please help?

Recommended Posts

Verby 1

Share this post

Link to post

digitalnomad 0

Share this post

Link to post

Staff 10118

Share this post

Link to post

Verby 1

Share this post

Link to post

Staff 10118

Share this post

Link to post

Verby 1

Share this post

Link to post

Join the conversation

Home

Community