Hi All, I check in FAQ and in Tom Eastep articles, but can''t find answer for my question. This is simple situation: I have dual homing connection to Internet, through two ISP but all two ISP links are managed by BGP. So I have AS number and my class "C" propagated by two BGP sessions (using Quagga). If one of this two links go down, full trafic is flowing through opposite link and this is very important for my network. But I''m using NAT (my LAN is bigger, than class "C"). So I have records in masq and in nat file translating my internal adresses to my (BGP propagated) IP adresses (static IP adresses of ISP ports are used very rarely). And... all rules I must manually duplicate for all two interfaces, because packets can go through any of this two ports and must be identically translated. Ofcourse, there is problem with probable errors. And if I will add third BGP connection, I should replicate half of rules with interface change. There should be natural to write ZONE name in INTERFACE column, where this zone contain both interfaces, but Shorewall not accept this. Here is a question: is there option to enable possibility of write zone name instead interface name in any rules file for automatically duplication rules for all interfaces in zone (or other method of groupping interfaces)? Or maybe exist other method to direct records about one interface automatically to another? Regards Andrzej Odyniec Warsaw, Poland ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Andrzej Odyniec wrote:> Here is a question: is there option to enable possibility of write zone name > instead interface name in any rules file for automatically duplication rules > for all interfaces in zone (or other method of groupping interfaces)? Or maybe > exist other method to direct records about one interface automatically to another?I''ll think about the notion of an ''interface group'' -- I won''t use zone names. Zones are security objects and should not be used for specifying packet rewriting. If I could design Shorewall over again, I wouldn''t even have DNAT and REDIRECT rules in the rules file but would rather have a separate file for specifying DNAT/REDIRECT. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Tom Eastep wrote:> Andrzej Odyniec wrote: > >> Here is a question: is there option to enable possibility of write zone name >> instead interface name in any rules file for automatically duplication rules >> for all interfaces in zone (or other method of groupping interfaces)? Or maybe >> exist other method to direct records about one interface automatically to another? > > I''ll think about the notion of an ''interface group'' -- I won''t use zone > names. Zones are security objects and should not be used for specifying > packet rewriting. If I could design Shorewall over again, I wouldn''t > even have DNAT and REDIRECT rules in the rules file but would rather > have a separate file for specifying DNAT/REDIRECT.Here''s an excerpt from the 4.1.4 release notes. HTH. 3) The /etc/shorewall/masq and /etc/shorewall/nat file now accept a comma-separated list of interface names where before only a single interface name could be listed (Shorewall-perl only). This feature is not for beginners. It iterates over the list of interfaces, substituting each interface in place of the list and processing the resulting entry according to the semantics of earlier Shorewall versions. If you don''t know where to use this, don''t try. Example 1: /etc/shorewall/masq: #INTERFACE SOURCE ADDRESS eth0,eth1 eth2 1.2.3.4 equivalent to: #INTERFACE SOURCE ADDRESS eth0 eth2 1.2.3.4 eth1 eth2 1.2.3.4 Example 2: /etc/shorewall/masq: #INTERFACE SOURCE ADDRESS eth0,eth1::192.168.1.0/24 eth2 1.2.3.4 equivalent to: #INTERFACE SOURCE ADDRESS eth0::192.168.1.0/24 eth2 1.2.3.4 eth1::192.168.1.0/24 eth2 1.2.3.4 Example 3: /etc/shorewall/nat: #EXTERNAL INTERFACE INTERNAL 206.124.146.178 eth0,wlan0 192.168.1.3 equivalent to: #EXTERNAL INTERFACE INTERNAL 206.124.146.178 eth0 192.168.1.3 206.124.146.178 wlan0 192.168.1.3 -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Tom Eastep wrote:> Tom Eastep wrote: >> Andrzej Odyniec wrote: >> >>> Here is a question: is there option to enable possibility of write zone name >>> instead interface name in any rules file for automatically duplication rules >>> for all interfaces in zone (or other method of groupping interfaces)? Or maybe >>> exist other method to direct records about one interface automatically to another? >> I''ll think about the notion of an ''interface group'' -- I won''t use zone >> names. Zones are security objects and should not be used for specifying >> packet rewriting. If I could design Shorewall over again, I wouldn''t >> even have DNAT and REDIRECT rules in the rules file but would rather >> have a separate file for specifying DNAT/REDIRECT. > > Here''s an excerpt from the 4.1.4 release notes. HTH. > > 3) The /etc/shorewall/masq and /etc/shorewall/nat file now accept a > comma-separated list of interface names where before only a single > interface name could be listed (Shorewall-perl only). > > This feature is not for beginners. It iterates over the > list of interfaces, substituting each interface in place of the > list and processing the resulting entry according to the semantics > of earlier Shorewall versions. If you don''t know where to use this, > don''t try.Note that placing ''Yes'' in the ALL INTERFACES column may have satisfied your requirements without this change. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Tom Eastep wrote:> > Note that placing ''Yes'' in the ALL INTERFACES column may have satisfied > your requirements without this change. >For the ''nat'' file, that is. -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 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Tom, Thanks for fast answer. Now you started new day but my day is ending. So: Tom Eastep wrote:> Tom Eastep wrote: >>Note that placing ''Yes'' in the ALL INTERFACES column may have satisfied >>your requirements without this change. > > For the ''nat'' file, that is. > > -TomYes. That rules go to chains: nat_in and nat_out instead <iface>_in and <iface>_out. But this will translate packets from DMZ and other interfaces too. And if that interfaces are normally NOT translated (as in my situation), because they have numbers from subclass of external class "C", transmission between LAN (translated) and DMZ (not translated) will be NAT-ed but it is not must. Transmission betwen not translated DMZ and translated LAN can be routed only, without NAT. Especially if it should be NAT-T. So this TOTAL translation isn''t elegant and may be not convenient. I think, better solution is grouping interfaces or enumerating interfaces according to your suggestion. Yes, in Shorewall conception zone can be subset or superset of interfaces. So you right: it isn''t good solution to allow use zones as general group of interfaces. But maybe other grouping tool is good solution. Years ago I programmed iptools using Monmotha script and for my needs I modified it and looped through list of external interfaces for duplicating rules. It was some method of enumerating interfaces. From other hand, "net" zone obtainable by some number of BGP interfaces is equivalent to one security (or unsecurity) zone, so in this situation maybe interfaces group is not necessary and maybe zone as specific group of interfaces is sufficient... (if it is superset of interfaces, not subset). Anyway, for BGP on number of interfaces we need notion: "group of interfaces" instead of one interface only. Ofcourse, BGP on client side is rare solution and ISPs are using mainly Cisco. But this needn''t be to the end of World... Regards Andrzej Odyniec Warsaw, Poland ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Andrzej Odyniec wrote:> > Anyway, for BGP on number of interfaces we need notion: "group of interfaces" > instead of one interface only. Ofcourse, BGP on client side is rare solution > and ISPs are using mainly Cisco. But this needn''t be to the end of World... >With the solution that I implemented (allowing a list of interfaces in the INTERFACE columns of nat and masq file), you can use variables to name interface groups: /etc/shorewall/params: NET=eth0,eth1 /etc/shorewall/masq: #INTERFACE SOURCE ADDRESS ... $NET ... I''ll be releasing 4.1.4 on 1/26/2008; it will include the change. -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tom Eastep wrote over year ago:> With the solution that I implemented (allowing a list of interfaces in > the INTERFACE columns of nat and masq file), you can use variables to > name interface groups: > > /etc/shorewall/params: > > NET=eth0,eth1 > > /etc/shorewall/masq: > > #INTERFACE SOURCE ADDRESS ... > $NET ... > > I''ll be releasing 4.1.4 on 1/26/2008; it will include the change.Tom, big thanks for this solution. It is working well last year. So well, so I can little suggestion for You to consider. This isn''t MHB or my need. Rather for consistency: All VPN I setup from OpenVPN tunnels. But last month I must set IPsec tunnels. When I set up IPsec tunnels, I need to expand internal security zones to tunneled adresses on external internet Interfaces. And in this place (hosts file) I need to declare delegated addresses of my internal security zone for all BGP interfaces separatelly, ie.:> crp eth2:172.23.0.0/18 ipsec > crp eth3:172.23.0.0/18 ipsec > crp eth2:172.31.201.0/24 ipsec > crp eth3:172.31.201.0/24 ipsecAfter Your change from 4.1.4 I can use variable defined as list of interfaces, but only in masq or nat files. Not in hosts. I have only two ipsec delegations, so it is not a problem. But if anybody builds IPsec tunnels mainly, this can be seen as incostistency. So maybe You should consider expand syntax with list od interfaces to hosts file too? Thanks for Your great job. Best regards Andrzej Odyniec Warsaw, Poland ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p
Andrzej Odyniec wrote:> All VPN I setup from OpenVPN tunnels. But last month I must set IPsec tunnels. > When I set up IPsec tunnels, I need to expand internal security zones to > tunneled adresses on external internet Interfaces. And in this place (hosts > file) I need to declare delegated addresses of my internal security zone for > all BGP interfaces separatelly, ie.: > >> crp eth2:172.23.0.0/18 ipsec >> crp eth3:172.23.0.0/18 ipsec >> crp eth2:172.31.201.0/24 ipsec >> crp eth3:172.31.201.0/24 ipsec > > After Your change from 4.1.4 I can use variable defined as list of interfaces, > but only in masq or nat files. Not in hosts.I would have written the above as: crp eth2:172.23.0.0/18,172.31.201.0/24 ipsec crp eth3:172.23.0.0/18,172.31.201.0/24 ipsec Which can be replaced with: BEGIN PERL for my $interface ( split /,/, $ENV{NET} ) { shorewall "crp $interface:172.23.0.0/18,172.31.201.0/24 ipsec" } END PERL Note that variables set in /etc/shorewall/params are passed to the Shorewall-perl compiler via the environment. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p
Tom Eastep wrote:> I would have written the above as: > > crp eth2:172.23.0.0/18,172.31.201.0/24 ipsec > crp eth3:172.23.0.0/18,172.31.201.0/24 ipsec > > Which can be replaced with: > > BEGIN PERL > > for my $interface ( split /,/, $ENV{NET} ) { > shorewall "crp $interface:172.23.0.0/18,172.31.201.0/24 ipsec" > } > > END PERL > > Note that variables set in /etc/shorewall/params are passed to the > Shorewall-perl compiler via the environment.Thanks, Tom. This is strong and universal solution. So actually in hosts file is absolutely no need for new syntax. Ockham''s Razor is always better. :) Best regards Andrzej Odyniec Warsaw, Poland ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p