You are not logged in.
I'm not able to use a VPN tunnel connection with PIA servers. I've tried using both config files provided from PIA and from the private-internet-access-vpn AUR I can't connect to anything outside my network. I can't even ping the gateway server.
These are some stats:
BEFORE CONNECTING TO VPN
#ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 18:db:f2:14:4c:13 brd ff:ff:ff:ff:ff:ff
3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 84:ef:18:c5:65:a7 brd ff:ff:ff:ff:ff:ff
inet 192.168.29.169/24 brd 192.168.29.255 scope global dynamic wlp1s0
valid_lft 76263sec preferred_lft 76263sec
inet 192.168.29.168/24 brd 192.168.29.255 scope global secondary wlp1s0
valid_lft forever preferred_lft forever
inet6 fe80::beff:43a5:27b7:8bca/64 scope link
valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:31:4f:36:6c brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 scope global docker0
valid_lft forever preferred_lft forever#ip ro
default via 192.168.29.1 dev wlp1s0 src 192.168.29.168 metric 303
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.29.0/24 dev wlp1s0 proto kernel scope link src 192.168.29.168 metric 303 AFTER CONNECTING TO VPN
#ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 18:db:f2:14:4c:13 brd ff:ff:ff:ff:ff:ff
3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 84:ef:18:c5:65:a7 brd ff:ff:ff:ff:ff:ff
inet 192.168.29.169/24 brd 192.168.29.255 scope global dynamic wlp1s0
valid_lft 76082sec preferred_lft 76082sec
inet 192.168.29.168/24 brd 192.168.29.255 scope global secondary wlp1s0
valid_lft forever preferred_lft forever
inet6 fe80::beff:43a5:27b7:8bca/64 scope link
valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:31:4f:36:6c brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 scope global docker0
valid_lft forever preferred_lft forever
19: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
link/none
inet 10.71.10.6 peer 10.71.10.5/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::77d0:f937:a039:4e6a/64 scope link flags 800
valid_lft forever preferred_lft forever#ip ro
0.0.0.0/1 via 10.71.10.5 dev tun0
default via 192.168.29.1 dev wlp1s0 src 192.168.29.168 metric 303
10.71.10.1 via 10.71.10.5 dev tun0
10.71.10.5 dev tun0 proto kernel scope link src 10.71.10.6
104.200.151.28 via 192.168.29.1 dev wlp1s0
128.0.0.0/1 via 10.71.10.5 dev tun0
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.29.0/24 dev wlp1s0 proto kernel scope link src 192.168.29.168 metric 303 This is openvpn output:
Sat Apr 1 16:38:03 2017 OpenVPN 2.4.1 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2017
Sat Apr 1 16:38:03 2017 library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.10
Sat Apr 1 16:38:03 2017 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat Apr 1 16:38:03 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]104.200.151.28:1198
Sat Apr 1 16:38:03 2017 UDP link local: (not bound)
Sat Apr 1 16:38:03 2017 UDP link remote: [AF_INET]104.200.151.28:1198
Sat Apr 1 16:38:03 2017 [1df4675f86f2a3e0c1f8f8b1cadc3f1a] Peer Connection Initiated with [AF_INET]104.200.151.28:1198
Sat Apr 1 16:38:04 2017 TUN/TAP device tun0 opened
Sat Apr 1 16:38:04 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sat Apr 1 16:38:04 2017 /usr/bin/ip link set dev tun0 up mtu 1500
Sat Apr 1 16:38:04 2017 /usr/bin/ip addr add dev tun0 local 10.71.10.6 peer 10.71.10.5
Sat Apr 1 16:38:04 2017 /etc/openvpn/update-resolv-conf.sh tun0 1500 1558 10.71.10.6 10.71.10.5 init
dhcp-option DNS 209.222.18.222
dhcp-option DNS 209.222.18.218
Sat Apr 1 16:38:04 2017 Initialization Sequence Completediptables isn't running.
I ran this command as well:
echo 1 > /proc/sys/net/ipv4/ip_forwardMy router has a VPN server installed. I can connect fine from a different Linux distro (Mint) and from Mac laptop as well using this same router though.
Any suggestions?
Last edited by raxon (2017-04-05 06:33:20)
Offline
I've got no solution for you I'm afraid, however I am experiencing what appears to be the same problem although I am not even able to connect to the VPN so it could be a completely separate issue.. I posted on the forums a few days ago about it but haven't had a working solution yet. Does your browser let you connect to their website? Was your VPN connection working previously?
I will follow your progress and hopefully my solution here as my thread seems to have died.
Offline
No idea what that AUR package does but if your goal is to run a VPN on your home network and connect to it remotely, why not just use OpenVPN directly? You can even run it in a linux container to protect the host OS.
Last edited by graysky (2017-04-02 08:20:34)
Offline
Does your browser let you connect to their website?
When I'm connected to PIA VPNs, no, the browser doesn't connect to anything. Being that I'm not able to ping the gateway, I don't think any packet is leaving my box, but I'm unsure how routing really works though.
However I'm not having certificates problems when accessing their website without being on their VPN. I think you should try to fix that first before troubleshooting your VPN issues.
Was your VPN connection working previously?
That's funny you asked because I was actually able to connect previously, but not always. Sometimes different tries of using OpenVPN command line and then Network Manager would establish the connection properly. Unfortunately this "hack" isn't working any longer.
I will follow your progress and hopefully my solution here as my thread seems to have died.
I checked your thread. I was able to download PIA VPN config files from their site without a problem. I can upload them somewhere so you can have them, but I'm sure you wouldn't want that. ![]()
No idea what that AUR package does but if your goal is to run a VPN on your home network and connect to it remotely, why not just use OpenVPN directly? You can even run it in a linux container to protect the host OS.
I'm actually using OpenVPN directly. The AUR package downloads the config files from PIA and store them into /etc/openvpn/client, changes some file names (PIA added a space to their config files) and updates resolv-conf.
Offline
My connection with PIA works. I use the aur package but not Network Manager. In any case, aside from specific ip's, my openvpn output is identical to yours. Have you tried using different PIA servers?
Offline
No issues here on my work box which happens to use PIA as a backup to Mullvad...
I start dhcpcd and OpenVPN manually by way of systemd (I don't always need to go online):
# systemctl start dhcpcd@enp4s0 openvpn-client@PIAWhat does your OpenVPN client configuration file look like?
Arch Linux + sway
Debian Testing + GNOME/sway
NetBSD 64-bit + Xfce
Offline
My connection with PIA works.
Does your route table look similar to mine after you connect to PIA? I'm thinking it could be something wrong with the routes, but I don't know how to troubleshoot that.
I use the aur package but not Network Manager. In any case, aside from specific ip's, my openvpn output is identical to yours. Have you tried using different PIA servers?
Yes, I have. I tried US Seattle, US California and US West. I'm able to connect to PIA VPNs using my Linux Mint box.
What does your OpenVPN client configuration file look like?
This is a config file I use from the AUR package: gist link
This is what I downloaded from PIA: gist link.
I have set my PIA username/password at /etc/private-internet-access/login.conf when using the AUR config files.
For the config file downloaded from PIA, I pass --auth-user-pass to the openvpn client, so it looks something like:
sudo openvpn --config *Seattle* --auth-user-pass auth.txtOffline
@raxon,
How are you testing your connectivity through the VPN?
Are you specifying the interface to the ping command?
$ ping -I tun0 8.8.8.8The output logs from OpenVPN and your 'ip addr' output look like everything is connected successfully.
Your routing table says that your default route is through your wireless interface wlp1s0. I wonder if this is a routing issue...
Offline
My ip ro output looks quite similar to yours. However, I use a slightly different openvpn command: delete the --auth-user-pass part. That option for me is already specified in the client conf file (the "Seattle" part of your command). I'd also make sure your login.conf doesn't have any errant spaces or line endings.
*Edit: you say you use PIA successfully with Mint. Try diffing the login.conf and Seattle.conf files.
Last edited by monodromy (2017-04-04 18:16:47)
Offline
Do it manually. FYI, neither the AUR nor the PIA configuration you listed is what you want to use.
You will want to use a file which looks like this (based on the PIA restrictive TCP configuration):
client
dev tun
proto udp
remote us-seattle.privateinternetaccess.com 1197
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-256-cbc
auth sha256
tls-client
remote-cert-tls server
auth-user-pass [path to auth file]
auth-nocache
comp-lzo
fast-io
verb 1
reneg-sec 0
crl-verify [path to crl.rsa.4096.pem]
ca [path to ca.rsa.4096.crt]
disable-occ
user nobody
group nobodyI added the following options to further lock down the PIA restrictive configuration:
auth-nocache
user nobody
group nobodyYou can also opt to revert to TCP by modifying the following:
proto tcp
remote us-seattle.privateinternetaccess.com 501You can apply further restrictions if desired. man openvpn ![]()
Last edited by adamlau (2017-04-05 06:12:40)
Arch Linux + sway
Debian Testing + GNOME/sway
NetBSD 64-bit + Xfce
Offline
Thanks @adamlu, I haven't tried using those set of config files and I was able to connect to the Internet now
I'm not sure why it wasn't working before, but I'm happy with the solution as it seems to be safer than what I had before.
Offline