Hi Everyone, I have an unusual problem with a Mandrivalinux 10.2/X86_64 installation, no the setup of shorewall where the DNAT rules die after a period of time. It does work after the machine is rebooted but the DNAT rules die after something like 6 hrs.. The rest of the firewall setting keep working.. Now even doing a "shorewall restart" does not seem to fix the problem .. rebooting the machine will fix the problem for about 6hrs The DNAT rule that I am referring to is something like DNAT net loc:192.168.0.1:25 tcp 26 The server has a External IP obtained from pppoe and the 192.168.0.1 comes from local ethernet card. basically I want a Exim mail server to listen to 2 ports 25 and 26, this is due to machines that need to send email and being with ISPs blocking out bound port 25, that need to connect to the mail server on port 26 Now with this problem I doubt that the resides with shorewall itself, I consider maybe the problem has something to do with iptables or how the kernel has been compiled.. at this moment I am using a stock kernel that comes with the 64bit Mandriva Linux. On consideration I have this setup as a working setup with the 32bit Linux not a problem.. no issues.. just wondering if anyone on this mailing list know of a fix for this, or even heard of this problem. Cheers Mark ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Mark Williamson wrote:> > On consideration I have this setup as a working setup with the 32bit > Linux not a problem.. no issues.. just wondering if anyone on this > mailing list know of a fix for this, or even heard of this problem. >Sorry -- I''ve not heard of the problem. When the problem occurs, are there any unusual messages (such as "conntrack table full") in your logs? -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, Mark, I have had the same experience but I have assumed that it may have been resolved in a more recent version of Shorewall, I run 1.4.8. In my case I discovered that DNAT would only work after I have tried proxyarp and then reconfigure for DNAT. Even then it would not survive a reboot. I don''t recall seeing in the documentation that there is a dependency but I have found that the DNAT would work and survive reboots if proxyarp is setup as well. I have checked the firewall for any obvious vulnerability from outside without finding. Tom, how bad a hack is this? -Ama -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Tom Eastep Sent: 26 August 2005 15:25 To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] DNAT dies after a period of time. Mark Williamson wrote:> > On consideration I have this setup as a working setup with the 32bit > Linux not a problem.. no issues.. just wondering if anyone on this > mailing list know of a fix for this, or even heard of this problem. >Sorry -- I''ve not heard of the problem. When the problem occurs, are there any unusual messages (such as "conntrack table full") in your logs? -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 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Ama Kalu wrote:> In my case I discovered that DNAT would only work after I have tried > proxyarp and then reconfigure for DNAT. Even then it would not survive a > reboot. > > I don''t recall seeing in the documentation that there is a dependency but I > have found that the DNAT would work and survive reboots if proxyarp is setup > as well. I have checked the firewall for any obvious vulnerability from > outside without finding.> > Tom, how bad a hack is this?It''s awful -- why don''t you just add the ORIGINAL DEST IP address to your external interface like the other 99.9999999% of us do? -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 on 26/08/2005 15:37:34:> Ama Kalu wrote: > > > In my case I discovered that DNAT would only work after I have tried > > proxyarp and then reconfigure for DNAT. Even then it would not survivea> > reboot. > > > > I don''t recall seeing in the documentation that there is a dependencybut I> > have found that the DNAT would work and survive reboots if proxyarp issetup> > as well. I have checked the firewall for any obvious vulnerabilityfrom> > outside without finding. > > > > > Tom, how bad a hack is this? > > It''s awful -- why don''t you just add the ORIGINAL DEST IP address to > your external interface like the other 99.9999999% of us do? >I guess I''m one of the 00.00000001% that uses ADD_DNAT_ALIASES=YES? works here with no problems... cheers, -- Eduardo Ferreira
They are added, these are the entries in my rules file; # DNAT net loc:172.16.172.51 tcp - - 165.165.215.163 DNAT net loc:172.16.172.53 tcp - - 165.165.215.164 These rules won''t work until I have made the following entry in my proxyarp file; # 165.165.215.163 eth1 eth0 No 165.165.215.164 eth1 eth0 No -Ama -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Tom Eastep Sent: 26 August 2005 19:38 To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] DNAT dies after a period of time. Ama Kalu wrote:> In my case I discovered that DNAT would only work after I have tried > proxyarp and then reconfigure for DNAT. Even then it would not survive a > reboot. > > I don''t recall seeing in the documentation that there is a dependency butI> have found that the DNAT would work and survive reboots if proxyarp issetup> as well. I have checked the firewall for any obvious vulnerability from > outside without finding.> > Tom, how bad a hack is this?It''s awful -- why don''t you just add the ORIGINAL DEST IP address to your external interface like the other 99.9999999% of us do? -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 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Eduardo Ferreira wrote:>> > I guess I''m one of the 00.00000001% that uses ADD_DNAT_ALIASES=YES? > works here with no problems...That''s amazing, given that there is no such option. -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
Ama Kalu wrote:> They are added, these are the entries in my rules file; > # > DNAT net loc:172.16.172.51 tcp - - 165.165.215.163 > DNAT net loc:172.16.172.53 tcp - - 165.165.215.164THEY ARE NOT ADDED!!! Where it the documentation do you think that you read that DNAT rules automatically add IP addresses. If you find such a place, please let us know so that we can fix the documentation.> > These rules won''t work until I have made the following entry in my proxyarp > file; > > # > 165.165.215.163 eth1 eth0 No > 165.165.215.164 eth1 eth0 No >Please read http://www.shorewall.net/Shorewall_and_Aliased_Interfaces.html. If you add 165.165.215.163 and .164 as addresses on eth1 then you won''t have to have that horrible hack. -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 on 26/08/2005 15:54:19:> Eduardo Ferreira wrote: > > >> > > I guess I''m one of the 00.00000001% that uses ADD_DNAT_ALIASES=YES? > > works here with no problems... > > That''s amazing, given that there is no such option. > > -Tomirkkkk, that''s what I deserve to write before thinking :(. Make it ADD_IP_ALIASES=YES. sorry all -- Eduardo Ferreira
Eduardo Ferreira wrote:> > Tom Eastep wrote on 26/08/2005 15:54:19: > >> Eduardo Ferreira wrote: >> >> >> >> > I guess I''m one of the 00.00000001% that uses ADD_DNAT_ALIASES=YES? >> > works here with no problems... >> >> That''s amazing, given that there is no such option. >> >> -Tom > irkkkk, that''s what I deserve to write before thinking :(. Make it > ADD_IP_ALIASES=YES. >:-) Just to be clear though, ADD_IP_ALIASES adds external addresses appearing in the ''nat'' file, not those appearing in the ORIGINAL DEST column of the ''rules'' file which would be what Ama would need. -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 on 26/08/2005 16:16:54:> Eduardo Ferreira wrote: > > > > Tom Eastep wrote on 26/08/2005 15:54:19: > > > >> Eduardo Ferreira wrote: > >> > >> >> > >> > I guess I''m one of the 00.00000001% that uses ADD_DNAT_ALIASES=YES? > >> > works here with no problems... > >> > >> That''s amazing, given that there is no such option. > >> > >> -Tom > > irkkkk, that''s what I deserve to write before thinking :(. Make it > > ADD_IP_ALIASES=YES. > > > :-) > > Just to be clear though, ADD_IP_ALIASES adds external addresses > appearing in the ''nat'' file, not those appearing in the ORIGINAL DEST > column of the ''rules'' file which would be what Ama would need. >Just a nano-second after hitting the ''send'' bottom I realized this. I''m really not in my best day here... Will keep silent till monday, when maybe I''ll got my mind back... sorry all, -- Eduardo Ferreira
Thanks Tom, I''m always grateful to learn from the master. BUT is there a way to determine whether it is the external interface that is servicing a ping request instead of the original destination IP address? I am concerned that the firewall will respond to requests made to its aliased interface even if the target of the DNAT, the internal machine is dead. -Ama -----Original Message----- From: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Tom Eastep Sent: 26 August 2005 20:02 To: shorewall-users@lists.sourceforge.net Subject: Re: [Shorewall-users] DNAT dies after a period of time. Ama Kalu wrote:> They are added, these are the entries in my rules file; > # > DNAT net loc:172.16.172.51 tcp - - 165.165.215.163 > DNAT net loc:172.16.172.53 tcp - - 165.165.215.164THEY ARE NOT ADDED!!! Where it the documentation do you think that you read that DNAT rules automatically add IP addresses. If you find such a place, please let us know so that we can fix the documentation.> > These rules won''t work until I have made the following entry in myproxyarp> file; > > # > 165.165.215.163 eth1 eth0 No > 165.165.215.164 eth1 eth0 No >Please read http://www.shorewall.net/Shorewall_and_Aliased_Interfaces.html. If you add 165.165.215.163 and .164 as addresses on eth1 then you won''t have to have that horrible hack. -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 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Ama Kalu wrote:> I am concerned that the firewall will respond to requests made to its > aliased interface even if the target of the DNAT, the internal machine is > dead.You shouldn''t be (concerned)... -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 Fri, 2005-08-26 at 07:24 -0700, Tom Eastep wrote:> Mark Williamson wrote: > > > > > On consideration I have this setup as a working setup with the 32bit > > Linux not a problem.. no issues.. just wondering if anyone on this > > mailing list know of a fix for this, or even heard of this problem. > > > > Sorry -- I''ve not heard of the problem. When the problem occurs, are > there any unusual messages (such as "conntrack table full") in your logs?The problem that I have been having is it''s been dieing silently, so I don''t really know when it dies exactly. I may setup something later though to detect when it happens. O.K. i rebooted the system last night and all is still sweet with it at this moment 14 hrs later.. Now I wonder if this problem will just disappear. Just grepping /var/log/messages for conntrack kernel: ip_conntrack version 2.1 (8192 buckets, 65536 max) - 336 bytes per conntrack O.K. I really don''t have a clue what the "buckets" are all about.. O.K. running "shorewall check" I know that the check function is not supported not supported.. but the only think that finds is "Connection Tracking Match: Not available", which I believe has nothing to do with DNAT Is there anything that I should look at? Cheers Mark ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Mark Williamson wrote:> > kernel: ip_conntrack version 2.1 (8192 buckets, 65536 max) - 336 bytes per conntrack > > O.K. I really don''t have a clue what the "buckets" are all about..It''s the size of the hash table used to access the conntrack table in your kernel.> > O.K. running "shorewall check" I know that the check function is not > supported not supported.. but the only think that finds is "Connection > Tracking Match: Not available", which I believe has nothing to do with > DNATThat''s correct.> > Is there anything that I should look at? >When it happens again: a) shorewall reset b) Try to connect through the DNAT rule. c) capture the output of "shorewall status" to a file. d) Use "gunzip" to compress the file. e) Forward the compressed file to the list. -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
The next time that it happens, I will follow this procedure, as I would like to get to the bottom of this.. About the only other thing I did the other day, I removed the package "msec" off the system.. msec = (Mandrake Security Management Program) A quick "rpm -e nodeps msec" took it out.. it must of been changing something in the back ground.. still time will tell if this was the problem. One good thing at this moment it''s still working.. Cheers Mark On Sat, 2005-08-27 at 07:54 -0700, Tom Eastep wrote:> Mark Williamson wrote: > > > > > kernel: ip_conntrack version 2.1 (8192 buckets, 65536 max) - 336 bytes per conntrack > > > > O.K. I really don''t have a clue what the "buckets" are all about.. > > It''s the size of the hash table used to access the conntrack table in > your kernel. > > > > > O.K. running "shorewall check" I know that the check function is not > > supported not supported.. but the only think that finds is "Connection > > Tracking Match: Not available", which I believe has nothing to do with > > DNAT > > That''s correct. > > > > > Is there anything that I should look at? > > > > When it happens again: > > a) shorewall reset > b) Try to connect through the DNAT rule. > c) capture the output of "shorewall status" to a file. > d) Use "gunzip" to compress the file. > e) Forward the compressed file to the list. > > -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------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Hi Everyone, Still have that DNAT dieing issue After a reboot the NDAT stuff actually stay alive for a couple of days.. When it died.. reboot.. it stayed alive for only about 1 hour "shorewall restart" On Sat, 2005-08-27 at 07:54 -0700, Tom Eastep wrote: <snip>> When it happens again: > > a) shorewall reset > b) Try to connect through the DNAT rule. > c) capture the output of "shorewall status" to a file. > d) Use "gunzip" to compress the file. > e) Forward the compressed file to the list. > > -TomFirst a "shorewall reset", then from a remote site I "telnet 58.58.58.58 26" then I captured the output of "shorewall status" This problem is quite odd.. BTW: I did change a number of the IPs in the status just to slightly guard privacy. Anyway as attached.
Mark Williamson escribió:> Hi Everyone, > > Still have that DNAT dieing issue > > After a reboot the NDAT stuff actually stay alive for a couple of days.. > When it died.. reboot.. it stayed alive for only about 1 hour > > "shorewall restart" > > On Sat, 2005-08-27 at 07:54 -0700, Tom Eastep wrote: > <snip>relevant kernel messages ?
On Tue, 2005-09-06 at 02:02 -0400, Cristian Rodriguez wrote:> Mark Williamson escribió: > > Hi Everyone, > > > > Still have that DNAT dieing issue > > > > After a reboot the NDAT stuff actually stay alive for a couple of days.. > > When it died.. reboot.. it stayed alive for only about 1 hour > > > > "shorewall restart" > > > > On Sat, 2005-08-27 at 07:54 -0700, Tom Eastep wrote: > > <snip> > > relevant kernel messages ? >No real kernel messages.. it''s just DNAT dieing .. the whole firewall keeps running .. The system stays running.. it''s just like that the iptables suddenly ignores a shorewall rule like DNAT net loc:192.168.0.100:25 tcp 26 Once the rule seems to get ignored all the system just seems to like it does not have that rule configured at all. I know that rule works as I have used that on other servers, without any issues. Cheers Mark ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Mark Williamson escribió:> On Tue, 2005-09-06 at 02:02 -0400, Cristian Rodriguez wrote: >>Mark Williamson escribió: >>>Hi Everyone, >>> >>>Still have that DNAT dieing issue >>> >>>After a reboot the NDAT stuff actually stay alive for a couple of days.. >>>When it died.. reboot.. it stayed alive for only about 1 hour >>> >>>"shorewall restart" >>> >>>On Sat, 2005-08-27 at 07:54 -0700, Tom Eastep wrote: >>><snip> >>relevant kernel messages ? >> > > No real kernel messages.. it''s just DNAT dieing .. the whole firewall > keeps running .. The system stays running.. it''s just like that the > iptables suddenly ignores a shorewall rule like > > DNAT net loc:192.168.0.100:25 tcp 26 > > Once the rule seems to get ignored all the system just seems to like it > does not have that rule configured at all. > > I know that rule works as I have used that on other servers, without any > issues.Tom : Any idea about this problem??? Im lost. :(
Cristian Rodriguez wrote:> > Tom : Any idea about this problem??? Im lost. :( >No -- unless the conntrack table is full (which seems unlikely -- it only has 346 entries in use). The packet count on the DNAT part of the rule in question is zero which indicates that the SYN packet on port 26 isn''t reaching that rule or if it is reaching the rule, it is not matching it!!?? Chain net_dnat (1 references) pkts bytes target prot opt in out source destination 0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:26 to:192.168.0.100:25 Clearly not a Shorewall problem, but other than that I don''t know what could cause this. I suppose that one could start inserting LOG rules into the mangle and nat table chains when the problem occurs to try to understand what packets (if any) that netfilter is seeing. That would require some iptables knowledge, however. Another approach might be to scan the netfilter mailing list(s) archives - I don''t recall a problem like this but I don''t follow the netfilter users list very closely (although I would have thought that a problem like this would have eventually reached the devel list). Mark: What kernel are you running? -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 Tue, 2005-09-06 at 07:10 -0700, Tom Eastep wrote:> Cristian Rodriguez wrote: > > > > > Tom : Any idea about this problem??? Im lost. :( > > > > No -- unless the conntrack table is full (which seems unlikely -- it > only has 346 entries in use). The packet count on the DNAT part of the > rule in question is zero which indicates that the SYN packet on port 26 > isn''t reaching that rule or if it is reaching the rule, it is not > matching it!!?? > > Chain net_dnat (1 references) > pkts bytes target prot opt in out source > destination > 0 0 DNAT tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 tcp dpt:26 to:192.168.0.100:25 > > Clearly not a Shorewall problem, but other than that I don''t know what > could cause this. I suppose that one could start inserting LOG rules > into the mangle and nat table chains when the problem occurs to try to > understand what packets (if any) that netfilter is seeing. That would > require some iptables knowledge, however. > > Another approach might be to scan the netfilter mailing list(s) archives > - I don''t recall a problem like this but I don''t follow the netfilter > users list very closely (although I would have thought that a problem > like this would have eventually reached the devel list). > > Mark: What kernel are you running?doing a "uname -pr" 2.6.11-6mdk AMD Athlon(tm) 64 Processor 3200+ It''s a Mandrake stock kernel for x86_64 -- It may be time to start playing around with Kernels In other systems Mandriva systems which are i586, not x86_64 based I have not seen this problem. same kernel version, similar setup etc.. I have pointed a news reader at gmane.comp.security.firewalls.netfilter.devel at this moment.. but I think it''s going to take me a while before I come close to a fix This problem is a obscure one, it''s even difficult to lodge a bug report anywhere.. but I will keep looking.. someone else will run into the same or similar problem. And I may end up with a fix with playing around the kernel as well. I will report back if I succeed. Cheers Mark ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Mark Williamson wrote:>> >> Another approach might be to scan the netfilter mailing list(s) archives >> - I don''t recall a problem like this but I don''t follow the netfilter >> users list very closely (although I would have thought that a problem >> like this would have eventually reached the devel list). >> >> Mark: What kernel are you running? > > doing a "uname -pr" > 2.6.11-6mdk AMD Athlon(tm) 64 Processor 3200+ > > It''s a Mandrake stock kernel for x86_64 -- It may be time to start > playing around with Kernels > > In other systems Mandriva systems which are i586, not x86_64 based I > have not seen this problem. same kernel version, similar setup etc.. > > I have pointed a news reader at > gmane.comp.security.firewalls.netfilter.devel at this moment.. but I > think it''s going to take me a while before I come close to a fix > > This problem is a obscure one, it''s even difficult to lodge a bug report > anywhere.. but I will keep looking.. someone else will run into the > same or similar problem. And I may end up with a fix with playing > around the kernel as well. I will report back if I succeed.I think it''s probably a AMD64-specific problem. I pay almost no attention to those problems on any networking list since the number of people wasting^H^H^H^H^H^H^H using those prosessors for firewall/gateway applications is very small. Aside -- I''ve been involved in 32bit->64bit OS transitions for the last several years. 64-bit addressing is typically SLOWER for applications that don''t involve very large amounts of in-memory data. -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