Wireguard/OpenVPN parity issue with unmentioned reply_to bug

[Apprisco]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [ O ] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [ O ] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

https://github.com/opnsense/core/issues/4389 Unlike OpenVPN, port forwarding through Wireguard is bugged- the wireguard ingress PASS rules must have a reply_to setting pointed to the Wireguard gateway, not the WAN Gateway- otherwise packets will be dropped without mention. This is at best a parity issue, at worst an undocumented, critical bug that's been hidden away by closed issues.

To Reproduce

Steps to reproduce the behavior:

Follow the Wireguard selective routing guide at https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html to the T. Open ports on external endpoint and notice incoming packets to Wireguard interface at the selected ports being denied. Setup a pass rule for those ports in the Wireguard interface firewall Setup a port forward for those ports to the correct internal hosts. Notice that ports remain closed and traffic is blocked.

Repeat steps for OpenVPN and notice it is working.

Expected behavior

Equal parity for OpenVPN or Wireguard/document the need for reply_to Gateways

Describe alternatives you considered

In advanced section of the pass rule, make sure packets are marked as to reply to the WG Gateway- but don't set the gateway lmao

Screenshots

Relevant log files

N/A

Additional context

N/A

Environment

OPNsense 23.7.8 (amd64).

[Apprisco]

This is not a support request. I've already gotten the port forwarding working This is a parity issue. Wireguard requires the reply_to option to be set to the wireguard gateway while OpenVPN does not. And none of this is mentioned in any document anywhere.

[Monviech]

If it's a documentation issue, you can create a PR to add it here: https://github.com/opnsense/docs/blob/master/source/manual/how-tos/wireguard-selective-routing.rst

I have already added it here once: https://github.com/opnsense/docs/blob/master/source/manual/how-tos/nat_reflection.rst

In some setups (e.g. an external IP address is bound on an additional VPN interface) you need to set "Filter rule association: None" and create your own Firewall rules. One of those firewall rules should match only on the VPN interface, and in "advanced features" of that rule "reply-to" should be your VPN interface. The other firewall rule (without "reply-to") should match the remaining interfaces.

So you can just link to that in the document or add the same section there.

[Apprisco]

@Monviech I'm now having trouble with port forwards again. Even with reply_to selected, it's not working. In short- incoming packets are logged correctly and I see all of them.

Packets incoming -> hits VPN tunnel address -> port forwarded to single host with reply_to rule -> port marked as open So that seems to be working. And it does work- qBittorrent for example will work perfectly both downloading and seeding through the VPN.

However, anytime I try a more advanced service things fail. Specifically web uis- any web UI that I've tried to port forward has completely failed. while nmap claims the port is open, I am unable to actually access the web ui- it even redirects to the correct path such as "ip:port/web/ui/" but won't actually display anything.

Please, if you have any ideas what's going on have mercy on my pitiful soul.

[Monviech]

If it happens for HTTPS and SSH for example, or most TCP traffic, its an MTU/MSS problem.

Its described here (applies to any vpn), look at the normalization rule that accounts for the VPN overhead in paket size.

https://docs.opnsense.org/manual/how-tos/wireguard-s2s.html#step-4a-setup-firewall-site-a

[Apprisco]

Unfortunately I cannot test SSH and HTTPS, both ports are below the size limit. I can only test any port over 2048. I'm not sure if it's TCP, but it's possible. I'll give it a go. Web services should be mostly TCP anyways. My keepalive is setup to 25s on the wireguard peer already.

[Apprisco]

Holy FUCK! Setting the normalization to 1340mss worked. 1390 is their recommended, meaning I had to drop it even further THANK YOU!!@@!J!@KJKJK OML

[Monviech]

Great, good job :)

[Apprisco]

@Monviech Two last questions. You're my savior in terms of everything. My sanity has been restored all thanks to you.

1. To resolve DNS leaks I setup a port forward rule for all DNS ports (53) from WGHosts to a specific DNS server. This breaks local DNS resolution. The other options on the guide didn't work. Any ideas on a better method?
2. I cannot access my web services through their domain locally. Should I just setup some unbound DNS redirects locally, or is there a way to resolve this in a smarter way?

[Monviech]

Sorry these kinda things are more for the forum now. https://forum.opnsense.org/

[Apprisco]

With all due respect, I have made the post on the forum and the opnsense reddit and neither had any reception for a long time. Both the OPNSense forums and reddit seem like they're slowly dying out. https://forum.opnsense.org/index.php?topic=41282.0 I have made a new forum post about the NAT reflection issue if you could help.

[Monviech]

If you think they're dying out feel free to help instead of being passive aggressive. 🤷‍♂️

[Apprisco]

If you think they're dying out feel free to help instead of being passive aggressive. 🤷‍♂️

Sorry, it was not my intention to come across like that, haha. I just meant that generally people seems to stop contributing on OPNSense/PFSense related forums. I've requested help with various problems over the past year and received barely any help overall. This github has been the most useful.