[SOLVED] Can reach OPNsense and internet but no LAN ressources

Started by HarryDasBrot, November 20, 2024, 12:14:55 AM

Previous topic - Next topic
Hi All, first time poster here.

I am running OPNsense 24.7.8 and have set-up Wireguard (Road Warrior) using the official guide. My goal is to access my homelab when I am not home (I have to travel for work frequently). I am currently remote and I can access the OPNsense WebGUI using the LAN IP and I can also browse the internet through my internet back at home (2ip.to). This is good but when I try to access any ressources in my homelab in the same subnet as OPNsense, I get timeouts. Can't ping anything outside OPNsense ofcource. I have set-up the Firewall rule to "pass" traffic to LAN. I also verified that this is not a "client" issue and have the same issue on my phone (iPhone running Wireguard app). Any suggestions, what I can try?

Here is my set-up:

L3 Switch:
Management VLAN 10: 172.16.10.1 - Also acting as DHCP server for LAN

Server 1
  IPMI: 172.16.10.2 (IPMI port) <-> L3 Switch (access port tagged as vlan 10)
  Proxmox: 172.16.10.3 (eth0 connected to vmbr0) <-> L3 Switch (access port tagged as vlan 10)

OPNsense (VM on Proxmox):
  LAN: 172.16.10.5  (virtio0 connected to vmbr0) <->  L3 Switch (access port tagged as vlan 10)
  WAN: 89.255.x.x (fibre connection to ISP through PPPOE on vlan 7) <-> Fiber Modem

With this out of the way, here is my config:

(1) WG Overview:

(2) WG Instance:

(3) WG Peer:

(4) WG Interface:

(5) Interface Assignments:

(6) WAN FW Rule:

(7) WG IF Rule:



Problem: Once I am connected to the Wireguard tunnel, I can:
- Ping 172.16.10.5 : success
- Ping google.com : success
- Ping 10.10.10.1 : success
- Ping 172.16.10.1: timeout
- Ping 172.16.10.3: timeout

Would welcome any advice or guide on how to troubleshoot my issue. I have looked at firewall rules but did not notice anything strange.

Edit: In my case, the LAN members at the remote location did not had internet access (no gateway configured). Setting the gateway (using my OPNsense as a jump point to configure the gateway via ssh). I will look into masquerading my IP to be able to connect to clients which I don't intend to have internet access. 

Note that your LAN devices will block access from outside of the LAN by their own firewalls by default.


Quote from: HarryDasBrot on November 20, 2024, 09:30:39 PM
My Printer, Switch, etc. don't have a firewall.
Do those devices have the default gateway set properly pointing to OPNsense?

Oh my god. You were right. For some reason, my dhcp did not distribute the default gateway and for some reason, I thought using wireguard is the same as being in LAN. Now I know better. Thank you so much.

Quote from: HarryDasBrot on November 21, 2024, 12:55:53 AM
I thought using wireguard is the same as being in LAN.
You can realize this though by an outbound NAT for the Wireguard subnet, natting the source IP to the OPNsense LAN IP (masquerading).
Maybe this is desired, in case, you don't want to state a gateway on dumb devices, which do not need internet access.

Quote from: viragomann on November 21, 2024, 09:46:07 AM
You can realize this though by an outbound NAT for the Wireguard subnet, natting the source IP to the OPNsense LAN IP (masquerading).
Maybe this is desired, in case, you don't want to state a gateway on dumb devices, which do not need internet access.

I was following guide from https://docs.opnsense.org/manual/how-tos/wireguard-client.html page which mentions that in step "Step 4(a) - Assign an interface to WireGuard (recommended)" that "[...]it automatically adds an IPv4 outbound NAT rule, which will allow the tunnel to access IPv4 IPs outside of the local network (if that is desired), without needing to manually add a rule[...]". So I thought I don't have to add a manual outbound NAT.

I have added a screenshot with the automatically generated rule.

That's somewhat different. The mentioned NAT rule is needed to access the internet across the tunnel. It's added to WAN.

I was talking about an outbound NAT rule on the LAN, meant as a workaround if local devices doesn't have a default gateway set.
This would translate the VPN clients IP to the LAN IP. So the destination device has to reply to the LAN IP, which is within its subnet, hence it wouldn't need a gateway. This also circumvents firewall restrictions of outside access on the devices.

Quote from: viragomann on November 21, 2024, 10:05:11 PM
That's somewhat different. The mentioned NAT rule is needed to access the internet across the tunnel. It's added to WAN.

I was talking about an outbound NAT rule on the LAN, meant as a workaround if local devices doesn't have a default gateway set.
This would translate the VPN clients IP to the LAN IP. So the destination device has to reply to the LAN IP, which is within its subnet, hence it wouldn't need a gateway. This also circumvents firewall restrictions of outside access on the devices.

I am currently remote and worried that with outbound NAT rule on the LAN interface I will cutoff my access. Is there a good guide on how to set-up this up? Is it just an outbound NAT rule on the LAN interface where I enable all communication?

Danke übrigens für deine Hilfe und schönes WE!

An outbound NAT rule on LAN doesn't disconnect you from OPNsense itself. It only affects traffic, which is going out on LAN and translates the source address into the interface address.
With this, the local destination devices see the access coming from OPNsense itself, which is inside of their subnet instead of the real origin source IP. So they don't need a gateway set to be accessed.

For the sake of security you should limit this rule to certain source and destination devices only.
If you need it for multiple destination devices add their IPs to an alias to treat all with a single rule.

Assuming the concerned devices are connected to LAN, the rule should look similar like this:

interface: LAN (subnet where the destination devices reside)
protocol: limit it for your needs
source: 10.10.10.0/24 (Wireguard tunnel)
destination: <alias for dest. IPs>
translation: LAN address (respective interface address)

Ensure that the outbound NAT is in hybrid mode.