Shorewall devel - Aug 2004 - who gives access? was: why ADD_DNAT_ALIASES missing?

hi,
there was some email problems and i repeat my question too fast, but 
this is the second part of my questions.
- only the rules and policy files give access right? ie. rules in the 
FORWARD chain of the filter table in iptables ?
- is a line in masq file automaticaly add an accept rule too? eg. in
msaq file
eth0 <internal ip>
allow connection from <internal ip> (local zona) to the net zone
(eth0''s
zone)?
- is a line in the nat file automaticaly add an accept rule too? eg. in
nat file:
<external ip> eth0:5  <internal ip>
allow connection from BOTH <internal ip> (local zona) to the net zone
(eth0''s zone) and from the net zone to the <internal ip>?
or should i also have to add these to the rules file?
- if the above two is not true tha why the DNAT rules do so? something 
similar like dnat- would be useful (just the opposite for masw and nat).
- if there is dnat rules why there is not snat?
i try to read all doc but these are not documented very well. some kind
of advanced documentation would be useful for those how know the ip and
iptables command .eg. "a dnat rule add such an iptables commands ..."
etc.
thanks in advance.
yours.

-- 
   Levente                               "Si vis pacem para bellum!"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Farkas Levente wrote:
| hi,
| there was some email problems and i repeat my question too fast, but
| this is the second part of my questions.
| - only the rules and policy files give access right? ie. rules in the
| FORWARD chain of the filter table in iptables ?
| - is a line in masq file automaticaly add an accept rule too? eg. in
| msaq file
| eth0 <internal ip>
| allow connection from <internal ip> (local zona) to the net zone
(eth0''s
| zone)?
| - is a line in the nat file automaticaly add an accept rule too? eg. in
| nat file:
| <external ip> eth0:5  <internal ip>
| allow connection from BOTH <internal ip> (local zona) to the net zone
| (eth0''s zone) and from the net zone to the <internal ip>?
| or should i also have to add these to the rules file?
| - if the above two is not true tha why the DNAT rules do so? something
| similar like dnat- would be useful (just the opposite for masw and nat).
| - if there is dnat rules why there is not snat?
| i try to read all doc but these are not documented very well. some kind
| of advanced documentation would be useful for those how know the ip and
| iptables command .eg. "a dnat rule add such an iptables commands
..." etc.
| thanks in advance.
| yours.
|

Please wait for my response AND READ IT before asking the same questions
over and over again!!!!!!!

- -Tom
- --
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBGSh5O/MAbZfjDLIRAiRXAJ4+u3zrj+PxDJ/4NcufwWqxjlaZXACfTe3I
UufqD1Hb4KkEi9312qZ3p80=FYXl
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Farkas Levente wrote:

| - if the above two is not true tha why the DNAT rules do so?

So that people don''t have to make two entries to implement a simple
port-forwarding rule.

| something
| similar like dnat- would be useful (just the opposite for masw and nat).

In the Shorewall2/ CVS project, there is a DNAT ONLY column in the
/etc/shorewall/nat file that suppresses the SNAT rules; I think that''s
wnat you are asking for.

| - if there is dnat rules why there is not snat?

Because under Netfilter it is impossible to implement an SNAT rule that
works like the other rule types.

- -Tom
- --
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBGS7aO/MAbZfjDLIRAkt0AKC73Hb/FWCVxqQri4ii0vYQSZH9ZwCfcWmf
zkDxeophJP+UquxttShHfA8=OZ4X
-----END PGP SIGNATURE-----

On Tue, 2004-08-10 at 22:23, Tom Eastep wrote:
> | something
> | similar like dnat- would be useful (just the opposite for masw and nat).
> 
> In the Shorewall2/ CVS project, there is a DNAT ONLY column in the
> /etc/shorewall/nat file that suppresses the SNAT rules; I think
that''s
> wnat you are asking for.
yes! thanks.
> | - if there is dnat rules why there is not snat?
> 
> Because under Netfilter it is impossible to implement an SNAT rule that
> works like the other rule types.
why? snat is just a bit generic masquarade. in our current hand made
iptables rules we have such lines:
-A PREROUTING -d <public ip> -p tcp -m tcp --dport ssh -j DNAT
--to-destination <private ip>
-A POSTROUTING -o eth0 -s <private ip>/24 -d ! <private ip>/24 -p
tcp -m
tcp --dport ssh -j SNAT --to-source <public ip>
for me they are similar.

Farkas wrote on 10/08/2004 18:01:24:
> On Tue, 2004-08-10 at 22:23, Tom Eastep wrote:
[...]
> why? snat is just a bit generic masquarade. in our current hand made
> iptables rules we have such lines:
> -A PREROUTING -d <public ip> -p tcp -m tcp --dport ssh -j DNAT
> --to-destination <private ip>
> -A POSTROUTING -o eth0 -s <private ip>/24 -d ! <private ip>/24
-p tcp -m
> tcp --dport ssh -j SNAT --to-source <public ip>
> for me they are similar.
my advice: time to RTFM (on iptables and on shorewall).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Farkas Levente wrote:
| On Tue, 2004-08-10 at 22:23, Tom Eastep wrote:
|
|>| something
|>| similar like dnat- would be useful (just the opposite for masw and nat).
|>
|>In the Shorewall2/ CVS project, there is a DNAT ONLY column in the
|>/etc/shorewall/nat file that suppresses the SNAT rules; I think
that''s
|>wnat you are asking for.
|
|
| yes! thanks.
|
|
|>| - if there is dnat rules why there is not snat?
|>
|>Because under Netfilter it is impossible to implement an SNAT rule that
|>works like the other rule types.
|
|
| why? snat is just a bit generic masquarade. in our current hand made
| iptables rules we have such lines:
| -A PREROUTING -d <public ip> -p tcp -m tcp --dport ssh -j DNAT
| --to-destination <private ip>
| -A POSTROUTING -o eth0 -s <private ip>/24 -d ! <private ip>/24 -p
tcp -m
| tcp --dport ssh -j SNAT --to-source <public ip>
| for me they are similar.

All of which can be done with Shorwall WITHOUT SNAT Rules.

- -Tom
- --
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBGTjiO/MAbZfjDLIRAmgLAJ4q+rmCpVVbFySxkmyBBzkwpY9UUgCfVyY0
I6/rhzpDj2BEmAihgwOCy24=QbG6
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Eastep wrote:
| Farkas Levente wrote:
| | On Tue, 2004-08-10 at 22:23, Tom Eastep wrote:
| |
| |>| something
| |>| similar like dnat- would be useful (just the opposite for masw and
| nat).
| |>
| |>In the Shorewall2/ CVS project, there is a DNAT ONLY column in the
| |>/etc/shorewall/nat file that suppresses the SNAT rules; I think
that''s
| |>wnat you are asking for.
| |
| |
| | yes! thanks.
| |
| |
| |>| - if there is dnat rules why there is not snat?
| |>
| |>Because under Netfilter it is impossible to implement an SNAT rule that
| |>works like the other rule types.
| |
| |
| | why? snat is just a bit generic masquarade. in our current hand made
| | iptables rules we have such lines:
| | -A PREROUTING -d <public ip> -p tcp -m tcp --dport ssh -j DNAT
| | --to-destination <private ip>
| | -A POSTROUTING -o eth0 -s <private ip>/24 -d ! <private ip>/24
-p tcp -m
| | tcp --dport ssh -j SNAT --to-source <public ip>
| | for me they are similar.
|
| All of which can be done with Shorwall WITHOUT SNAT Rules.
|

Note that there is a way to specify SNAT as part of a DNAT rule -- I''ve
always been dissatisfied with that and I will probably remove the
capability in 2.1 (Now that SNAT can be restricted to a particular
protocol and port, the need for SNAT as part of a DNAT rule is removed).

- -Tom
- --
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBGUPyO/MAbZfjDLIRAgy2AKCkIdndzCFt77s/3dmUGWtKcx3ccACffrB5
yeRbpcMs6/ucaPSTJ6S3XR0=QJUF
-----END PGP SIGNATURE-----

hi,
i move this thread to the devel list since it''s no longer a user
questions.
so i understand the shorewall "philosophy". ie:
- dnat rules should have to put int rules file,
- snat (and regular masquarade) should have to put into masq file,
- bidirectional nat (ie. both snat and dnat) and only dnat should have 
to put into the nat file.
so the current situation is that we can do everything in shorewall!
but let''s go back to the original goal (if i dare to guess
tom''s
goal:-). to create a something which do the same as iptables but in a 
higher level and gives less chance for errors.
my only cosmetic problem here is that not realy symmetric and users can 
be made fault. my problems:
- if ones add a line to the masq or nat file than (most of the case) he 
also should have to add an accept line to the rules file.
- users define dnat in rules file while snat/masq in masq file. so for 
dnat (except dnat-) they don''t have to write a paralell accept line, 
while for snat he must, which is easy to forget.
- masq file is for masq and snat
- nat file is for dnat and both dnat and snat, this is also not to symatric.
- the same dnat can be defined in rules file (dnat-) and also in the nat 
file (dnat only).

so my suggestions:
- add snat and masq possibility to the rules file which can be similar 
to the current dnat (automaticaly create an accept rule).
- somehow standardize the format of the masq and nat files may be 
similar/same to the rules file, use there separate file snat, dnat and 
nat. or simple use one file, made it possible to define snat, dnat and 
nat (both snat and dnat) in the current nat file.
in this case those (most users) who would like to add an accept line 
also can in the rules file. and those who would like to separate the nat 
and the access right can use policy/rules only for access right and 
nat/masq files for nat in a symmetric and imho a more transparent way.

these are just "cosmetic" changes, but imho it makes shorewall a
cleaner
and transparent.

just my 2c.

Tom Eastep wrote:
> Tom Eastep wrote:
> | Farkas Levente wrote:
> | | On Tue, 2004-08-10 at 22:23, Tom Eastep wrote:
> | |
> | |>| something
> | |>| similar like dnat- would be useful (just the opposite for masw and
> | nat).
> | |>
> | |>In the Shorewall2/ CVS project, there is a DNAT ONLY column in the
> | |>/etc/shorewall/nat file that suppresses the SNAT rules; I think
that''s
> | |>wnat you are asking for.
> | |
> | |
> | | yes! thanks.
> | |
> | |
> | |>| - if there is dnat rules why there is not snat?
> | |>
> | |>Because under Netfilter it is impossible to implement an SNAT rule
that
> | |>works like the other rule types.
> | |
> | |
> | | why? snat is just a bit generic masquarade. in our current hand made
> | | iptables rules we have such lines:
> | | -A PREROUTING -d <public ip> -p tcp -m tcp --dport ssh -j DNAT
> | | --to-destination <private ip>
> | | -A POSTROUTING -o eth0 -s <private ip>/24 -d ! <private
ip>/24 -p
> tcp -m
> | | tcp --dport ssh -j SNAT --to-source <public ip>
> | | for me they are similar.
> |
> | All of which can be done with Shorwall WITHOUT SNAT Rules.
> |
> 
> Note that there is a way to specify SNAT as part of a DNAT rule --
I''ve
> always been dissatisfied with that and I will probably remove the
> capability in 2.1 (Now that SNAT can be restricted to a particular
> protocol and port, the need for SNAT as part of a DNAT rule is removed).
-- 
   Levente                               "Si vis pacem para bellum!"

Eduardo Ferreira wrote:
> Farkas wrote on 10/08/2004 18:01:24:
> 
> 
>>On Tue, 2004-08-10 at 22:23, Tom Eastep wrote:
> 
> [...]
> 
>>why? snat is just a bit generic masquarade. in our current hand made
>>iptables rules we have such lines:
>>-A PREROUTING -d <public ip> -p tcp -m tcp --dport ssh -j DNAT
>>--to-destination <private ip>
>>-A POSTROUTING -o eth0 -s <private ip>/24 -d ! <private
ip>/24 -p tcp -m
>>tcp --dport ssh -j SNAT --to-source <public ip>
>>for me they are similar.
> 
> 
> my advice: time to RTFM (on iptables and on shorewall). 
did you read the original mail and my reply to it?
my advice: time to read the mails before reply.
tom wrote:
"Because under Netfilter it is impossible to implement an SNAT rule that
  works like the other rule types."
i just show an example with one dnat and one snat rules, both are 
netfilter rules and they work similar. so it is possible with netfiter 
to implement it.

-- 
   Levente                               "Si vis pacem para bellum!"

Farkas Levente wrote:
> so i understand the shorewall "philosophy". ie:
> - dnat rules should have to put int rules file,
Yes.
> - snat (and regular masquarade) should have to put into masq file,
Yes.
> - bidirectional nat (ie. both snat and dnat) and only dnat should have 
> to put into the nat file.
Originally, only bidirectional nat. While the current Shorewall2/ CVS
tree has added ''dnat-only'' to this file, this gives us two
ways to do
DNAT which I don''t particularly like.
> so the current situation is that we can do everything in shorewall!
> but let''s go back to the original goal (if i dare to guess
tom''s
> goal:-). to create a something which do the same as iptables but in a 
> higher level and gives less chance for errors.
I didn''t intend that it could do everything that iptables can do -- but
that''s close.
> my only cosmetic problem here is that not realy symmetric and users can 
> be made fault. my problems:
> - if ones add a line to the masq or nat file than (most of the case) he 
> also should have to add an accept line to the rules file.
Actually, the user generally has to add more that one rule.
> - users define dnat in rules file while snat/masq in masq file. so for 
> dnat (except dnat-) they don''t have to write a paralell accept
line,
> while for snat he must, which is easy to forget.
I don''t believe that -- 99% of users that use SNAT/MASQ have exactly
one
entry in their /etc/shorewall/masq file.
> - masq file is for masq and snat
> - nat file is for dnat and both dnat and snat, this is also not to 
> symatric.
I''m inclined to remove the dnat-only part.
> - the same dnat can be defined in rules file (dnat-) and also in the nat 
> file (dnat only).
> 
> so my suggestions:
> - add snat and masq possibility to the rules file which can be similar 
> to the current dnat (automaticaly create an accept rule).
Unfortunately, it isn''t possible in many cases to construct a SNAT/MASQ
rule that matches the ACCEPT rule. Until such time (if it ever comes)
that the "-i" option is available in POSTROUTING, I''m not
going to
implement SNAT/MASQ rules in /etc/shorewall/rules.

Note that it *would* be possible to make a matching rule using packet
marking; unfortunately, since the MARK target doesn''t allow a logical
OR
operation, it is not possible for Shorewall to use packet marking
internally since such use would overwrite the user''s use of marking
(/etc/shorewall/tcrules).
> - somehow standardize the format of the masq and nat files may be 
> similar/same to the rules file, use there separate file snat, dnat and 
> nat. or simple use one file, made it possible to define snat, dnat and 
> nat (both snat and dnat) in the current nat file.
No -- the purpose of the /etc/shorewall/nat file is to define one-to-one
NAT and that''s all. It doesn''t need all of the baggage
that''s in the
rules file.

> in this case those (most users) who would like to add an accept line 
> also can in the rules file. and those who would like to separate the nat 
> and the access right can use policy/rules only for access right and 
> nat/masq files for nat in a symmetric and imho a more transparent way.
> 
> these are just "cosmetic" changes, but imho it makes shorewall a
cleaner
> and transparent.
> 
> just my 2c.
Thanks!

-Tom
--
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Mentally, I have always compared the Shorewall configuration files,
such as policy and rules, to 4th normal relational database tables.
Keeping the Shorewall configuration files in 4th normal form is possibly
the hardest part of the project.  Tom, of course, has never said that
his configuration files were going to be 4th normal form.

The reason I like Shorewall is that the configuration files are generally
very easy to understand.  I support any changes that make the configuration
files clean and easy to understand even if the changes were incompatible
with previous versions.

-- 
Steve Herber	herber@thing.com		work: 206-221-7262
Security Engineer, UW Medicine, IT Services	home: 425-454-2399

On Wed, 11 Aug 2004, Farkas Levente wrote:
> hi,
> i move this thread to the devel list since it''s no longer a user
questions.
> so i understand the shorewall "philosophy". ie:
> - dnat rules should have to put int rules file,
> - snat (and regular masquarade) should have to put into masq file,
> - bidirectional nat (ie. both snat and dnat) and only dnat should have 
> to put into the nat file.
> so the current situation is that we can do everything in shorewall!
> but let''s go back to the original goal (if i dare to guess
tom''s
> goal:-). to create a something which do the same as iptables but in a 
> higher level and gives less chance for errors.
> my only cosmetic problem here is that not realy symmetric and users can 
> be made fault. my problems:
> - if ones add a line to the masq or nat file than (most of the case) he 
> also should have to add an accept line to the rules file.
> - users define dnat in rules file while snat/masq in masq file. so for 
> dnat (except dnat-) they don''t have to write a paralell accept
line,
> while for snat he must, which is easy to forget.
> - masq file is for masq and snat
> - nat file is for dnat and both dnat and snat, this is also not to
symatric.
> - the same dnat can be defined in rules file (dnat-) and also in the nat 
> file (dnat only).
> 
> so my suggestions:
> - add snat and masq possibility to the rules file which can be similar 
> to the current dnat (automaticaly create an accept rule).
> - somehow standardize the format of the masq and nat files may be 
> similar/same to the rules file, use there separate file snat, dnat and 
> nat. or simple use one file, made it possible to define snat, dnat and 
> nat (both snat and dnat) in the current nat file.
> in this case those (most users) who would like to add an accept line 
> also can in the rules file. and those who would like to separate the nat 
> and the access right can use policy/rules only for access right and 
> nat/masq files for nat in a symmetric and imho a more transparent way.
> 
> these are just "cosmetic" changes, but imho it makes shorewall a
cleaner
> and transparent.
> 
> just my 2c.
> 
> Tom Eastep wrote:
> > Tom Eastep wrote:
> > | Farkas Levente wrote:
> > | | On Tue, 2004-08-10 at 22:23, Tom Eastep wrote:
> > | |
> > | |>| something
> > | |>| similar like dnat- would be useful (just the opposite for
masw and
> > | nat).
> > | |>
> > | |>In the Shorewall2/ CVS project, there is a DNAT ONLY column in
the
> > | |>/etc/shorewall/nat file that suppresses the SNAT rules; I think
that''s
> > | |>wnat you are asking for.
> > | |
> > | |
> > | | yes! thanks.
> > | |
> > | |
> > | |>| - if there is dnat rules why there is not snat?
> > | |>
> > | |>Because under Netfilter it is impossible to implement an SNAT
rule that
> > | |>works like the other rule types.
> > | |
> > | |
> > | | why? snat is just a bit generic masquarade. in our current hand
made
> > | | iptables rules we have such lines:
> > | | -A PREROUTING -d <public ip> -p tcp -m tcp --dport ssh -j
DNAT
> > | | --to-destination <private ip>
> > | | -A POSTROUTING -o eth0 -s <private ip>/24 -d ! <private
ip>/24 -p
> > tcp -m
> > | | tcp --dport ssh -j SNAT --to-source <public ip>
> > | | for me they are similar.
> > |
> > | All of which can be done with Shorwall WITHOUT SNAT Rules.
> > |
> > 
> > Note that there is a way to specify SNAT as part of a DNAT rule --
I''ve
> > always been dissatisfied with that and I will probably remove the
> > capability in 2.1 (Now that SNAT can be restricted to a particular
> > protocol and port, the need for SNAT as part of a DNAT rule is
removed).
> 
>

Tom Eastep wrote:
> Farkas Levente wrote:
>> my only cosmetic problem here is that not realy symmetric and users 
>> can be made fault. my problems:
>> - if ones add a line to the masq or nat file than (most of the case) 
>> he also should have to add an accept line to the rules file.
> 
> 
> Actually, the user generally has to add more that one rule.
> 
>> - users define dnat in rules file while snat/masq in masq file. so for 
>> dnat (except dnat-) they don''t have to write a paralell accept
line,
>> while for snat he must, which is easy to forget.
> 
> 
> I don''t believe that -- 99% of users that use SNAT/MASQ have
exactly one
> entry in their /etc/shorewall/masq file.
my "one line"s was just example and do not think that these files
contains only one lines rather "one of those lines" or "one lines
for
one lines".
>> - the same dnat can be defined in rules file (dnat-) and also in the 
>> nat file (dnat only).
>>
>> so my suggestions:
>> - add snat and masq possibility to the rules file which can be similar 
>> to the current dnat (automaticaly create an accept rule).
> 
> 
> Unfortunately, it isn''t possible in many cases to construct a
SNAT/MASQ
> rule that matches the ACCEPT rule. Until such time (if it ever comes) 
> that the "-i" option is available in POSTROUTING, I''m
not going to
> implement SNAT/MASQ rules in /etc/shorewall/rules.
i don''t know that part. for dnat rules there is no -o and? in this case
you don''t define interface, since you may not define any interface.
>> - somehow standardize the format of the masq and nat files may be 
>> similar/same to the rules file, use there separate file snat, dnat and 
>> nat. or simple use one file, made it possible to define snat, dnat and 
>> nat (both snat and dnat) in the current nat file.
> 
> 
> No -- the purpose of the /etc/shorewall/nat file is to define one-to-one 
> NAT and that''s all. It doesn''t need all of the baggage
that''s in the
> rules file.
here i refere to the masq and nat files format (not to the rules).

-- 
   Levente                               "Si vis pacem para bellum!"