Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keeps Restarting #117

Open
dcbell opened this issue Oct 13, 2024 · 1 comment
Open

Keeps Restarting #117

dcbell opened this issue Oct 13, 2024 · 1 comment

Comments

@dcbell
Copy link

dcbell commented Oct 13, 2024

Starting today my VPN won't stay connected. When looking at the docker logs, I see it make a connection, get to the Adding route step, then about 2 minutes later it says "Shutting down WireGuard" and starts over again.

Log:

Sun Oct 13 19:14:08 UTC 2024: Shutting down WireGuard
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0
[#] resolvconf -d wg0 -f
could not detect a useable init system
[#] iptables-restore -n
iptables-restore: line 6 failed: Bad rule (does a matching rule exist in that chain?).
Fetching next-gen PIA server list
Verified OK
Verified server list
Registering public key with PIA endpoint; id: us3, cn: phoenix414, ip: 184.170.242.157
Generating /etc/wireguard/wg0.conf
Using PIA DNS servers: 10.0.0.243,10.0.0.242
Port forwarding is not available at this location
Successfully generated /etc/wireguard/wg0.conf
Sun Oct 13 19:14:09 UTC 2024: Bringing up WireGuard interface wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.22.237.79 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a wg0 -m 0 -x
could not detect a useable init system
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] iptables-restore -n
interface: wg0
  public key: 0o2OGoD+C1x4+A5DBVbjWYgxh/NNw02AoD7GRMhmQWE=
  private key: (hidden)
  listening port: 33771
  fwmark: 0xca6c
peer: PRHPwKh9cnlCNXJe1duQW5GK3X91dF2rXnKziGy4qHA=
  endpoint: 184.170.242.157:1337
  allowed ips: 0.0.0.0/0
Sun Oct 13 19:14:09 UTC 2024: WireGuard successfully started
Sun Oct 13 19:14:09 UTC 2024: Allowing network access to 172.18.0.6/16 on eth0
Sun Oct 13 19:14:09 UTC 2024: Firewall enabled: Blocking non-WireGuard traffic
Sun Oct 13 19:14:09 UTC 2024: Allowing network access to 10.0.0.0/8 on eth0
Sun Oct 13 19:14:09 UTC 2024: Adding route to 10.0.0.0/8
Sun Oct 13 19:15:28 UTC 2024: Shutting down WireGuard

Compose file (relevant portion):

  vpn:
    image: thrnz/docker-wireguard-pia
    container_name: vpn
    volumes:
      - ${CONFIG_ROOT:-.}/pia:/pia
      - ${CONFIG_ROOT:-.}/pia-shared:/pia-shared
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    environment:
      - LOC=${PIA_LOCATION}
      - USER=${PIA_USER}
      - PASS=${PIA_PASS}
      - LOCAL_NETWORK=${PIA_LOCAL_NETWORK}
      - PORT_FORWARDING=0
      - PORT_PERSIST=1
      - PORT_SCRIPT=/pia-shared/portupdate-qbittorrent.sh
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
      - net.ipv6.conf.default.disable_ipv6=1
      - net.ipv6.conf.all.disable_ipv6=1
      - net.ipv6.conf.lo.disable_ipv6=1
    healthcheck:
      test: ping -c 1 www.google.com || exit 1
      interval: 30s
      timeout: 10s
      retries: 3
    restart: always
@thrnz
Copy link
Owner

thrnz commented Oct 13, 2024

Sun Oct 13 19:15:28 UTC 2024: Shutting down WireGuard

I think that message is only shown when the container is brought down by Docker itself. Without any custom scripts, I don't think a shutdown can be triggered from within the container itself.

It looks like the restart is happening about 90s after the container starts. It might just be a conincidence, and I'm not sure how the timers work, but thats roughly the healthcheck's interval * retries value. It also looks like the LOCAL_NETWORK range overlaps with PIA's dns servers (10.0.0.243,10.0.0.242) which can cause lookup issues, which might cause the healthcheck ping to fail. You might be able to work around it by setting something like VPNDNS=1.1.1.1 to use another dns server.

I don't suppose there's anything in your setup that would restart a container after a failed healthcheck? Nothing else comes to mind at the moment, apart from that the restart is likely being trigged from outside the container itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants