[SOLVED] Firewall:NAT:Outbound. Manual sets WAN IP address to current DHCP lease

[weust]

Before I file this as a bug on github, I wanted to put it here first. In case I missed anything.

I've set a Outbound rule for my PlayStation console to have Static Port mapping to the outside world.
It needs that for NAT Type 2.
Therefore I set the Mode to Manual Outbound NAT rule generation.

After I set the mode, the NAT Aaddress changed the auto generated rules from "WAN address" to the current DHCP IP address of my WAN connection.
The rule still shows "WAN Address" being selected though.

I just ran into the issue when my WAN address got a new lease, and a new address, and I was unable to do anything internet wise.

[weust]

It does this on Automatic outbound NAT rule generation as well.

[weust]

For some reason adding a mapping to the Auto rule generation option doesn't work for me.
Setting it to Manual, and not even editing the mapping I created under Auto, makes the PlayStation work at NAT type 2. Otherwise it's NAT type 3

[franco]

Tom, what's the status on this? Anything to do here from a dev perspective? :)

[weust]

Well, having the page showing what it set in the rule instead of resolving what the WAN address is would be nice. So interface type, not IP address.

And having "Automatic outbound NAT rule generation" work like it should would help, as right now it doesn't.
Meaning the adding a rule to Mappings.

[franco]

pfSense kindly noticed that they had the same issue. There'll be a fix in the repository today, but unfortunately not in time for 15.1.7.1.

[weust]

Good to hear it's not just me then.
As mentioned on IRC there is a workaround, so I'm ok for now.

[franco]

Can you please confirm this is working now with 15.1.7.2? :)

[weust]

I will do this tomorrow evening or Thursday evening.
Got things I want to do and will therefore create a new VM for OPNsense.
And before I will restore the backup config, I wil test this part.

[weust]

Setting the mode to manual leaves the WAN type alone now, so that's good.
However, upon clicking the Save button, it throws out an error:

Fatal error: Uncaught exception 'Exception' with message 'Failed to connect: No such file or directory' in /usr/local/opnsense/mvc/app/library/OPNsense/Core/Backend.php:65 Stack trace: #0 /usr/local/etc/inc/util.inc(158): OPNsense\Core\Backend->sendEvent('filter sync') #1 /usr/local/etc/inc/util.inc(1604): send_event('filter sync') #2 /usr/local/etc/inc/config.lib.inc(534): carp_sync_client() #3 /usr/local/www/firewall_nat_out.php(114): write_config() #4 {main} thrown in /usr/local/opnsense/mvc/app/library/OPNsense/Core/Backend.php on line 65

This is on a 15.1.6.1-LibreSSL upgraded to 15.1.7.2_1-bdd927343.

[franco]

The configd socket wasn't there it seems. You always seem to trigger daemon-related issues with your setup, but I'm not sure why. It is mostly harmless, except that it doesn't reload the new settings. A reboot should fix this. A couple of tweaks went into 15.1.8 that may make this go away, otherwise we'll have to debug with a microscope.

[weust]

This was actually a new setup. Moved from Hyper-V 2012 R2 to EAXi 6.0.0.

I don't know why I trigger these things. It's not like I am doing weird things IMO.

[franco]

Nothing weird indeed. I wasn't indicating that. ;) How many CPUs are you using?

[weust]

I didn't mean it like that. But I know I can do weird things when trying things out :-)

I use 2 virtual CPU's for the VM.