Gateway Node

[hansy2]

Important: Don't forget to add your gateway node's subnet IP (192.168.2.0/24) to the AllowedIPs list in your WireGuard peer configuration. If this entry is missing, you will be unable to reach or communicate with the gateway node over the tunnel.

https://www.wiredoor.net/docs/usage#gateway-node

[dmesad]

That’s currently handled internally by Wiredoor.
When a gateway node is created, Wiredoor automatically configures the appropriate AllowedIPs in each peer’s WireGuard setup, so users don’t need to manually add the subnet range.

[dmesad]

Unfortunately not for me, the latest version is installed. When the config is downloaded, it only contains "AllowedIPs = 10.0.0.0/24".

Could you please share a few more details so I can try to reproduce the issue?

[hansy2]

Since I only use "Split Tunnel" for certain clients and not "Full Tunnel", the subnet has to be added afterwards.

Add Client -> fill everything out -> click on save -> using wireGuard configuration -> download configuration

`
[Interface]
PrivateKey = AEq1wC2Kp4YH2tj**********
Address = 10.0.0.5/32

[Peer]
PublicKey = S2zrnUMmp3oQ1*************
PresharedKey = mZTrILAx8Rt*******
AllowedIPs = 10.0.0.0/24 <<<< the subnet is missing here
PersistentKeepalive = 25
Endpoint = *******:51820
`

[dmesad]

In Wiredoor, each gateway is configured with iptables PostUp and PostDown rules that perform forwarding and NAT between the WireGuard network (10.x.x.x) and the local subnet (for example: 192.168.1.x).

Clients don’t need to manually include the LAN subnet in their AllowedIPs because the gateway handles the routing and masquerading automatically.

Example gateway configuration:

[Interface]
PrivateKey = ***************
Address = 10.12.1.2/32

PostUp = iptables -A FORWARD -i wg0 -o eth0 -s 10.12.1.0/24 -d 192.168.1.0/24 -j ACCEPT; iptables -A FORWARD -i eth0 -o wg0 -s 192.168.1.0/24 -d 10.12.1.0/24 -j ACCEPT; iptables -t nat -A POSTROUTING -s 10.12.1.0/24 -d 192.168.1.0/24 -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -o eth0 -s 10.12.1.0/24 -d 192.168.1.0/24 -j ACCEPT; iptables -D FORWARD -i eth0 -o wg0 -s 192.168.1.0/24 -d 10.12.1.0/24 -j ACCEPT; iptables -t nat -D POSTROUTING -s 10.12.1.0/24 -d 192.168.1.0/24 -o eth0 -j MASQUERADE

[Peer]
PublicKey = ***************
PresharedKey = ***************
AllowedIPs = 10.12.1.0/24
PersistentKeepalive = 25
Endpoint = ***************:51820

If you add it manually, it’ll still work, but it’s not required for connectivity in the default Wiredoor setup.

[hansy2]

Perhaps this is a mistake on my end, but without this change I can't access the gateway subnet with a Windows PC. Otherwise everything works, and I'll test it under macOS with the same configuration shortly.

***** Update *****
The same thing happens on macOS. As soon as I use the configuration in Wireguard, I can't access the subnet without making the change.

[dmesad]

I wouldn't recommend adding local subnet to the AllowedIPs.
If you do, all traffic destinated for that subnet will be routed through the tunnel, instead of reaching your actual local network.

On Windows, since iptables rules don't apply , the automatic gateway routing won't work as it does on Linux.

In this case, I recommend running the Wiredoor Gateway using the official Docker image wiredoor/wiredoor-cli, which already includes the necessary routing and masquerading configuration.

To configure a docker gateway, simply create a gateway node on your Wiredoor instance pointing to your local network.
Then create a docker-compose.yml file in your local windows machine:

services:
  wiredoor-gw:
    image: wiredoor/wiredoor-cli:latest
    cap_add:
      - NET_ADMIN
    sysctls:
      - net.ipv4.ip_forward=1
    environment:
      WIREDOOR_URL: https://your-wiredoor-instance_or_ip
      TOKEN: your-gateway-node-token

Replace the WIREDOOR_URL and TOKEN variables, and then start the container with:

docker compose up -d

Once the container is running, you’ll be able to expose services from any address within your local network.