Hi,
I'm struggling with port forwarding through WireGuard.
Totally i have 3 conected to each other opnsense and all subnets are fully accessible from each other.
Each office is connected via a separate instance-peer setup, so each WG instance has its own interface.
I am trying to port forward from wan opnsenseA to lan opnsenseB but it only works from the OpnsenseA local networks.
I tried adding a reply-to gateway of the WG interface for Wan rule, but that didn't help either. Maybe I misconfigured the gateway for WireGuard?
( ip of WG instance of opnsenseA (tried B also), monitor ip is lan ip of opnsenseB) opnsenseB has a dynamic Wan ip.
(https://i.postimg.cc/tTRXHmCs/image.png)
OpnsenseA logs show that everything is working as expected.
(https://i.postimg.cc/8CcSKfyv/image.png)
Meanwhile, OpnsenseB shows nothing at all...
However, if I try accessing the WAN from the LAN network of OpnsenseA, both OpnsenseA and OpnsenseB logs show activity.
The logs of opnsenseB
(https://i.postimg.cc/KztsJZyL/image.png)
Any ideas what I might be missing?
And second question how to debug it? How to check traffic flow to understand what is going wrong?
Does your wireguard cryptokey routing (Allowed IPs) allow any IP address to get routed into the tunnel?
Quote from: Monviech (Cedrik) on September 03, 2025, 11:18:39 AMDoes your wireguard cryptokey routing (Allowed IPs) allow any IP address to get routed into the tunnel?
sorry for delay with reply)
Can you please correct me if I am wrong. "Allowed IPs" refers to the subnets or IP addresses that should be routed through the tunnel.
So if I uderstant you correct, No, its configured to route only local nets. What exactly I need Wan=>wg=>local ip.
P.S.
I added a rule to the WG interface on opnsenseB, which seems logical, but it didn't help. Anyway I don`t see any firewall logs on opnB that match or correspond to the redirect logs on opnA."
(https://i.postimg.cc/7ZkyH6jb/image.png)
The cryptokey routing is best explained here, it has its own subsection on the main page:
https://www.wireguard.com/
What you can do is selecting if routes should be installed to the system routing table, or not, via an advanced option in the wireguard endpoint.
Other than that, the packet capture tool is your friend. Capture ICMP and follow the packets, see where it fails.
Also you might discover assymtric paths, if client A has a public IP address as source and gets port forwarded and routed through the wireguard tunnel, on the VPS the return packet will be sent via the default gateway, not returning back through the tunnel, as the target is a public IP. You have to use source NAT as well so the source looks like its an IP that can be routed back through the wireguard tunnel.
Quote from: Monviech (Cedrik) on September 04, 2025, 08:33:57 AMWhat you can do is selecting if routes should be installed to the system routing table, or not, via an advanced option in the wireguard endpoint.
I have access from local nets of OpnsenseA to local nets of opnsenseB and vice versa. So is it means that the routing table is configured correct?
Quote from: Monviech (Cedrik) on September 04, 2025, 08:33:57 AMAlso you might discover assymtric paths, if client A has a public IP address as source and gets port forwarded and routed through the wireguard tunnel, on the VPS the return packet will be sent via the default gateway, not returning back through the tunnel, as the target is a public IP. You have to use source NAT as well so the source looks like its an IP that can be routed back through the wireguard tunnel.
as I understand the issue is here but I added reply-to option with wgB gateway to the Wan rule which "associated" with port forwarding. If there anything else what I am missing?
Thank you for your help!)
If the local networks can talk to each other, good.
But if you port forward, the source IP is a public IP address still. So the wireguard tunnel has to allow the public IP through the tunnel, and the response packet with thw public IP as target back through the tunnel.
This means the cryptokey routing has to bw configured correctly (aka allowing any allowed IPs to go into the tunnel on the site that will send back >to> the public IP of the requesting client)
For that you will most likely need policy based routing, and unchecking that the wireguard itself installs system routes.
With PBR you can set a gateway inside firewall rules.
e.g.
https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html
Quote from: Monviech (Cedrik) on September 04, 2025, 09:02:55 AMFor that you will most likely need policy based routing, and unchecking that the wireguard itself installs system routes.
I apologize for asking so many questions — I'm still new to OPNsense, coming from Kerio Control.
Yes, the source is a public IP, which is why "port forwarding" only works from the local networks of opnsenseA — because in that case, the source IP is local.
Should I configure selective routing on opnsenseB? And if so, which rule should I use this WG gateway?
Sorry but I try to understand why selective routing would be needed in this situation, since I don't require internet access through opnsenseA at all, and I can't specify a particular "source IP" from wich I will ever try access my Home Assistant server.
Should I create gateway for WG and use it as reply-to here? (Firewall=>rule=>WG_interface)
(https://i.postimg.cc/7ZkyH6jb/image.png)