Messages

Patrick,

Thank you very much.
I had not checked the packet processing order since I was wrongly focusing on the fact it was OK with the phone connected to the Wifi.

That was the issue, indeed. I enabled the automatic rule generation.

If I had chosen to handle the FW rule manually, I would never have thought of setting 127.0.0.1 as a destination in a WAN-facing firewall rule. :D

[this is the server side (OPNsense) not replying at all]

Good evening,

I'm using the "official" WireGuard client on an Android phone to connect to an OPNsense 26.1.5 virtual appliance running on KVM (Proxmox).
GrapheneOS's Android 16, WireGuard client version 1.0.20260315.

On the OPNsense side, a WG instance is listening on port 51820.
Firewall rules (new model) on the WAN interface of the OPNsense are basic : a rule allowing all traffic from specific sources (anti-lockout ; not matching the phone's public IP) and a rule allowing UDP/51820. Nothing else. No legacy rule.

The Android client is successful in connecting to it, regardless of its connectivity : Wifi, or mobile network.

I need to run Wireguard (or at least I'd like to) on UDP/4500 sometimes, to escape a firewall at a specific location.
I do not want to create a specific Wireguard instance for that purpose.
Therefore I created a Destination NAT rule : UDP/4500 arriving on the WAN interface (regardless of the source) is redirected to 127.0.0.1 port 51820.

The odd behavior I'm unable to understand and figure out it the following.

When the phone is connected on my home's Wifi network and the Wireguard client is set to target port 51820 at the OPNsense side, everything works like a charm. The OPNsense is remote, not located on the LAN

Disconnecting the phone's Wifi to use the mobile connection : WG traffic is still flowing between the phone and the OPNsense.

Now if I change the target port in the Wireguard's client configuration from 51820 to 4500 : the OPNsense instantly stops replying to any WG packet sent by the Android client. This was verified by capturing traffic with tcpdump on the OPNsense appliance. (tcpdump -nvvvvli vtnet0 port 4500 ; vtnet0 being the WAN interface) I'm still using the mobile network at this stage.

With the client still configured to use port 4500, when I reconnect to the Wifi network, the OPNsense replies to the client again.

Comparing initial handshake packets when the client is connected to Wifi vs. mobile network, using port 4500 in both cases, shows no obvious difference.

The DNAT rule seems to be OK since the client can connect over port 4500 when it's using Wifi.

This does not appear to be caused by the mobile network since this is the server side (OPNsense) not replying at all.

Odd stuff continues : when I add a firewall (new model) rule allowing any UDP traffic (all sources/destinations/ports) just before the rule allowing WireGuard traffic to port 51820, WireGuard on port 4500 becomes OK with the phone connected to the mobile network.

This is driving me nuts. :)

Any piece of advice would be appreciated.

Thank you.