Hi all, I''ve been using Shorewall since 1.x and I must say, its probably the most comprehensive and flexible firewall abstraction layer to iptables. Thumbs-up Tom! Now, to business.. All my hosts which I''m doing 1:1 NAT from eth0 (wan) to eth2(windows-dmz) or eth3(unix-dmz), and I have to keep the "ALL Interfaces" parameter set to NO, because whenever I have a host transiting from one interface to another on the firewall I want to preserve its original internal address instead of translating it to the IP address thats on eth0. But at the same time, I need to source-nat all connections to the DNAT IP''s because occasionally (in other words, having ALL Interfaces set to YES) some applications don''t use proper DNS, and I want to be able to loop-through the firewall instead of having the connection fail. So, in essence, HostA (10.10.10.10/eth2)---> HostB (10.10.11.10/eth3), host B should see the IP of hostA, so no DNAT/SNAT. HostA (10.10.10.10/eth2)---> HostA-WANIP (123.123.123.10/eth0), should SNAT as Firewall (123.123.123.1/eth0), in order to DNAT back to 10.10.10.10/eth2. I manage to do this pretty regularly on Sonicwall''s since I can specify the source & destination interface for NAT pattern-matching, an consequently, the NAT is done as desired. What would be the approach with shorewall? I tried various combinations with /etc/shorewall/masq but have failed miserably :( Ideas? Many thanks Kris ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Kristopher Lalletti wrote:> > What would be the approach with shorewall? I tried various > combinations with /etc/shorewall/masq but have failed miserably :( >The Shorewall approach is to realize that if you have enough public IP addresses to use 1-to-1 NAT for your Internet-accessible internal servers then NAT is the wrong approach. You should be using plain routing (possibly augmented by Proxy ARP). That may require you to add another NIC to your firewall so that you have: a) net b) loc c) dmz d) Those servers that for some reason you choose to put in your ''loc'' zone rather that in the ''dmz'' zone. My personal belief is that there is no valid reason for this class of server to exist at all and very valid reasons to think that they should not exist at all. But from your post, it seems that you may have them. See Shorewall FAQ 2 for a discussion of why I think that such servers are a very bad idea. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Fri, Nov 09, 2007 at 07:22:51PM -0800, Tom Eastep wrote:> d) Those servers that for some reason you choose to put in your ''loc'' > zone rather that in the ''dmz'' zone. My personal belief is that there > is no valid reason for this class of server to exist at all and very > valid reasons to think that they should not exist at all. But from > your post, it seems that you may have them. See Shorewall FAQ 2 for a > discussion of why I think that such servers are a very bad idea.For the sake of completeness - this can be a valid configuration when you have multiple firewalls (or filtering routers, if you can afford such beasts), so from the perspective of the firewall on the internet border they''re all in one zone, but something else in the network is segregating them from each other. Such configurations are going to be rare. I have only one of them, at our largest site (~70-100 hosts over two buildings). ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Eastep wrote:> Kristopher Lalletti wrote: > >> What would be the approach with shorewall? I tried various >> combinations with /etc/shorewall/masq but have failed miserably :( >> > > The Shorewall approach is to realize that if you have enough public IP > addresses to use 1-to-1 NAT for your Internet-accessible internal > servers then NAT is the wrong approach.But, if you want to continue to use NAT, then it sounds like you need to add some DNAT- rules. An entry in /etc/shorewall/nat is nearly equivalent to an SNAT rule and a DNAT- rule. Example: /etc/shorewall/nat 206.124.146.178 $EXT_IF:0 192.168.1.3 where $EXT_IF is the wan interface is the same as /etc/shorewall/masq: $EXT_IF 192.168.1.3 206.124.146.178 and /etc/shorewall/rules: DNAT- wan lan:192.168.1.3 - - - 206.124.146.178 So if you wanted connection attempts from the dmz zone to 206.124.146.178 to be sent to 192.168.1.3, you could add: DNAT- dmz lan:192.168.1.3 - - - 206.124.146.178 By using DNAT- rather than DNAT, you can then specify the traffic that you wish to allow using regular ACCEPT rules (DNAT would generate a blanket ACCEPT rule which is probably not what you want). HTH, - -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 v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHNcecO/MAbZfjDLIRAjJhAKC2nUkoSrEx5FK+/x9wesM4CVb8SwCfah0L 6PDFmdR1MbHoqn9I/FV1pmM=N0Yu -----END PGP SIGNATURE----- ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Indeed, the DNAT- rule worked like a charm. I wasn''t too keen on using it since it was already declared from the /etc/shorewall/nat file, and I was convinced that it may have a been a question of priority in rules that needed to be tweaked. I am in fact in a multi-homed network, and dealing with 2 distinct firewalls to make matters a little complex. So I only want to NAT when necessary for dmz-wan communications, and conserve the internal IP''s for routing purposes between zoned and other networks & vpn''s. Thanks for the help! Kris On 11/10/07, Tom Eastep <teastep@shorewall.net> wrote:> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tom Eastep wrote: > > Kristopher Lalletti wrote: > > > >> What would be the approach with shorewall? I tried various > >> combinations with /etc/shorewall/masq but have failed miserably :( > >> > > > > The Shorewall approach is to realize that if you have enough public IP > > addresses to use 1-to-1 NAT for your Internet-accessible internal > > servers then NAT is the wrong approach. > > But, if you want to continue to use NAT, then it sounds like you need to > add some DNAT- rules. > > An entry in /etc/shorewall/nat is nearly equivalent to an SNAT rule and > a DNAT- rule. > > Example: > > /etc/shorewall/nat > > 206.124.146.178 $EXT_IF:0 192.168.1.3 > > where $EXT_IF is the wan interface is the same as > > /etc/shorewall/masq: > > $EXT_IF 192.168.1.3 206.124.146.178 > > and /etc/shorewall/rules: > > DNAT- wan lan:192.168.1.3 - - - 206.124.146.178 > > So if you wanted connection attempts from the dmz zone to > 206.124.146.178 to be sent to 192.168.1.3, you could add: > > DNAT- dmz lan:192.168.1.3 - - - 206.124.146.178 > > By using DNAT- rather than DNAT, you can then specify the traffic that > you wish to allow using regular ACCEPT rules (DNAT would generate a > blanket ACCEPT rule which is probably not what you want). > > HTH, > - -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 v2.0.4-svn0 (GNU/Linux) > Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org > > iD8DBQFHNcecO/MAbZfjDLIRAjJhAKC2nUkoSrEx5FK+/x9wesM4CVb8SwCfah0L > 6PDFmdR1MbHoqn9I/FV1pmM> =N0Yu > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/