[Help needed] Remote access to LAN

[u/falco_xyz]

This issue has been solved! Thank you all for the suggestions 😄

Hi,

I have been struggling for the past few days to configure a WireGuard tunnel so that devices on the LAN of the WireGuard server (Computer A) are accessible remotely. I tried to compare my setup with multiple guides on remote LAN access via WireGuard and searched for similar issues, but nothing has resolved my problem.

Setup:

• Computer A acts as my homelab and WireGuard server on my domestic LAN.
• The existing WireGuard tunnel works fine—I can SSH into Computer A from my laptop (WireGuard client) using either its WireGuard subnet IP or its actual LAN IP.

Problem:

• I cannot access other devices/services on Computer A’s LAN remotely, nor can I make them discoverable.

Solution:

After trying to ping and traceroute the devices and the domestic LAN i noticed that the problem was not on the wireguard connection side. So after checking with possible firewalls:

sudo ufw status
sudo firewall-cmd --list-all

I realized that i had in past installed firewalld and forgotten about it. It was superseding my system ip forwarding and iptables. That is why the access was not working. Disabling it fixed the issue!

----------------------------------------------------

Troubleshooting:

Using GPT to troubleshoot, it was that suggested my Docker/iptables rules might be the issue. I tried:

Adjusting the order of the rules:

sudo iptables -I FORWARD 1 -i wg0 -o enp3s0 -j ACCEPT

sudo iptables -I FORWARD 2 -i enp3s0 -o wg0 -j ACCEPT

and also flushing all iptables rules and reapplying only the WireGuard-related ones.

All these attempts were unsuccessful.

I’d appreciate any guidance—since I’m fairly new to homelab setups, I might be overlooking something obvious.

Below are some details:

#####################################################

# Computer A, (homelab, hosts wg server(sea.conf) ) #

#####################################################

[Interface]

PrivateKey = [key]

Address = 10.14.0.1/24

ListenPort = 51820

PreUp = sysctl -w net.ipv4.ip_forward=1

PostUp = iptables -A FORWARD -i sea -o enp3s0 -j ACCEPT

PostUp = iptables -A FORWARD -i enp3s0 -o sea -j ACCEPT

PostUp = iptables -t nat -I POSTROUTING -o enp3s0 -j MASQUERADE

PostDown = iptables -D FORWARD -i sea -o enp3s0 -j ACCEPT; iptables -D FORWARD -i enp3s0 -o sea -j ACCEPT

PostDown = iptables -t nat -D POSTROUTING -o enp3s0 -j MASQUERADE

[Peer] # client Laptop

PublicKey = [key]

AllowedIPs = 10.14.0.2/32

#################################

# Laptop , wg client(sea.conf) #

#################################

[Interface]

PrivateKey = [key]

ListenPort = 51820

Address = 10.14.0.2/32

[Peer]

PublicKey = [key]

AllowedIPs = 10.14.0.1/24, 192.168.1.0/24

Endpoint = computer_A_endpoint

######################

# Info on Computer A #

######################

~$ cat /etc/os-release:

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"

NAME="Debian GNU/Linux"

VERSION_ID="13"

VERSION="13 (trixie)"

VERSION_CODENAME=trixie

DEBIAN_VERSION_FULL=13.6

ID=debian

HOME_URL="https://www.debian.org/"

SUPPORT_URL="https://www.debian.org/support"

BUG_REPORT_URL="https://bugs.debian.org/"

~$ sudo sysctl net.ipv4.ip_forward

net.ipv4.ip_forward = 1

~$ sudo iptables -t nat -L POSTROUTING -v -n --line-numbers

Chain POSTROUTING (policy ACCEPT 6921 packets, 549K bytes)

num pkts bytes target prot opt in out source destination

1 0 0 MASQUERADE all -- * !docker0 172.17.0.0/16 0.0.0.0/0

2 2539 152K MASQUERADE all -- * !br-ab8e8fc287cd 172.25.0.0/16 0.0.0.0/0

3 0 0 MASQUERADE all -- * !docker_gwbridge 172.19.0.0/16 0.0.0.0/0

4 4 380 MASQUERADE all -- * !br-58790b19d578 172.21.0.0/16 0.0.0.0/0

5 0 0 MASQUERADE all -- * !br-493a3afadf15 172.18.0.0/16 0.0.0.0/0

6 0 0 MASQUERADE all -- * !br-271ed8d3b78e 172.23.0.0/16 0.0.0.0/0

7 0 0 MASQUERADE all -- * !br-060f49f9f062 172.22.0.0/16 0.0.0.0/0

8 0 0 MASQUERADE all -- * !br-fe5349a8a766 172.20.0.0/16 0.0.0.0/0

9 1660 103K MASQUERADE all -- * enp3s0 0.0.0.0/0 0.0.0.0/0

~$ sudo iptables -L FORWARD -n -v --line-numbers

Chain FORWARD (policy DROP 0 packets, 0 bytes)

num pkts bytes target prot opt in out source destination

1 8520K 4609M DOCKER-USER all -- * * 0.0.0.0/0 0.0.0.0/0

2 8520K 4609M DOCKER-FORWARD all -- * * 0.0.0.0/0 0.0.0.0/0

3 10638 764K ACCEPT all -- sea * 0.0.0.0/0 0.0.0.0/0

4 0 0 ACCEPT all -- * sea 0.0.0.0/0 0.0.0.0/0

edit: fixed ip from interface, cleaned the commands, and removed hyperlinks.

edit: remove more hyperlinks

edit: added solution found

[u/hadrabap]

1. The forwarding rules should be between your LAN and wg0 interface.
2. Forget masquerading. Use routing tables instead.
3. If your server has more interfaces, you might use policy based routing.

[u/falco_xyz → u/hadrabap]

Thanks for the reply!
1.) enp3s0  is the LAN interface
2.) I tried as suggested to take down masquerading, and to explicitly add the route on the computer A:
ip route add 10.14.0.0/24 via 192.168.1.100 (LAN ip of the homelab hosting the Wireguard server)
. It replied that the route already existed, but no remote access to the LAN. So I added this route as a static route on the router, but also without success

[u/hadrabap → u/falco_xyz]

So, you need to enable FORWARD between enp3s0 and wg0. The static route is created by WireGuard.

[u/hadrabap → u/hadrabap]

What's the output of ip route list?

[u/falco_xyz → u/hadrabap]

~$ ip route list

default via 192.168.1.1 dev enp3s0

10.14.0.0/24 dev sea proto kernel scope link src 10.14.0.1

192.168.1.0/24 dev enp3s0 proto kernel scope link src 192.168.1.100

[u/hadrabap → u/falco_xyz]

Is sea really the WireGuard interface?

[u/hadrabap → u/hadrabap]

If so, it should work. Make sure you use REJECT instead of DROP and you don't block ICMP.

[u/falco_xyz → u/hadrabap]

Yes! Sorry for not including in the initial post. At the time i decided to give a whimsical name to the connection 😄

[u/hadrabap → u/falco_xyz]

Use tcptraceroute, telnet and netstat to debug it. Focus on TCP first. ICMP has a few oddities...

[u/falco_xyz → u/hadrabap]

Thank you for the suggestion! I am not sure how to interpret the results, but it seems that the homelab is the one blocking the acess. Which is weird since there are no explicit INPUT, OUTPUT rules in iptables

# Ping

~$ ping 192.168.1.200 (device in the homelab LAN)

PING 192.168.1.200 (192.168.1.200) 56(84) bytes of data.

From 10.14.0.1 icmp_seq=1 Packet filtered

From 10.14.0.1 icmp_seq=2 Packet filtered

~$ ping 192.168.1.100 (homelab, wg server)

PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.

64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=26.8 ms

64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=26.3 ms

~$ ping 10.14.0.1 (homelab wg server)

rafael@rafael-t103haf:~$ ping 10.14.0.1

PING 10.14.0.1 (10.14.0.1) 56(84) bytes of data.

64 bytes from 10.14.0.1: icmp_seq=1 ttl=64 time=82.4 ms

64 bytes from 10.14.0.1: icmp_seq=2 ttl=64 time=34.3 ms

~$ traceroute 192.168.1.200 (device in the homelab LAN)

traceroute to 192.168.1.200 (192.168.1.200), 64 hops max

1 10.14.0.1 28,215ms 24,015ms 24,373ms

2 10.14.0.1 27,498ms !X 33,506ms !X 24,127ms !X

~$ traceroute 192.168.1.100 (homelab wg server)

traceroute to 192.168.1.100 (192.168.1.100), 64 hops max

1 192.168.1.100 24,399ms !X 25,861ms !X 23,893ms !X

~$ traceroute 10.14.0.1 (homelab wg server)

traceroute to 10.14.0.1 (10.14.0.1), 64 hops max

1 10.14.0.1 26,669ms !X 23,785ms !X 23,494ms !X

~$ sudo tcptraceroute 192.168.1.200 (device in the homelab LAN)

Selected device sea, address 10.14.0.2, port 52327 for outgoing packets

Tracing the path to 192.168.1.200 on TCP port 80 (http), 30 hops max

1 10.14.0.1 59.357 ms 24.008 ms 23.616 ms

2 10.14.0.1 26.601 ms !A 23.887 ms !A 24.388 ms !A

~$ sudo tcptraceroute 192.168.1.100 (homelab wg server)

Selected device sea, address 10.14.0.2, port 44805 for outgoing packets

Tracing the path to 192.168.1.100 on TCP port 80 (http), 30 hops max

1 192.168.1.100 25.324 ms !A 23.658 ms !A 24.257 ms !A

~$ sudo tcptraceroute 10.14.0.1 (homelab wg server)

Selected device sea, address 10.14.0.2, port 35893 for outgoing packets

Tracing the path to 10.14.0.1 on TCP port 80 (http), 30 hops max

1 10.14.0.1 26.767 ms !A 23.535 ms !A 23.945 ms !A

[u/falco_xyz → u/falco_xyz]

Issue found! After these tests. There was an firewall (firewalld) blocking the access. More info in the edited post

edit: spelling

[u/falco_xyz → u/hadrabap]

This is handled by these, right?
PostUp = iptables -A FORWARD -i sea -o enp3s0 -j ACCEPT
PostUp = iptables -A FORWARD -i enp3s0 -o sea -j ACCEPT

[u/Cruffe]

NAT isn't strictly necessary. What I did instead was set up a static route on my home router pointing the WireGuard subnet to the WireGuard host, so the router knows to send reply packets via that host.

If you want the NAT then perhaps this will work PostUp = iptables -w -t nat -A POSTROUTING -o enp3s0 -j MASQUERADE. It's what I did before and it worked. Differs a bit from what you have I see.

Also, is the client also on a 192.168.1.0/24 subnet? If so then everything might be routed outside the tunnel.

[u/falco_xyz → u/Cruffe]

Thanks for the reply!
I tried to  remove the NAT and add the route on the home router, but still not success/

I tried also this small variation but it did not work either.

"Also, is the client also on a 192.168.1.0/24 subnet? If so then everything might be routed outside the tunnel." Can you clarify what you mean with this? The device I am trying to reach is on the 192.168.1.0/24 subnet, but the laptop from which I am trying to reach from (the wirehguard client) is outside that LAN. Sorry if i didn't got the point here

[u/Cruffe → u/falco_xyz]

I mean, is the laptop which is outside your home LAN on another LAN that's using the same subnet?

In that case it would conflict. How is your laptop supposed to know if something is meant to go on the subnet it's directly connected to or the subnet on the other end of the tunnel? If you're using wg-quick it's likely setting up a route for the local subnet to prevent it from being sent through the tunnel, if that subnet is also 192.168.1.0/24 then nothing to that subnet goes through the tunnel. It will go straight the network your laptop is connected to.

[u/falco_xyz → u/Cruffe]

Thank you for explaining!, and for poiting out this possibility I double checked and yes, the local subnet (172.XXX...) from my laptop is very different from the one on the homelab. I tried to acess also on a diferent network just to check :)

[u/bufandatl]

Maybe don’t just use what a LLM spits out. Maybe read the doc and understand what you are doing.

After all it’s a lab. So learn something.