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:65535  
    
    

    That 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:65535  
    
    

    And 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.


Log in to reply