[Shorewall-users] Shorewall 1.3 Beta 1

Tom Eastep teastep@shorewall.net
Sat, 18 May 2002 06:33:51 -0700 (PDT)


On Fri, 17 May 2002, Steve Herber wrote:

> I started using a Cisco Pix firewall about three years ago and the
> main problem I had was understanding some of the syntax for the port
> forwarding rules.  What I really liked about shorewall was how simple
> the configuration files were for the simple cases.  But I have always
> had a problem with the rules file because of the multiple possibilities.
> Not that the possibilities are bad, but because the syntax, just like the
> Pix syntax, doesn't fit the way I look at network connections.  I agree
> with John that lots happens in the file.
>

As I just wrote to John, port forwarding rules are confusing because they 
are actually two rules. If, as iptables does, you make these two rules 
totally separate then both rules are very easy to understand but then you 
have to remember to add two rules when you want to port forward rather 
than just one rule (and you have to remember to delete both rules when you 
no longer want to port forward).
 
> I really like systems to be regular and consistent.  Is there a reason that
> the order of the fields in the rules file and the tos file are different both
> in order and in name?  The same goes for the policy file where the RESULT
> field is at the other end of the line and has a different name.  And is there
> a good reason to use SOURCE/DEST some places but CLIENT/SERVER others?
> 
> The current rules file:
> RESULT  CLIENT(S)  SERVER(S)  PROTO  PORT(S)  CLIENT_PORT(S)  ADDRESS
> 
> The current tos file:
> SOURCE  DEST  PROTOCOL  SOURCE_PORTS  DEST_PORTS  TOS
> 
> The current policy file:
> CLIENT  SERVER  POLICY  LOG LEVEL
> 
> 
> Could these be changed to:
> 
> The new rules file:
> POLICY  SOURCE(S)  DEST(S)  PROTO  SOURCE_PORT(S)  DEST_PORT(S)  ADDRESS
> 

Using POLICY for the the name of the first column is in my view even more 
confusing -- what is in this column ISN'T a policy but rather it is 
specifying what action to perform on connection requests that match this 
rule (that's why the column is called ACTION in 1.3).

Secondly, almost no rules specify SOURCE_PORT(S) -- so placing it before 
DEST_PORT(S) means that almost every rule is going to have to have "-" in 
that column (whereas placing it after DEST_PORTS(S) means that most rules 
can simply ignore it.

> The new tos file:
> SOURCE  DEST  PROTO  SOURCE_PORTS  DEST_PORTS  TOS
> 
> The new policy file:
> POLICY  SOURCE  DEST  LOG LEVEL
> 
> 
> Or, the way I like to read these, left to right:
> 
> The new rules file:
> POLICY  SOURCE(S)  PROTO  SOURCE_PORT(S)  DEST(S)  DEST_PORT(S)  ADDRESS
> 
> The new tos file:
> SOURCE  PROTO  SOURCE_PORTS  DEST  DEST_PORTS  TOS
> 
> The new policy file:
> POLICY  SOURCE  DEST  LOG LEVEL
> 
> 
> I don't have a good name for the ADDRESS filed in the rules file.  Maybe
> NAT_ADDRESS?
> 
> I know the discussion is about adding the new POLICY types, DNAT, and so on,
> but I wonder if these changes would help and maybe negate the need for the
> extra rules?
>

For the next beta, I'll clean up the config files and documentation so
that they uniformly use SOURCE and DESTINATION. That will make the code
harder to read but for the most part, that's my problem.

Can you do the same with the sample configuration files so that they match 
the documentation (right now, they come from an assortment of old versions 
and are woefully out of date)? 

Thanks,
-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
AIM: tmeastep  \ http://www.shorewall.net
ICQ: #60745924  \ teastep@shorewall.net