Wireguard Server - Access homenetwork

Good day!

I have been using Linuxserver/Wireguard for months and it has been wonderful. One thing that I have been thinking about for some time is how to gain access to home network. Are there anyone who has achieved this or have some advice that could help me? This is what I have done so far:


  1. Added net.ipv4.ip_forward = 1 to /etc/sysctl.conf and rebooted.
  2. Added Home network LAN (10.0.1.0) to peer in server wg0.conf and rebooted.

[Peer]
PublicKey = …
AllowedIPs = 10.13.13.2/32,10.0.1.0/24
PersistentKeepalive = 25


Docker-compose snippet with linuxserver/wireguard
  wireguard:
    image: linuxserver/wireguard
    cap_add:
      - net_admin
      - sys_module
    environment:
      TZ: "Europe/London"
      PUID: 1000
      PGID: 1000
      SERVERURL: MY_URL
      SERVERPORT: MY_EXT_PORT
      PEERS: 2
      PEERDNS: 8.8.8.8
      INTERNAL_SUBNET: 10.13.13.0
    ports:
      - "51820:51820/udp"
    restart: unless-stopped
    volumes:
      - /etc/docker/wireguard_server:/config
      - /lib/modules:/lib/modules
PostUp and PostDown scripts in server wg0.conf

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

There is no need of adding static routes given both addresses are on the same subnet. So what else should I do? Do I need to add some additional rules to PostUp/Down such as: iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT; iptables -A FORWARD -i %i -o eth0 -j ACCEPT? Do I need to accept rules the other way as well, from eth0 to %i? I appreciate all the help I can get :slight_smile:

I achieved it, i simply copy pasted the suggested compose entry, entered a 1 for peers, when the barcode popped up, i scanned it with my cell phone. When i leave the house and connect, i have access to my lan.

I suggest starting with the basics before trying to modify things, you need a good known working solution prior to advanced tinkering.

1 Like

Yeah as driz said, keep it simple at first.

I done exactly the same and everything worked fine right away.

Actually, I started with the basics. The reason for why I didn’t think it worked was because I could not access my server’s ssh and https ports. So I searched online and found multiple guides without any luck. The reason for why I could not access my server was that my firewall setup blocked the access. I thought the Docker container added the necessary rules for forwarding and hence didn’t think that could be the issue.

So by adding the rule iptables -P INPUT ACCEPT I can access both ssh and https. I have narrowed it down to iptables -A INPUT -s 172.20.0.2/32 -p tcp -m multiport --dports 22,443 -j ACCEPT (I am not using port 22 for ssh, so the rule is different for me). Given the address 172.20.0.2, is it hardcoded? I have tried multiple peers with different addresses and they all get that adress. I have not tried to see which address I get if another user is connected, but could it be 172.20.0.3 and so on? If so, I will probably change the iptables rule to include not just 172.20.0.2.

1 Like

172.20.0.2 is NOT hardcoded and can change at any time, your rule will only work until that change occurs, that’s why our default rule uses a variable. You’ve marked your response as the solution though, so I will assume you know how to fix it when it breaks.

I can tell you i modified nothing at all to have basic LAN access while remote, this is also the experience of MOST of our user base. That said, you may be using a docker-unfriendly distribution, which is pretty much anything using ufw, nfw, or firewalld (read: anything not REAL iptables) but that info wasn’t shared so I can only make guesses.

Also, it sounds like you were assuming that 172.20.x.x is a vpn user address, it’s not, it’s the docker network address for a bridge network. your users, by default, would have 10.13.13.0/24 IPs. None of those are “static”

1 Like

You are absolutely correct. I get the IP 172.20.0.2 when I use a bridge network. Without the bridge, the host running the Wireguard server reports IP 172.19.0.2, while another host on the network reports the IP of my Wireguard server. Do you have full access to your host running the wireguard server without adding any rules? If you do, I assume you have a less strict rule?

I’m using iptables outside of the docker system, but with quite strict rules. Example for ssh (port 22): iptables -A INPUT -s LAN_NETWORK/24 -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT. By relaxing the rule and removing -s and -i I can connect just fine. I was hoping to find a solution where I can maintain strict rules.

we’re going back to where i said start with the basics, you make your rules strict AFTER you have it working. I would encourage you to join our discord, it’s much more active and better for brainstorming with others :slight_smile:

Thank you very much for the help. I will look into Discord next time I encounter something I want to discuss with others when using one of your dockers :slight_smile:

The solution I ended up with is adding a new network bridge with a static subnet. Docker-compose:

networks:
  wgs:
    name: wgs
    driver: bridge
    ipam:
     config:
       - subnet: 10.113.113.0/24

  wireguard:
    image: linuxserver/wireguard
    ....
    networks:
      - wgs
    ....

This way I can add iptables rules with -s 10.113.113.0/24 restrictions such as iptables -A INPUT -s 10.113.113.0/24 -p tcp -m multiport --dports 22,443 -j ACCEPT. Apparantly these rules can’t be added in the PostUp/Down scripts in wg0.conf.

2 Likes

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.