Wireguard Selective Routing - Local resolution?

[apprisco]

Hi all! I have wireguard selective routing working perfectly even with port forwards via reply_to.
https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html + documented reply_to issue.
I'm now trying to get my port forwards to work within LAN- aka access services through the VPN tunnel also through LAN as I need the url to be the same within the network as outside of the network.

I've heard this can be done with NAT reflection in most cases, but with wireguard it doesn't seem to work.
Anyone have any clues?

[Monviech (Cedrik)]

What did you try?

Did you follow the NAT Reflection tutorial?

Whats the current state of the rules?

[apprisco]

Hi,

Sorry for sounding passive aggressive on Github! It really wasn't my intention.

Current state: 10.13.128.121 is the local endpoint of the WG Tunnel. I can access my port forwarded services in LAN through 10.13.128.121:port. However, I cannot access it via the other endpoint- aka the public IP of the WG Tunnel. This seems to say that NAT reflection is working but not in the way that I want it to.

Should I post every rule I have setup on OPNsense WG related right now? I do not want to spam with images.
While the issue I posted has been resolved (MSS issue as you mentioned)
https://new.reddit.com/r/opnsense/comments/1dompr6/port_forwarding_based_on_wireguard/
All my rules should be available on the above link.

[Monviech (Cedrik)]

It's okay, I know how annoying it is if something does not work right.

The issue comes from the complexity of NAT, combined with unusual configurations.

The root of it all stems from ignoring IPv6, too. If all of your services would be available with IPv6 too, all IP addresses would be unique. (IPv6 GUA, Global Unicast Address, globally routable). You don't need any NAT for that, no NAT Reflection, nothing. It just works TM.

So, striving for a Dual Stack infrastructure with IPv4 and IPv6 solves all those pains. All clients that have IPv6 will prefer it over IPv4, meaning that you don't need the complicated NAT rules. Clients will always be routed directly to the service, without tricking them with NAT in any way.

-----------

Also yeah I'm talking around your issue. It would take a lot of time to troubleshoot that. I don't have any test environment for that, and doing it asynchronically on a forum without having access to a remote session (especially for NAT problems) is really hard. I'm kinda caught up in a lot of things, I can't spend too much time on this.

[apprisco]

It just seems like a standard wireguard based issue though. It simply thinks that the nat reflected IP is the local endpoint of the wireguard tunnel, not the actual endpoint.
Is there any way to resolve this with a hairpin?

[Monviech (Cedrik)]

Yeah with reflection you can rewrite the destination any way you like.

And with hairpin you can rewrite source and destination at the same time.

It's all explained here in method 1:

https://docs.opnsense.org/manual/how-tos/nat_reflection.html#start-of-the-how-to-section

You don't use any of the system default nat reflection options, but craft your own.

In your case, you can create a different port forward rule that matches before the one you already have, selectively matching the traffic you want to reflect. For example by specifying an exact source, for example only the IPs of your LAN network.

Just try a few things out, NAT is pain. I have to look at my own manual almost every time I do anything. It's really a mind twister.

[apprisco]

Unfortunately following the guide and not using the default NAT reflection, I can't even access the services via the internal wireguard port.

[apprisco]

Interesting.
I can finally see some of the important logs in the firewall.
WAN IP (device is off the VPN) hits external WireGuard Endpoint IP.
That request gets redirected into the home directly through the tunnel through my port forward.
That traffic then tries to go back out to no avail.

If I can redirect all traffic to the external wireguard endpoint ip from localhost to the internal wireguard IP it should work.

[apprisco]

Worked! Simply adding another port forward on top of the existing port forward on WAN interface, redirecting all requests to Wireguard IP to local tunnel seems to have worked.

[Monviech (Cedrik)]

Great job.

Now that you have the gist of it, maybe you could help others with the same issues sometimes.

The unholy trinity of:
- reply_to
- mtu/mss
- port forwards for proper NAT reflection

is one of the more common occurences lately.