I''m re-reading the section on dns names in the shorewall docs: "I personally recommend strongly against using DNS names in Shorewall configuration files. If you use DNS names and you are called out of bed at 2:00AM because Shorewall won''t start as a result of DNS problems then don''t say that you were not forewarned." Having been stung by this a few times over the years, I''m wondering if anyone has come up with a solution to this problem. Perhaps a conditional include file which will perform the lookups, and just ignore the rule if the dns lookup fails? Just wondering if someone has a creative solution to the problem. Otherwise, I''ll probably just convert the names to IPs by hand, then list the names in a comment. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Shawn Wright, I.T. Manager Shawnigan Lake School http://www.sls.bc.ca swright@sls.bc.ca
On Wed, 2005-03-09 at 11:44 -0800, Shawn Wright wrote:> I''m re-reading the section on dns names in the shorewall docs: > > "I personally recommend strongly against using DNS names in > Shorewall configuration files. If you use DNS names and you > are called out of bed at 2:00AM because Shorewall won''t start > as a result of DNS problems then don''t say that you were not > forewarned." > > Having been stung by this a few times over the years, I''m > wondering if anyone has come up with a solution to this > problem. Perhaps a conditional include file which will perform > the lookups, and just ignore the rule if the dns lookup fails? > > Just wondering if someone has a creative solution to the > problem. Otherwise, I''ll probably just convert the names to IPs > by hand, then list the names in a comment.Just using the IPs should be the way to go. :) Although there is a simple way to actually use IPs, which do look like DNS names. Pretty similar at least... Have a look at the ''params'' file and see the documentation at http://shorewall.net/Documentation.htm#Variables I personally use this file for MAC addresses (it''s a pain to remember the the NIC associated with the MAC address ;-) a lot and logging (ULOG), but it will just as well serve for DNS names and IP addresses. HTH karsten -- Davision - Atelier fuer Gestaltung / Internet / Multimedia UNIX / Linux Netzwerke und Schulungen Telefon 06151/273859 Fax 06151/273862
Karsten wrote on 09/03/2005 18:00:59:> On Wed, 2005-03-09 at 11:44 -0800, Shawn Wright wrote: > > I''m re-reading the section on dns names in the shorewall docs: > > > > "I personally recommend strongly against using DNS names in > > Shorewall configuration files. If you use DNS names and you > > are called out of bed at 2:00AM because Shorewall won''t start > > as a result of DNS problems then don''t say that you were not > > forewarned." > > > > Just using the IPs should be the way to go. :) > >I may be totally wrong here but the fartest I am from the physical details of my network (arps, macs, ips etc), the more confortable I feel. I use dns names in every one of my 6 firewalls - and in a site with heavy DHCP use and a lot of different kinds of clients and connections, I think this is the only way to go. but YMMV. /And no, I have never been called out of bed at 2:00AM. If someone restarts shorewall for any reason at this time at my site, he''s not going to call me - he''s going to call a new job. cheers, ________________________ Eduardo Ferreira Icatu Holding S.A. Supervisor de TI (5521) 3804-8606
On 10 Mar 2005 at 10:27, Eduardo Ferreira wrote:> Karsten wrote on 09/03/2005 18:00:59: > > > On Wed, 2005-03-09 at 11:44 -0800, Shawn Wright wrote: > > > I''m re-reading the section on dns names in the shorewall docs: > > > > > > "I personally recommend strongly against using DNS names in > > > Shorewall configuration files. If you use DNS names and you > > > are called out of bed at 2:00AM because Shorewall won''t start > > > as a result of DNS problems then don''t say that you were not > > > forewarned." > > > > > > > Just using the IPs should be the way to go. :) > > > > > I may be totally wrong here but the fartest I am from the physical details > of my network (arps, macs, ips etc), the more confortable I feel. I use > dns names in every one of my 6 firewalls - and in a site with heavy DHCP > use and a lot of different kinds of clients and connections, I think this > is the only way to go. but YMMV.I guess it depends on your need for using DNS names. In our case, it is just to handle a few external sites that require bizarre port access that we do not normally permit. There is less than 20 of them, so doing lookups by hand is not a big deal, except if the host IP changes. That''s why I thought it would be nice to have an include file where rules would fail silently if DNS lookup failed, or some type of rule that would behave the same way in the main rules file. Obviously one wouldn''t want to use this too often, but where a DNS name is desirable, but the actual rule is not critical to firewall operation, then rule behaviour like this would work nicely I think.> /And no, I have never been called out of bed at 2:00AM. If someone > restarts shorewall for any reason at this time at my site, he''s not going > to call me - he''s going to call a new job.The only time it has occurred for us is after a power outage where something went wrong with backup power systems and forced a reboot of the firewall. In these cases, DNS lookup failures are very common. Fortunately, we are now on automatic generator, but even that can fail, as we found out last month during a 36 hour outage. But even one failure to restart shorewall due to DNS failure is one too many... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Shawn Wright, I.T. Manager Shawnigan Lake School http://www.sls.bc.ca swright@sls.bc.ca
Shawn Wright wrote:> > > I guess it depends on your need for using DNS names. In our case, it is > just to handle a few external sites that require bizarre port access that we > do not normally permit. There is less than 20 of them, so doing lookups by > hand is not a big deal, except if the host IP changes. That''s why I thought > it would be nice to have an include file where rules would fail silently if > DNS lookup failed, or some type of rule that would behave the same way > in the main rules file. Obviously one wouldn''t want to use this too often, > but where a DNS name is desirable, but the actual rule is not critical to > firewall operation, then rule behaviour like this would work nicely I think. >You can parse the output of ''dig'' or ''nslookup'' in your /etc/shorewall/params file and set your variables that way. If the lookup fails, you set some some of default address (the last one you looked up manually, for example). -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
Tom Eastep wrote:> > You can parse the output of ''dig'' or ''nslookup'' in your > /etc/shorewall/params file and set your variables that way. If the > lookup fails, you set some some of default address (the last one yous/b "... some sort of ..."> looked up manually, for example). >-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
Shawn wrote on 10/03/2005 13:55:28:> On 10 Mar 2005 at 10:27, Eduardo Ferreira wrote: > > The only time it has occurred for us is after a power outage where > something went wrong with backup power systems and forced a reboot of > the firewall. In these cases, DNS lookup failures are very common. > Fortunately, we are now on automatic generator, but even that can fail,as> we found out last month during a 36 hour outage. But even one failure to> restart shorewall due to DNS failure is one too many...my generators wouldn''t last 36 hours - But I could refuel them. hummmmmm. may be I have a problem... thanks for one more worst-situation-possible experience. In a case like this, the order in which I re-power on the servers and equipments (modems, routers, switches etc) will certainly make a difference. Back to procedure documentation... cheers, ________________________ Eduardo Ferreira Icatu Holding S.A. Supervisor de TI (5521) 3804-8606
On 10 Mar 2005 at 14:22, Eduardo Ferreira wrote:> Shawn wrote on 10/03/2005 13:55:28: > > > On 10 Mar 2005 at 10:27, Eduardo Ferreira wrote: > > > > The only time it has occurred for us is after a power outage where > > something went wrong with backup power systems and forced a reboot of > > the firewall. In these cases, DNS lookup failures are very common. > > Fortunately, we are now on automatic generator, but even that can fail, > as > > we found out last month during a 36 hour outage. But even one failure to > > > restart shorewall due to DNS failure is one too many... > my generators wouldn''t last 36 hours - But I could refuel them. hummmmmm. > may be I have a problem... > > thanks for one more worst-situation-possible experience. In a case like > this, the order in which I re-power on the servers and equipments (modems, > routers, switches etc) will certainly make a difference. Back to > procedure documentation...We seem to be a case study on worst-case situations here... The outage on Jan 1st of this year occurred in the midst of a 36" snowfall, and our main generator (250kW, powers whole building) failed to start after the second outage when one of the starting batteries exploded! (still not sure why that happened). We had to send someone 25 kms to pickup a new battery, and run a small 4kW generator just to heat up the block enough to get it started, since the block heater had been down for 2 hours. On the plus side, once it''s started we have enough fuel on site for several weeks of power... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Shawn Wright, I.T. Manager Shawnigan Lake School http://www.sls.bc.ca swright@sls.bc.ca
On 10 Mar 2005 at 9:08, Tom Eastep wrote:> Shawn Wright wrote: > > > > I guess it depends on your need for using DNS names. In our case, it is > > just to handle a few external sites that require bizarre port access that we > > do not normally permit. There is less than 20 of them, so doing lookups by > > hand is not a big deal, except if the host IP changes. That''s why I thought > > it would be nice to have an include file where rules would fail silently if > > DNS lookup failed, or some type of rule that would behave the same way > > in the main rules file. Obviously one wouldn''t want to use this too often, > > but where a DNS name is desirable, but the actual rule is not critical to > > firewall operation, then rule behaviour like this would work nicely I think. > > > > You can parse the output of ''dig'' or ''nslookup'' in your > /etc/shorewall/params file and set your variables that way. If the > lookup fails, you set some some of default address (the last one you > looked up manually, for example).This sounds like a good plan. I''ll probably use djb''s ''dnsip'' tool instead, as it gives nice clean output. I''ll see what I can come up with. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Shawn Wright, I.T. Manager Shawnigan Lake School http://www.sls.bc.ca swright@sls.bc.ca
Shawn Wright wrote:> > This sounds like a good plan. I''ll probably use djb''s ''dnsip'' tool instead, > as it gives nice clean output.Can''t get much cleaner than this: teastep@ursa:~/Shorewall/Shorewall2> dig +short mail.blarg.net 206.124.128.86 206.124.128.85 teastep@ursa:~/Shorewall/Shorewall2> -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
On 10 Mar 2005 at 10:18, Tom Eastep wrote:> Shawn Wright wrote: > > > > > This sounds like a good plan. I''ll probably use djb''s ''dnsip'' tool instead, > > as it gives nice clean output. > > Can''t get much cleaner than this: > > teastep@ursa:~/Shorewall/Shorewall2> dig +short mail.blarg.net > 206.124.128.86 > 206.124.128.85 > teastep@ursa:~/Shorewall/Shorewall2>Agreed, I hadn''t tried that switch. But I don''t have dig installed on the firewall... I''m running an instance of djbdns already, so the djb tools are handy. To save time, I''m going to just convert to IPs for now. I don''t have enough DNS names to justify the time getting a script written and debugged. I''ll let someone who needs it more than I do come up with a script.... ;-) Thanks for the tips though, I''m starting to use the params file for some of our VLANs and hosts. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Shawn Wright, I.T. Manager Shawnigan Lake School http://www.sls.bc.ca swright@sls.bc.ca
shawn> That''s why I thought it would be nice to have an include file ... tom>> You can parse the output of ''dig'' or ''nslookup'' ... Shawn: What both you (include file) and Tom (using `...` within the "params" file) are describing would seem to work after a ''shorewall'' "start" or "restart" But what will you do if the IP addresses change *in between* "restarts"? Run a ''cron'' job? Not trying to disagree here, but just understand a complete "solution"! -- Prof Kenneth H Jacker khj@cs.appstate.edu Computer Science Dept www.cs.appstate.edu/~khj Appalachian State Univ Boone, NC 28608 USA
Kenneth Jacker wrote:> > What both you (include file) and Tom (using `...` within the "params" > file) are describing would seem to work after a ''shorewall'' "start" or > "restart" But what will you do if the IP addresses change *in > between* "restarts"? Run a ''cron'' job?Or use a Proxy that supports destination access lists. -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
On 12 Mar 2005 at 13:23, Tom Eastep wrote:> Kenneth Jacker wrote: > > > > > What both you (include file) and Tom (using `...` within the "params" > > file) are describing would seem to work after a ''shorewall'' "start" or > > "restart" But what will you do if the IP addresses change *in > > between* "restarts"? Run a ''cron'' job? > > Or use a Proxy that supports destination access lists.In our case, most of our rules requiring DNS names are used for NAT, because the services in question won''t work through a proxy. (or at least not through squid). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Shawn Wright, I.T. Manager Shawnigan Lake School http://www.sls.bc.ca swright@sls.bc.ca