One spurious OpenVPN client connection among many failures

[CarribbeanPrivate]

I'm trying to establish a VPN on my RT-N66R, flashed with Merlin 376.48_3

Troubleshooting log is here:http://pastebin.com/kRc8GwfB

In the midst of my troubleshooting this morning, I had a connection succeed (details noted at line 150 in the log). Curiously, this was immediately following implementing a change to verbose logging. I suspect this is a coincidence, as I have been unable to re-create (tunnel failed after 5 minutes, can't get it back).

Major error is that the TLS negotiation fails to occur with 60 seconds, causing a re-start. With the exception of the one time, I never get a UDP read (only writes, up to 70 bytes - 14x5 tries).

Could this be ISP blocking & I happened to get through once? The log starts as I shifted away from TCP port 443 in an attempt to bypass any potential ISP interference.

Thanks!

 

[RMerlin]

Check the protocol. You mentions TCP 443, yet your log shows you are using UDP.

 

[CarribbeanPrivate]

Sorry for the confusion.

Lines 26-34 in the troubleshooting log is where I shifting back to UDP1194, since TCP443 was not getting me anywhere (previous TCP troubleshooting not covered by the uploaded log).

Since all of the router logs I included are after that point, they do reflect the UDP protocol.

 

[Deleted member 27741]

Just a guess here, but testing of the VPN should be done outside your local network. Use your phone hotspot or some other network. I have run into this same TLS failure and it was caused by trying to connect while at home.

Confounding the issue, TAP connects fine from home, while TUN will not. If you are the kind of guy that connects to (for whatever reason) your VPN from home, TAP is your Huckleberry.

Here is what happens when I try to connect to my OPENVPN server that uses TUN from home, the same configuration works perfectly if I connect to my phone hotspot (a different network than the N66U)-

TLS: Initial packet from [AF_INET]192.168.x.x:58974, sid=xxxxxxxx xxxxxxxx
Nov 29 18:29:46 openvpn[1425]: 192.168.x.x:58974 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Nov 29 18:29:46 openvpn[1425]: 192.168.x.x:58974 TLS Error: TLS handshake failed
Nov 29 18:29:46 openvpn[1425]: 192.168.x.x:58974 SIGUSR1[soft,tls-error] received, client-instance restarting

 

[john9527]

I think I saw in another post that you are trying to get a Private Internet Access OpenVPN client running...correct? I run 24x7 with all my traffic routed through it, so it does work.

Can you post/link a screen shot of the setup page you are using (hide your userid and password)? maybe we can spot something. The setup I use is really very minimal.

 

[CarribbeanPrivate]

@000111,

Unable, as I'm about as isolated as you can get when it comes to services - I know people who literally have better internet access in-theatre overseas. There is no cellular data service available, we're outside the range of most satellite providers, and no fiber anywhere near my area. The community's entire internet is channeled through one of two commercial satellite dishes - hence my question about latency in the other thread. Ping to Level3 DNS 4.2.2.3 == 700ms right now.

Also, the computer client connects reliably - so I know it's possible from my home network. Doesn't matter if it's set to TCP443 or UDP1194. Problem is multiple devices that I need to protect, so looking to use the router.

@John,

Absolutely. My current setup deviates from the PIA advice originally followed here:
https://www.privateinternetaccess.c...-setup-for-newer-branches-including-tomatousb

and the advice I received from the .opvn file from the Tier 1 support here:
http://pastebin.com/4fiEeyHz

Not shown is the ca.crt that is stored in the Certificate Authority dialog (It does include the full --begin-- and --end-- lines).

Current screenshots are attached; how I got there is detailed in the log from my original post - I haven't changed anything beyond that t/s log yet, as I had it breathing for six minutes this morning... very frustrating to reach the top & find another false ridgeline there.

 

[john9527]

OK....here are the differences in your setup vs mine

Server Address: I use the url (for me us-west.privateinternetaccess.com) vs the ip address. You should be able to ping the url from your PC even before starting the VPN client. They use a pool of addresses, so by specifying the ip address you may be going to one that happens to be down.

Accept DNS Config - I use 'Strict' vs Disable to help prevent DNS leaks.

Encryption Cipher - Try specifying their default directly as 'BF-CBC' instead of Default. (once we get this working, we can try some undocumented settings I figured out to change to a better cipher).

TLS Renegotiation Time - I use the default of -1 and see the renegotiations in the log, but 0 should be OK.

Connection Retry - I use '30' instead of -1

and here are my custom config options

auth SHA1
mute-replay-warnings
verb 3
inactive 0
keepalive 5 60


Finally, just as double check, the ca.crt gets pasted into the second position, Certificate Authority on that screen. (not trying to be insulting or anything, but I've made mistakes like that myself).

Finally+1 - I see you are using Client 2. Do you have a Client 1 running? If so, you need to shut that one down.

 

[Deleted member 27741]

Wow, sorry about that connection. Maybe you live on a paradise island so it makes up for it.

I notice that you have "redirect internet traffic" set to no. I am not a VPN guru, but wouldn't that nullify some of the main benefits of using your router as a VPN client? Like encrypted and anonymous internet usage?

 

[RMerlin]

Accept DNS Config - I use 'Strict' vs Disable to help prevent DNS leaks.

As a side note, some tunnel providers will even force you to set this, as they will block DNS access to other DNS servers to prevent any DNS-based leak of information.

 

[CarribbeanPrivate]

[Client cycled --> OFF --> ON after each individual change]
[Client ONE and desktop clients both OFF during testing. Using client TWO in an attempt to troubleshoot TWO independently from client ONE via PIA tech support *not overly useful thus far; they just keep regurgitating Tier I response protocols. I don't want to be *that* guy applying two different sources that interfere with fixing the actual problem.]

server set back to us-east...
Accept DNS Config set from Disabled --> Strict
TLS Renegotiation Time from 120 --> default of -1
Connection Retry from -1 --> 30
Encryption set to Blowfish-CBC
Replaced custom config with:
-------
auth SHA1
mute-replay-warnings
verb 3
inactive 0
keepalive 5 60
-------
CA.crt verified in the second position - no ego here; I'd even prefer someone to point out that I was doing something silly like having an ON/OFF problem!

Redirect Internet Traffic --> Yes

**Definitely appears to be an inbound read problem. VPN Status hangs at 70 bytes written, 0 read.


[------Most recent log-----]
Dec 4 23:39:40 rc_service: httpd 367:notify_rc start_vpnclient2
Dec 4 23:39:40 kernel: tun: Universal TUN/TAP device driver, 1.6
Dec 4 23:39:40 kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Dec 4 23:39:40 openvpn[5120]: OpenVPN 2.3.4 mipsel-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Nov 20 2014
Dec 4 23:39:40 openvpn[5120]: library versions: OpenSSL 1.0.0o 15 Oct 2014, LZO 2.08
Dec 4 23:39:40 openvpn[5120]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Dec 4 23:39:40 openvpn[5120]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 4 23:39:40 openvpn[5120]: Socket Buffers: R=[118784->131072] S=[118784->131072]
Dec 4 23:39:40 openvpn[5124]: UDPv4 link local: [undef]
Dec 4 23:39:40 openvpn[5124]: UDPv4 link remote: [AF_INET]209.222.18.43:1194
Dec 4 23:40:12 openvpn[5124]: event_wait : Interrupted system call (code=4)
Dec 4 23:40:12 openvpn[5124]: OpenVPN STATISTICS
Dec 4 23:40:12 openvpn[5124]: Updated,Thu Dec 4 23:40:12 2014
Dec 4 23:40:12 openvpn[5124]: TUN/TAP read bytes,0
Dec 4 23:40:12 openvpn[5124]: TUN/TAP write bytes,0
Dec 4 23:40:12 openvpn[5124]: TCP/UDP read bytes,0
Dec 4 23:40:12 openvpn[5124]: TCP/UDP write bytes,70
Dec 4 23:40:12 openvpn[5124]: Auth read bytes,0
Dec 4 23:40:12 openvpn[5124]: pre-compress bytes,0
Dec 4 23:40:12 openvpn[5124]: post-compress bytes,0
Dec 4 23:40:18 openvpn[5124]: event_wait : Interrupted system call (code=4)
Dec 4 23:40:18 openvpn[5124]: OpenVPN STATISTICS
Dec 4 23:40:18 openvpn[5124]: Updated,Thu Dec 4 23:40:18 2014
Dec 4 23:40:18 openvpn[5124]: TUN/TAP read bytes,0
Dec 4 23:40:18 openvpn[5124]: TUN/TAP write bytes,0
Dec 4 23:40:18 openvpn[5124]: TCP/UDP read bytes,0
Dec 4 23:40:18 openvpn[5124]: TCP/UDP write bytes,70
Dec 4 23:40:18 openvpn[5124]: Auth read bytes,0
Dec 4 23:40:18 openvpn[5124]: pre-compress bytes,0
Dec 4 23:40:18 openvpn[5124]: post-compress bytes,0
Dec 4 23:40:40 openvpn[5124]: [UNDEF] Inactivity timeout (--ping-restart), restarting
Dec 4 23:40:40 openvpn[5124]: SIGUSR1[soft,ping-restart] received, process restarting
Dec 4 23:40:40 openvpn[5124]: Restart pause, 2 second(s)
Dec 4 23:40:42 openvpn[5124]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Dec 4 23:40:42 openvpn[5124]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 4 23:40:42 openvpn[5124]: Socket Buffers: R=[118784->131072] S=[118784->131072]
Dec 4 23:40:43 openvpn[5124]: UDPv4 link local: [undef]
Dec 4 23:40:43 openvpn[5124]: UDPv4 link remote: [AF_INET]209.222.18.67:1194
Dec 4 23:41:06 openvpn[5124]: event_wait : Interrupted system call (code=4)
Dec 4 23:41:06 openvpn[5124]: OpenVPN STATISTICS
Dec 4 23:41:06 openvpn[5124]: Updated,Thu Dec 4 23:41:06 2014
Dec 4 23:41:06 openvpn[5124]: TUN/TAP read bytes,0
Dec 4 23:41:06 openvpn[5124]: TUN/TAP write bytes,0
Dec 4 23:41:06 openvpn[5124]: TCP/UDP read bytes,0
Dec 4 23:41:06 openvpn[5124]: TCP/UDP write bytes,56
Dec 4 23:41:06 openvpn[5124]: Auth read bytes,0
Dec 4 23:41:06 openvpn[5124]: pre-compress bytes,0
Dec 4 23:41:06 openvpn[5124]: post-compress bytes,0
Dec 4 23:41:37 openvpn[5124]: event_wait : Interrupted system call (code=4)
Dec 4 23:41:37 openvpn[5124]: OpenVPN STATISTICS
Dec 4 23:41:37 openvpn[5124]: Updated,Thu Dec 4 23:41:37 2014
Dec 4 23:41:37 openvpn[5124]: TUN/TAP read bytes,0
Dec 4 23:41:37 openvpn[5124]: TUN/TAP write bytes,0
Dec 4 23:41:37 openvpn[5124]: TCP/UDP read bytes,0
Dec 4 23:41:37 openvpn[5124]: TCP/UDP write bytes,70
Dec 4 23:41:37 openvpn[5124]: Auth read bytes,0
Dec 4 23:41:37 openvpn[5124]: pre-compress bytes,0
Dec 4 23:41:37 openvpn[5124]: post-compress bytes,0
Dec 4 23:41:43 openvpn[5124]: [UNDEF] Inactivity timeout (--ping-restart), restarting
Dec 4 23:41:43 openvpn[5124]: SIGUSR1[soft,ping-restart] received, process restarting
Dec 4 23:41:43 openvpn[5124]: Restart pause, 2 second(s)
Dec 4 23:41:45 openvpn[5124]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Dec 4 23:41:45 openvpn[5124]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 4 23:41:45 openvpn[5124]: Socket Buffers: R=[118784->131072] S=[118784->131072]
Dec 4 23:41:45 openvpn[5124]: UDPv4 link local: [undef]
Dec 4 23:41:45 openvpn[5124]: UDPv4 link remote: [AF_INET]108.61.55.77:1194

 

[john9527]

Let's try turning off encryption as a test....

Port: 1195
Encryption cipher: None