Auto to Manual Outboound NAT change required reboot
-
I had to do some extra outbound NAT on a system just now. I clicked for Manual Outbound NAT Rule Generation and save - good looking rules appeared. Then I addded a couple of rules to the end of the list, saved/applied. But I was "tearing my hair out" trying to work out why it did not work. Did packet captures and the new internal test networks I had added to the NAT rules list did not actually get NAT'd out WAN.
I looked at rules.debug and it looked like this:
# Subnets to NAT tonatsubnets = "{ 10.49.32.0/24 10.49.47.0/24 10.50.32.0/24 10.49.251.0/24 127.0.0.0/8 0.0.0.0 }" nat on $WAN from $tonatsubnets port 500 to any port 500 -> 202.xxx.xxx.xxx/32 port 500 nat on $WAN from $tonatsubnets to any -> 202.xxx.xxx.xxx/32 port 1024:65535That is what the automatic mode generates.
I tried editing and saving a firewall rule, in case that would trick it into rebuilding the whole of the pf rules based on the config - no joy.
Eventually I rebooted, and the NAT section of rules.debug is as expected:# Outbound NAT rules nat on $WAN from 10.49.32.0/24 to any port 500 -> 202.xxx.xxx.xxx/32 static-port nat on $WAN from 10.49.32.0/24 to any -> 202.xxx.xxx.xxx/32 port 1024:65535 nat on $WAN from 10.49.47.0/24 to any port 500 -> 202.xxx.xxx.xxx/32 static-port nat on $WAN from 10.49.47.0/24 to any -> 202.xxx.xxx.xxx/32 port 1024:65535 nat on $WAN from 127.0.0.0/8 to any -> 202.xxx.xxx.xxx/32 port 1024:65535 nat on $WAN from 10.50.32.0/24 to any -> 202.xxx.xxx.xxx/32 port 1024:65535 nat on $WAN from 10.49.251.0/24 to any -> 202.xxx.xxx.xxx/32 port 1024:65535 nat on $WAN from 10.99.0.0/16 to any port 500 -> 202.xxx.xxx.xxx/32 static-port nat on $WAN from 10.99.0.0/16 to any -> 202.xxx.xxx.xxx/32 port 1024:65535And my test networks in 10.99.0.0/16 happily NAT out to the public internet.
Is this a known "feature"?
(I will try and reproduce it later - and if I can reproduce then have a go at fixing it.) -
That means your ruleset isn't reloading. Is it logging a filter reload? The latest snapshot reloads the rules just fine, and that hasn't been broken at any time recently AFAIK.
-
I rebooted the box that had the issue - that was how I got it to work, so no logs available from that.
I tried reproducing any problem switching between Auto and Manual outbound NAT on another test system and can't break it. Everything I do is reflected correctly in config.xml and rules.debug at run time - no reboots needed.
So there was some weird condition that didn't implement my change on-the-fly on the production system, but I have no idea what sequence of clicks will produce it. If I come across this again one day, I will stop for longer and collect logs and investigate… before resorting to reboot. -
Logs aren't cleared on reboot any longer, so there's a good chance it's still there unless you're running something that logs to the system log a lot. clog /var/log/system.log
-
It is Alix nanoBSD - so /var is in memory and gone after reboot.
At the time, I had an issue with an OpenVPN server dying with "out of swap space" also. So I might have just been short of memory and the filter reload process died before it could do anything useful. -
ah ok, yeah in that case your logs are gone. It's possible that check_reload_status and its monitoring process were killed off when you ran out of RAM, which would prevent the rules from reloading.