Re: [Fwbuilder-discussion] Firewall Builder v2.0.3, build #420

[<ch...@sy...>]

Hi,

fwbuilder build 420 on SuSE 9.0.  Created new firewall config "testfw" 
for pf/OpenBSD and tested the generated ruleset on OpenBSD 3.5-stable.

* Groups of negated objects generate syntactically invalid rules.  A rule
  object like this: 

    src       dest    svc     action
    not int1  ext100  telnet  accept
    not int2

  generates this rule, which gives a syntax error when loaded:

    pass in   quick inet proto tcp  from ! { 10.0.0.33 , 10.0.0.34 }  
				    to 192.0.2.9 port 23 modulate state

  A negated list "! { ... }" is not allowed by pf's syntax.  Individual 
  list entries can be negated, but not the list itself.  Then again, 
  negated list entries don't really make sense to me.  Do you have a 
  reasonable example for negation?

* You mention "implemented negation through tables" in the v420 log entry. 
  But I don't see tables defined or referenced in the generated ruleset, 
  and the "Use tables" checkbox doesn't seem to do anything, there is no 
  difference if it is checked or unchecked.

  Could it be a semantic confusion on your side, interpreting lists "{...}" 
  as tables?  A table could be initialized from a list and then used in 
  firewall rules like this (note the angle brackets are verbatim):

    table <inthosts> { 10.0.0.33 , 10.0.0.34 }
    pass in quick inet proto icmp from <inthosts> to 192.0.2.9

* I'm missing "flags S/SA" in front of "modulate state" for TCP firewall 
  rules, much like "flags S" gets added to ipfilter rules when "Accept TCP 
  sessions opened prior to firewall restart" is checked.  Note that 
  "flags S/SA" is recommended by the pf community, while "flags S" would be 
  syntactically invalid.  Other than that, this is the same as with ipfilter.

* Could you add logging to the generated fallback rule?  Maybe as a 
  checkbox in "Firewall/Firewall Settings/Logging"?  I always have to 
  specify a fallback rule manually in order to get fallthrough logging, 
  which kind of defeats the generated fallback rule.


I will do more testing, but I think you want to know about the syntax 
error stuff quickly.  


ciao,
chakl
-- 
Olaf Schreck    ch...@sy...        syscall() Network Solutions, Berlin