Network is unreachable from client after upgrade to 0.3.0

[zifeo]

As https://github.com/Place1/wg-access-server/issues/85 has been closed without a solution, here is another of a similar blocker.

MacOS Wireguard app show the following logs:

Failed to send handshake initiation write ipd4 0.0.0.0:62400->x.x.x.x:51820: sendto: network is unreachable

loglevel: debug

adminUsername: removed
adminPassword: "removed"

port: 8000
externalHost: removed

wireguard:
  enabled: true
  privateKey: removed
  interface: wg0
  port: 51820

vpn:
  cidr: 10.44.0.0/24
  gatewayInterface: ""
  allowedIPs:
    - removed/32 # specific IP

disableMetadata: false
storage: postgres://removed?sslmode=disable

dns:
  enabled: false
  upstream:
    - "8.8.8.8"

auth:
  gitlab:
    name: "Gitlab"
    baseURL: removed
    clientID: removed
    clientSecret: removed
    redirectURL: removed
    emailDomains: removed

version: "3.7"

networks:
  front:
    external:
      name: removed

volumes:
  postgres:

services:

  wg-access-server:
    image: place1/wg-access-server:0.2.5
    #image: place1/wg-access-server:v0.3.0
    cap_add:
      - NET_ADMIN
    volumes:
      - "./config.yaml:/config.yaml"
    ports:
      - "51820:51820/udp"
    devices:
      - "/dev/net/tun:/dev/net/tun"
    depends_on:
      - db
    networks:
      - front
      - default
    labels:
      - traefik.enable=true
      - traefik.frontend.rule=Host:removed
      - traefik.port=8000
      - traefik.docker.network=front
      - traefik.frontend.redirect.entryPoint=https # this is traffic version 1 still but should not be relevant

  db:
    image: postgres:13
    restart: unless-stopped
    networks:
      - default
    volumes:
      - postgres:/var/lib/postgresql/data
    environment:
      - POSTGRES_ROOT_PASSWORD=removed
      - POSTGRES_PASSWORD=removed
      - POSTGRES_USER=removed
      - POSTGRES_DB=removed

[antoinebou12]

Same issue wg-access-server | time="2020-12-11T22:51:22Z" level=error msg="failed to start dns server: listen udp 0.0.0.0:53: bind: address already in use" file="server.go:51"

[zifeo]

@antoinebou13 Not sure whether this is really the same, sounds rather like you have two services binding to the same port.

@Place1 I confirm that the change you made in #93 has removed the error message I experienced. I have been trying your vanilla docker-compose for all version above 0.2.5 and none is working out of the box (even in different environments - Docker for Mac or Docker on Debian). The WG client successfully connects to server but then all requests time out (they are received by the WG server as confirmed by tcpdump, so the issue must be happening after).

Can you reproduce on your side with this slightly modified version? How can I provide you with more debugging info?

version: "3.0"
services:
  wg-access-server:
    image: place1/wg-access-server:v0.4.6
    container_name: wg-access-server
    cap_add:
      - NET_ADMIN
    volumes:
      - "./data:/data"
    environment:
      - "WG_ADMIN_USERNAME=admin"
      - "WG_ADMIN_PASSWORD=password"
      - "WG_WIREGUARD_PRIVATE_KEY=SL98cjAgH1+Zqv5C8ZjGMFNSmgUIVCtHRtqgvB++HU0="
      - "WG_DNS_ENABLED=false"
    ports:
      - "8000:8000/tcp"
      - "51820:51820/udp"
    devices:
      - "/dev/net/tun:/dev/net/tun"

[Place1]

@zifeo i'm a but stumped to be honest. I deploy wg-access-server with pretty much the exact config you've posted (i have DNS on though).

Are you attempting to connect out to the internet? LAN? or other docker containers on the same host?

I'm a little suspicious that you're problem is related to: https://github.com/Place1/wg-access-server/issues/71

[zifeo]

@Place1 enabling the DNS, and specifying a public one seems to work

 - "WG_DNS_ENABLED=true"                                                                                                                                                                                                                                            
 - "WG_DNS_UPSTREAM=8.8.8.8"

However on local (Docker for Mac), enabling the DNS ends up in a loop (I guess) and thus times out.

Are you able to reproduce the issue if you disable the DNS?

[zifeo]

@Place1 I found the root cause, this part interpreted differently the null string in release 3.0.0-rc1/rc2: https://github.com/Place1/wg-access-server/compare/0.2.5...v0.3.0-rc2#diff-54c7c1af5fa8d5db4dc49f0e8e80e93ba2b1183ba4d5c9e2e5729e6deae6a3cdL158-L165 → https://github.com/Place1/wg-access-server/compare/0.2.5...v0.3.0-rc2#diff-24d7d302370ed3237f14db2d526f3989379e3dcef1141a76de2cea7ba9b1dcb2R49

[arctica]

I am facing the same issue. Upgraded wg-access-server to the most recent version and client traffic does not seem to get properly routed anymore. With or without dns enabled, same problem.

Clients have the range 10.44.0.0/16 for which traffic is routed fine, at least I can ping 10.44.0.1. But any traffic to outside that range gets lost.

I compared iptables rules between the old and the new server and noticed the default policy for FORWARD changed from ACCEPT to DROP.

Old server:
Chain FORWARD (policy ACCEPT)

New server:
Chain FORWARD (policy DROP)

Running iptables -A FORWARD -s 10.0.0.0/8 -j ACCEPT resulted in the traffic being routed properly again. I am not sure if this is a good config though. @Place1 any ideas?

[Mokto]

Same issue here. Upgraded from 0.2 to 0.4.

I do have internet, but DNS can't seem to work outside this network.