You are not logged in.
Hello!
I've had the private-internet-access-vpn package from AUR installed for quite a while and it worked fine. The last month or so the couple of times I've tried to use it it does not work and I'm unsure as to why that is. It's able to connect through the NetworkManager app and I also run it manually via the openvpn command. My username/password are correct as well.
Here is the result of running the openvpn command
❯ sudo openvpn --config /etc/openvpn/client/US_Texas.conf
Thu Nov 30 10:34:01 2017 OpenVPN 2.4.4 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 26 2017
Thu Nov 30 10:34:01 2017 library versions: OpenSSL 1.1.0g 2 Nov 2017, LZO 2.10
Thu Nov 30 10:34:01 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Thu Nov 30 10:34:01 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]162.216.46.164:1198
Thu Nov 30 10:34:01 2017 UDP link local: (not bound)
Thu Nov 30 10:34:01 2017 UDP link remote: [AF_INET]162.216.46.164:1198
Thu Nov 30 10:34:01 2017 [1d84443dcd6fec5be3e819583edeb1fb] Peer Connection Initiated with [AF_INET]162.216.46.164:1198
Thu Nov 30 10:34:02 2017 auth-token received, disabling auth-nocache for the authentication token
Thu Nov 30 10:34:02 2017 TUN/TAP device tun0 opened
Thu Nov 30 10:34:02 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Nov 30 10:34:02 2017 /usr/bin/ip link set dev tun0 up mtu 1500
Thu Nov 30 10:34:02 2017 /usr/bin/ip addr add dev tun0 local 10.62.10.6 peer 10.62.10.5
Thu Nov 30 10:34:02 2017 /etc/openvpn/update-resolv-conf.sh tun0 1500 1558 10.62.10.6 10.62.10.5 init
dhcp-option DNS 209.222.18.222
dhcp-option DNS 209.222.18.218
Thu Nov 30 10:34:02 2017 Initialization Sequence Completed
^CThu Nov 30 10:34:45 2017 event_wait : Interrupted system call (code=4)
Thu Nov 30 10:34:45 2017 /usr/bin/ip addr del dev tun0 local 10.62.10.6 peer 10.62.10.5
Thu Nov 30 10:34:45 2017 /etc/openvpn/update-resolv-conf.sh tun0 1500 1558 10.62.10.6 10.62.10.5 init
Thu Nov 30 10:34:45 2017 SIGINT[hard,] received, process exiting
Offline
what does 'there is no web access' mean?
Offline
what does 'there is no web access' mean?
It means that when I connect to the VPN, websites don't load and just time out. Also when I ping google.com for example, I get no response back.
Offline
It means that when I connect to the VPN, websites don't load and just time out. Also when I ping google.com for example, I get no response back.
Is google.com resolved to an ip address after starting the VPN? If so is it resolved by the the DNS server provided by the VPN?
Is the routing table updated after starting the VPN to add a new default route?
Offline
Alright folks and OP, what kernel version do you use? I was recently very surprised revealing out none of VPN-nm connection work either. Got the same symthoms with linux-lts 4.9.67-1. Journal was fullfilled by a lot of martian packets and TLS negotiation failures finally exceeding the ping-restart threshold. There is no DNS resolving on the VPN side, neither a single transfer. Tried to debug this issue using a wireshark sniff on the tun interface - a lot of tcp renegotiation packets and malformed OVPN protocol packets appeared. (in the same time TLS negotiation was logged in journald)
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, process restarting
VPN connection working without any problem on the linux-lts 4.9.66-1 as well on the 4.14.4-1.
Also tried to resolve this turning off path filtering mechanism in the kernel itself (net.ipv4.conf.all.rp_filter = 0) with no luck.
Im 100% sure its something with the latest LTS commit, but Im not so tech'y and unable to aim it.
Routing table is updated and everything seems to work normal, but no transfer starts as in the case of OP.
kind regards.
Offline
@Al.Piotrowicz the initial post was in November before the release of 4.9.67-1
Offline
@loqs It's true, but instead of starting new thread (what I found pointless) tried to describe the problem in this one. For me the earlier versions worked flawless. The problem has started with 4.9.67-1 here. Due to lack of knowledge I'm unable to say what exactly is causing this weird problem, but the ONLY thing I did since it worked was installing the 4.9.67-1 version. Thanks for advance.
Offline
https://cdn.kernel.org/pub/linux/kernel … Log-4.9.67 does not contain anything directly from the networking tree but it is a relatively small number of commits.
If you bisect between 4.9.66 and 4.9.67 you should be able to find the commit that is causing the issue. Please do build 4.9.66 and 4.967 locally to check that the issue
does appear with one and not the other and that there is not some other cause.
Offline
Alright folks and OP, what kernel version do you use? I was recently very surprised revealing out none of VPN-nm connection work either. Got the same symthoms with linux-lts 4.9.67-1. Journal was fullfilled by a lot of martian packets and TLS negotiation failures finally exceeding the ping-restart threshold. There is no DNS resolving on the VPN side, neither a single transfer. Tried to debug this issue using a wireshark sniff on the tun interface - a lot of tcp renegotiation packets and malformed OVPN protocol packets appeared. (in the same time TLS negotiation was logged in journald)
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) TLS Error: TLS handshake failed SIGUSR1[soft,tls-error] received, process restarting
VPN connection working without any problem on the linux-lts 4.9.66-1 as well on the 4.14.4-1.
Also tried to resolve this turning off path filtering mechanism in the kernel itself (net.ipv4.conf.all.rp_filter = 0) with no luck.Im 100% sure its something with the latest LTS commit, but Im not so tech'y and unable to aim it.
Routing table is updated and everything seems to work normal, but no transfer starts as in the case of OP.kind regards.
Sorry for the late response. I'm on 4.14.4-1-ARCH as of right now and I just hooked up to the VPN and same symptoms.
Offline
SirMyztiq wrote:It means that when I connect to the VPN, websites don't load and just time out. Also when I ping google.com for example, I get no response back.
Is google.com resolved to an ip address after starting the VPN? If so is it resolved by the the DNS server provided by the VPN?
Is the routing table updated after starting the VPN to add a new default route?
Hello!
Thanks for responding. Sorry for the late response I was away from my home computer.
Could you give me some pointers in how to diagnose and obtain the information you are asking for?
This is the only line that returns after I ping google.com
PING google.com (216.58.218.174) 56(84) bytes of data.
Last edited by SirMyztiq (2017-12-12 01:11:25)
Offline
So google.com is resolved to an IP address. To see if that answer is coming from the VPN's DNS install dig then run `dig google.com` in the response look at the ;; SERVER line which is the DNS that responded.
For the routing table run `ip route` before starting the VPN then start the VPN and repeat the command are the results the same?
Offline
So google.com is resolved to an IP address. To see if that answer is coming from the VPN's DNS install dig then run `dig google.com` in the response look at the ;; SERVER line which is the DNS that responded.
For the routing table run `ip route` before starting the VPN then start the VPN and repeat the command are the results the same?
Thanks for the help!
Before and after connecting to the VPN, I ran
dig google.com
and I noticed that the ";; SERVER" line did not change! My resolv.conf file was updated with the DNS address of my VPN but they were both after my default DNS address, I'm not sure if that matters though.
I also checked the routing tables and they do in fact change after connecting to the VPN.
Offline
Sorry for the late response. I'm on 4.14.4-1-ARCH as of right now and I just hooked up to the VPN and same symptoms.
Sounds the bug issue could be caused by the different factor. Sorry for the confusion my posts could make, but I will track the thread with interest, because symptoms seems to be the same here.
Offline
$ nmap -p 1194,1198 162.216.46.164
Starting Nmap 7.60 ( https://nmap.org ) at 2017-12-15 23:17 CET
Nmap scan report for 162.216.46.164
Host is up (0.16s latency).
PORT STATE SERVICE
1194/tcp closed openvpn
1198/tcp closed cajo-discovery
Nmap done: 1 IP address (1 host up) scanned in 0.58 seconds
Sure that config (comes with the AUR??) is good?
Offline