After reboot wireguard behind opnsense no outbound NAT to WAN Interface pppoe0

[blodone]

Hi,


After debugging some time i found out that if i reboot my opnsense box my VPN gateway behind it does not get any connection anymore.

The Source IP (192.168.x.x) in the outbound WAN NAT should be rewritten to the pppoe0 WAN Interface address, but it's left unchanged.

If i "tcpdump -i pppoe0 port ...." i see the unchanged source address. Although i have set Block private networks it's visible with tcpdump and tells me it's on the line

So now if i change my wireguard to another port listening, it'll connect in no time.
Reboot -> not working, same issue on the other port.
I have no port-forward or any rules (cleaned all out).

If i netcat with the same source port to destination it's also not NAT translated.
Only after some time with no traffic (wireguard disabled) the issue is magically resolved like it seems a state is held and NAT translation of a later assigned WAN Interface Address is not possible.

After some search and verification it seems this Issue is already 2 years old:
https://forum.opnsense.org/index.php?topic=31351.0

I tracked down to at least 1 Minute downtime in traffic is cleaning up the states and a new Connection is being NAT translated good. But that has to work out of the box for a professional firewall. This issue cannot be ignored!

[udo1toni]

Das Problem besteht dauerhaft. Ich kann machen was ich will, die Rules werden einfach komplett ignoriert, als seien sie gar nicht vorhanden - obwohl sie fröhlich angezeigt werden.

[relmes]

I had a similar issue that I've been wrestling with.  In my setup I've an external device that handles the ppp connection and gives me a /29 network. The Opnsense has a WAN interface in that /29 for internet access and should NAT everything behind the IP on the WAN interface which the ppp router will then handle. 

However, on a reboot of the FW I was seeing non natted traffic from my network hit the PPP router.  The FW on that device is set to drop anything that is sourced from RFC1918.  ALL the traffic that was hitting it was ZeroTier (UDP 9993) traffic. 

Looking at the states, there were ones for direct (non NAT) in place and NAT ones.  If I cleared the state tables (either all or the relevant ones just for the Zerotier traffic) it all all started working again, with the NAT rule being hit and processed properly.

After much playing about, I seem to have found a fix.

Under:
Firewall -> Settings -> Advanced

Tick the "Skip Rules when gateway is down".

This seems to prevent the issue. 

My guess is that when this is NOT ticked the FW rules were enabled so traffic was able to leave the interface to the WAN, but whilst the GW was down (which it will be for a little bit after a reboot) NAT Rules aren't yet in effect and hence it was letting through the ZeroTier traffic without NAT.  Once the GW came up, the NAT rules start working and the additional states for NAT get created.  However, as there is already an earlier state for the NON NAT case, this continues to get processed.  As ZeroTier constantly is sending udp traffic, the early state never times out and expires.

By having this feature ticked,  the rules are not in place until the GW is up.  So the NAT is in place before the rules that allow the ZeroTier traffic out are hit. 

I've done a number of reboots since enabling this option and so far, I've not seen a repeat of the issue.  Time will tell if I've broken anything else by doing this though :-)

Hopefully this will help in your situation.