dperson / openvpn-client

GNU Affero General Public License v3.0
1.06k stars 588 forks source link

PIA VPN connection stopped working #345

Open snooze92 opened 3 years ago

snooze92 commented 3 years ago

I'm using Docker compose, and my docker-compose.yml file starts with this:

version: '3.7'
services:

  vpn:
    container_name: vpn
    image: dperson/openvpn-client:latest
    restart: unless-stopped
    cap_add:
      - net_admin
    security_opt:
      - label:disable
    read_only: true
    tmpfs:
      - /run
      - /tmp
    ports:
      - "8112:8112"
      - "9117:9117"
    environment:
      - PUID=1000 # snooze92
      - PGID=1000 # snooze92
      - TZ=Europe/Amsterdam
    volumes:
      - /dev/net:/dev/net:z
      - ${HOME}/.vpn:/vpn
    command: -r '192.168.178.0/24'

Since about a week, it seems that my other containers that depend on the vpn container for networking (e.g. Jackett, Deluge...) are having network issues. I haven't changed any configuration, I'm not sure why it stopped working...

I'm using this image:

$ docker images | grep vpn
dperson/openvpn-client      latest              40876b9dd828        4 months ago        20MB

$ docker ps | grep vpn
c518b21a74ac        dperson/openvpn-client:latest   "/sbin/tini -- /usr/…"   32 hours ago        Up 32 hours (unhealthy)   0.0.0.0:8112->8112/tcp, 0.0.0.0:9117->9117/tcp   vpn

docker ps shows that container is "unhealthy", but I'm not sure what that is based on. When I docker exec in the running vpn container, local ping commands seem to work, but external IPs do not:

bash-5.0# ping 172.18.0.2 
PING 172.18.0.2 (172.18.0.2): 56 data bytes
64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.189 ms
64 bytes from 172.18.0.2: seq=1 ttl=64 time=0.196 ms
^C
--- 172.18.0.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.189/0.192/0.196 ms

bash-5.0# ping 192.168.178.12
PING 192.168.178.12 (192.168.178.12): 56 data bytes
64 bytes from 192.168.178.12: seq=0 ttl=63 time=2.717 ms
64 bytes from 192.168.178.12: seq=1 ttl=63 time=83.051 ms
64 bytes from 192.168.178.12: seq=2 ttl=63 time=217.569 ms
64 bytes from 192.168.178.12: seq=3 ttl=63 time=96.307 ms
^C
--- 192.168.178.12 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 2.717/99.911/217.569 ms

bash-5.0# ping 192.168.178.1
PING 192.168.178.1 (192.168.178.1): 56 data bytes
64 bytes from 192.168.178.1: seq=0 ttl=63 time=2.969 ms
64 bytes from 192.168.178.1: seq=1 ttl=63 time=1.257 ms
^C
--- 192.168.178.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 1.257/2.113/2.969 ms

bash-5.0# ping 216.58.214.4
PING 216.58.214.4 (216.58.214.4): 56 data bytes
ping: sendto: Operation not permitted

bash-5.0# ping 212.102.35.101
PING 212.102.35.101 (212.102.35.101): 56 data bytes
ping: sendto: Operation not permitted

bash-5.0# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Operation not permitted

docker-compose logs shows this repeating constantly:

vpn            | Fri Nov 27 20:35:25 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
vpn            | Fri Nov 27 20:35:25 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]212.102.35.104:1198
vpn            | Fri Nov 27 20:35:25 2020 UDP link local: (not bound)
vpn            | Fri Nov 27 20:35:25 2020 UDP link remote: [AF_INET]212.102.35.104:1198
vpn            | Fri Nov 27 20:35:55 2020 [UNDEF] Inactivity timeout (--ping-restart), restarting
vpn            | Fri Nov 27 20:35:55 2020 SIGUSR1[soft,ping-restart] received, process restarting
vpn            | Fri Nov 27 20:40:55 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
vpn            | Fri Nov 27 20:40:55 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]212.102.35.101:1198
vpn            | Fri Nov 27 20:40:55 2020 UDP link local: (not bound)
vpn            | Fri Nov 27 20:40:55 2020 UDP link remote: [AF_INET]212.102.35.101:1198
vpn            | Fri Nov 27 20:41:25 2020 [UNDEF] Inactivity timeout (--ping-restart), restarting
vpn            | Fri Nov 27 20:41:25 2020 SIGUSR1[soft,ping-restart] received, process restarting

In /vpn, I have a Mediabox.ovpn file:

client
dev tun
proto udp
remote nl.privateinternetaccess.com 1198
resolv-retry infinite
nobind
persist-key
# persist-tun # disable to completely reset vpn connection on failure
cipher aes-128-cbc
auth sha1
tls-client
remote-cert-tls server

auth-user-pass /vpn/auth # to be reachable inside the container
compress
verb 1
reneg-sec 0
crl-verify /vpn/crl.rsa.2048.pem # to be reachable inside the container
ca /vpn/ca.rsa.2048.crt # to be reachable inside the container
disable-occ

keepalive 10 30 # send a ping every 10 sec and reconnect after 30 sec of unsuccessfull pings
pull-filter ignore "auth-token" # fix PIA reconnection auth error that may occur every 8 hours

How can I troubleshoot this further?

snooze92 commented 3 years ago

I checked the latest OpenVPN files provided by PIA (https://www.privateinternetaccess.com/openvpn/openvpn.zip) and the netherlands.ovpn file had two notable changes since last time I checked:

I changed my Mediabox.ovpn file to match:

--- Mediabox.ovpn.old   2020-11-27 21:22:56.155264528 +0100
+++ .vpn/Mediabox.ovpn  2020-11-27 21:23:35.604124135 +0100
@@ -3,7 +3,7 @@
 client
 dev tun
 proto udp
-remote nl.privateinternetaccess.com 1198
+remote nl-amsterdam.privacy.network 1198
 resolv-retry infinite
 nobind
 persist-key
@@ -17,8 +17,61 @@
 compress
 verb 1
 reneg-sec 0
-crl-verify /vpn/crl.rsa.2048.pem # to be reachable inside the container
-ca /vpn/ca.rsa.2048.crt # to be reachable inside the container
+
+<crl-verify>
+-----BEGIN X509 CRL-----
+(...)
+-----END X509 CRL-----
+</crl-verify>
+
+<ca>
+-----BEGIN CERTIFICATE-----
+(...)
+-----END CERTIFICATE-----
+</ca>
+
 disable-occ

 keepalive 10 30 # send a ping every 10 sec and reconnect after 30 sec of unsuccessfull pings

After the last restart, it works. I have to admit, I am not sure whether one of these changes fixed anything, or if it was just the restart. I hope it keeps on working, now! :)