On Fri, Apr 21, 2006 at 11:38:11AM -0700, Jon Simola wrote: > This is totally repeatable, and keeps biting me. Is this a bug or feature?
I think it's expected that -N only reads and honours NAT rules, and ignores anything else, including any options like 'set skip'. The man page is clear on that, IMO. What isn't so clear is whether it should first clear (reset) all options before loading the new NAT rules. Basically, any invokation that changes something first resets the options. You'll have to add the -O option to the invokation to re-parse and reload the options after the (implicit) reset. -N isn't special in that regard, -R behaves the same. Whether the man page is clear about the result of using a combination of -N, -R, and -O simultanously, I'm not sure. The implict reset was added intentionally, I think Theo feels strongly about it. The idea is that you don't get different results from incremental reloads in different orders, i.e. reparsing the file produces one well-defined state no matter what the state was beforehand. The addition of -m muddied the issue further, I'm not sure what it is expected to do when combined with -N. You could argue the case that -N (and -R) shouldn't cause an implicit option reset, but only a plain -f should. But that's not up to me to decide, and it's not a simple implementation buglet, but at least somewhat intentional ;) Personally, I always reload the entire rules with -f without -N/-R, so this hasn't bothered me yet. HTH, Daniel