I''m trying to implement shorewall on my Centos 6 firewall. I''m by no means a firewall person and have an extremely limited knowledge of iptables and find it to be very confusing, and am hoping that Shorewall will help me get around that problem. With that said, here''s what I attempting to figure out. I have a web and email server running on a local host and when I implement shorewall I continue to get email and my web page is accessible from the internet. So far so good. My problem is with the firewall itself. I run a weather station connected to my firewall, and it sends updates to weather underground, and to CWOP, I also run ddclient on the same host. All 3 of these processes fail to connect to their respective hosts. As best I can determine ddclient and connections to the weather underground hosts both utilize port 80, and all cwop servers - - - cwop.aprs.net : port 14580 or port 23 - - - this links to all four CWOP servers. Here are the rules that I''ve tried. I tried specifying both protocols and ports as well but neither works. ACCEPT net:checkip.dyndns.org $FW all - ACCEPT net:weatherstation.wunderground.com $FW all - ACCEPT net:cwop.aprs.net $FW all - DNAT net loc:XXX.XXX.XXX.2 tcp http,https,imap,imaps,smtp This is what I see in the log wvcwopd[1789]: <1375804611302> : radSocketClientCreate: in progress connect failed: Connection refused wvcwopd[1789]: <1375804611304> : radSocketClientCreateAny: failed to connect to DNS result 85.188.1.27:23 wvcwopd[1789]: <1375804611304> : radSocketClientCreate: in progress connect failed: Connection refused wvcwopd[1789]: <1375804611306> : radSocketClientCreateAny: failed to connect to DNS result 129.15.41.39:23 wvcwopd[1789]: <1375804611306> : radSocketClientCreate: in progress connect failed: Connection refused wvcwopd[1789]: <1375804611308> : radSocketClientCreateAny: failed to connect to DNS result 129.15.41.40:23 wvcwopd[1789]: <1375804611308> : radSocketClientCreate: in progress connect failed: Connection refused wvcwopd[1789]: <1375804611309> : radSocketClientCreateAny: failed to connect to DNS result 193.1.208.229:23 wvcwopd[1789]: <1375804611310> : radSocketClientCreate: in progress connect failed: Connection refused wvcwopd[1789]: <1375804611312> : radSocketClientCreateAny: failed to connect to DNS result 70.57.237.99:23 wvcwopd[1789]: <1375804611312> : radSocketClientCreateAny: failed to connect to any server wvcwopd[1789]: <1375804611313> : CWOP-connect: failed to connect to all 3 APRS servers! wvhttpd[1792]: <1375804804520> : WUNDERGROUND-send: http://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?ID=XXXXXXXXXX&PASSWORD=XXXXXXXX&dateutc=2013-08-06+160x1.c88b4bfb41af8p-1013000x1.75245444e5557p+29304&winddir=020&windspeedmph=002&windgustmph=001&hum wvhttpd[1792]: <1375804804520> : WUNDERGROUND-send: dity=76&tempf=078.7&rainin=0.00&dailyrainin=0.27&baromin=30.06&dewptf=70.400&weather=&clouds=&softwaretype=wview-5.20.2&action=updateraw wvhttpd[1792]: <1375804804684> : WUNDERGROUND-error: couldn''t connect to host WARNING: cannot connect to checkip.dyndns.org:80 socket: IO::Socket::INET: connect: Connection refused What rules do I need to add to allow the firewall to permit these connections to work? Thanks Pete -- Unencumbered by the thought process. -- Click and Clack the Tappet brothers ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It''s a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
Dear Pete: You need to use ports and either tcp or udp for definitions for the firewall. the best thing I did was look at the macros that come with Shorewall (ie macro.DNS) it usually is under /usr/share/shorewall/ for example: # # Shorewall version 4 - DNS Macro # # /usr/share/shorewall/macro.DNS # # This macro handles DNS traffic. # ############################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE RATE USER/ # PORT(S) PORT(S) LIMIT GROUP PARAM - - udp 53 PARAM - - tcp 53 You can see what is need to make the rules work. I think you need for cwop.aprs.net below: ACCEPT - - tcp 14580 If you wright your own macros you can put in lots of rules with one line in the firwall rule Hope this helps Eric P.S. the two dashes between ACCEPT and tcp are very important, with out them they will not work. I have done old Cisco firewalls and this is a lot easier. ----- Original Message ----- From: "Pete Geenhuizen" <pete@geenhuizen.net> To: shorewall-users@lists.sourceforge.net Sent: Tuesday, August 6, 2013 12:11:14 PM Subject: [Shorewall-users] configuration help I''m trying to implement shorewall on my Centos 6 firewall. I''m by no means a firewall person and have an extremely limited knowledge of iptables and find it to be very confusing, and am hoping that Shorewall will help me get around that problem. With that said, here''s what I attempting to figure out. I have a web and email server running on a local host and when I implement shorewall I continue to get email and my web page is accessible from the internet. So far so good. My problem is with the firewall itself. I run a weather station connected to my firewall, and it sends updates to weather underground, and to CWOP, I also run ddclient on the same host. All 3 of these processes fail to connect to their respective hosts. As best I can determine ddclient and connections to the weather underground hosts both utilize port 80, and all cwop servers - - - cwop.aprs.net : port 14580 or port 23 - - - this links to all four CWOP servers. Here are the rules that I''ve tried. I tried specifying both protocols and ports as well but neither works. ACCEPT net:checkip.dyndns.org $FW all - ACCEPT net:weatherstation.wunderground.com $FW all - ACCEPT net:cwop.aprs.net $FW all - DNAT net loc:XXX.XXX.XXX.2 tcp http,https,imap,imaps,smtp This is what I see in the log wvcwopd[1789]: <1375804611302> : radSocketClientCreate: in progress connect failed: Connection refused wvcwopd[1789]: <1375804611304> : radSocketClientCreateAny: failed to connect to DNS result 85.188.1.27:23 wvcwopd[1789]: <1375804611304> : radSocketClientCreate: in progress connect failed: Connection refused wvcwopd[1789]: <1375804611306> : radSocketClientCreateAny: failed to connect to DNS result 129.15.41.39:23 wvcwopd[1789]: <1375804611306> : radSocketClientCreate: in progress connect failed: Connection refused wvcwopd[1789]: <1375804611308> : radSocketClientCreateAny: failed to connect to DNS result 129.15.41.40:23 wvcwopd[1789]: <1375804611308> : radSocketClientCreate: in progress connect failed: Connection refused wvcwopd[1789]: <1375804611309> : radSocketClientCreateAny: failed to connect to DNS result 193.1.208.229:23 wvcwopd[1789]: <1375804611310> : radSocketClientCreate: in progress connect failed: Connection refused wvcwopd[1789]: <1375804611312> : radSocketClientCreateAny: failed to connect to DNS result 70.57.237.99:23 wvcwopd[1789]: <1375804611312> : radSocketClientCreateAny: failed to connect to any server wvcwopd[1789]: <1375804611313> : CWOP-connect: failed to connect to all 3 APRS servers! wvhttpd[1792]: <1375804804520> : WUNDERGROUND-send: http://weatherstation.wunderground.com/weatherstation/updateweatherstation.php?ID=XXXXXXXXXX&PASSWORD=XXXXXXXX&dateutc=2013-08-06+160x1.c88b4bfb41af8p-1013000x1.75245444e5557p+29304&winddir=020&windspeedmph=002&windgustmph=001&hum wvhttpd[1792]: <1375804804520> : WUNDERGROUND-send: dity=76&tempf=078.7&rainin=0.00&dailyrainin=0.27&baromin=30.06&dewptf=70.400&weather=&clouds=&softwaretype=wview-5.20.2&action=updateraw wvhttpd[1792]: <1375804804684> : WUNDERGROUND-error: couldn''t connect to host WARNING: cannot connect to checkip.dyndns.org:80 socket: IO::Socket::INET: connect: Connection refused What rules do I need to add to allow the firewall to permit these connections to work? Thanks Pete -- Unencumbered by the thought process. -- Click and Clack the Tappet brothers ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It''s a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3392 / Virus Database: 3209/6554 - Release Date: 08/05/13 ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It''s a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
On 8/6/2013 10:11 AM, Pete Geenhuizen wrote:> I''m trying to implement shorewall on my Centos 6 firewall. I''m by no > means a firewall person and have an extremely limited knowledge of > iptables and find it to be very confusing, and am hoping that > Shorewall will help me get around that problem. > > With that said, here''s what I attempting to figure out. > > I have a web and email server running on a local host and when I > implement shorewall I continue to get email and my web page is > accessible from the internet. So far so good. > > My problem is with the firewall itself. I run a weather station > connected to my firewall, and it sends updates to weather underground, > and to CWOP, I also run ddclient on the same host. All 3 of these > processes fail to connect to their respective hosts.Why don''t you simply have an ACCEPT policy from $FW to net? In /etc/shorewall/policy: $FW net ACCEPT> > As best I can determine ddclient and connections to the weather > underground hosts both utilize port 80, and > all cwop servers - - - cwop.aprs.net : port 14580 or port 23 - - - > this links to all four CWOP servers. > > Here are the rules that I''ve tried. I tried specifying both > protocols and ports as well but neither works. > > ACCEPT net:checkip.dyndns.org $FW all - > ACCEPT net:weatherstation.wunderground.com $FW all - > ACCEPT net:cwop.aprs.net $FW all - > DNAT net loc:XXX.XXX.XXX.2 tcp http,https,imap,imaps,smtpPlacing DNS names in your configuration is a really bad idea. See: http://www.shorewall.net/configuration_file_basics.htm#dnsnames http://www.shorewall.net/FAQ.htm#idp3857840 -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It''s a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
On 08/06/2013 04:54 PM, Tom Eastep wrote:> On 8/6/2013 10:11 AM, Pete Geenhuizen wrote: > Why don''t you simply have an ACCEPT policy from $FW to net? In > /etc/shorewall/policy: > > $FW net ACCEPT >Thanks Tom for the suggestion, and please forgive my ignorance, but wouldn''t this open the firewall to anything? Anyway I gave it a shot, but unfortunately it didn''t make any difference, still no joy.> > Placing DNS names in your configuration is a really bad idea. See:I agree completely and that wasn''t what I wanted to do, which is one reason why I was asking for help. Perhaps I have something else in the rules file creating a problem, so here are the rules that I have SECTION NEW ACCEPT net $FW DNAT net loc:XXX.XXX.XXX.13 tcp 22 2222 DNAT net loc:XXX.XXX.XXX.2 tcp http,https,imap,imaps,smtp Invalid(DROP) net all DNS(ACCEPT) $FW net SSH(ACCEPT) loc $FW Ping(ACCEPT) loc $FW Ping(DROP) net $FW ACCEPT $FW loc icmp ACCEPT $FW net icmp -- Unencumbered by the thought process. -- Click and Clack the Tappet brothers ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It''s a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
Let''s see if I''m understanding you. So you have 3 zones right? [ net, loc, fw ] And you''re ''weather station'' machine connects to the firewall via loc interface? And you need the ''weather station'' to connect somewhere on the internet.. through the net interface? If I understood correctly, you can either add the following to /etc/shorewall/policy: loc net ACCEPT OR you can add individual rules for loc like: ACCEPT loc net tcp 23 ACCEPT loc net tcp 14580 NOTICE how the loc is going to the net, and not the fw.. On Tue, Aug 6, 2013 at 4:34 PM, Pete Geenhuizen <pete@geenhuizen.net> wrote:> > On 08/06/2013 04:54 PM, Tom Eastep wrote: > > On 8/6/2013 10:11 AM, Pete Geenhuizen wrote: > Why don''t you simply have an ACCEPT policy from $FW to net? In > /etc/shorewall/policy: > > $FW net ACCEPT > > Thanks Tom for the suggestion, and please forgive my ignorance, but > wouldn''t this open the firewall to anything? > Anyway I gave it a shot, but unfortunately it didn''t make any difference, > still no joy. > > > Placing DNS names in your configuration is a really bad idea. See: > > I agree completely and that wasn''t what I wanted to do, which is one > reason why I was asking for help. > > Perhaps I have something else in the rules file creating a problem, so > here are the rules that I have > SECTION NEW > > ACCEPT net $FW > DNAT net loc:XXX.XXX.XXX.13 tcp 22 2222 > > DNAT net loc:XXX.XXX.XXX.2 tcp http,https,imap,imaps,smtp > > Invalid(DROP) net all > DNS(ACCEPT) $FW net > SSH(ACCEPT) loc $FW > Ping(ACCEPT) loc $FW > > > Ping(DROP) net $FW > > ACCEPT $FW loc icmp > ACCEPT $FW net icmp > > > > -- > Unencumbered by the thought process. > -- Click and Clack the Tappet brothers > > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It''s a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It''s a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
also remove the line ACCEPT net $FW from your rules. On Tue, Aug 6, 2013 at 4:51 PM, johnny bowen <jbowen7@gmail.com> wrote:> Let''s see if I''m understanding you. So you have 3 zones right? [ net, loc, > fw ] > And you''re ''weather station'' machine connects to the firewall via loc > interface? > And you need the ''weather station'' to connect somewhere on the internet.. > through the net interface? > > If I understood correctly, you can either add the following to > /etc/shorewall/policy: > loc net ACCEPT > > OR > > you can add individual rules for loc like: > ACCEPT loc net tcp 23 > ACCEPT loc net tcp 14580 > > > > NOTICE how the loc is going to the net, and not the fw.. > > > > On Tue, Aug 6, 2013 at 4:34 PM, Pete Geenhuizen <pete@geenhuizen.net>wrote: > >> >> On 08/06/2013 04:54 PM, Tom Eastep wrote: >> >> On 8/6/2013 10:11 AM, Pete Geenhuizen wrote: >> Why don''t you simply have an ACCEPT policy from $FW to net? In >> /etc/shorewall/policy: >> >> $FW net ACCEPT >> >> Thanks Tom for the suggestion, and please forgive my ignorance, but >> wouldn''t this open the firewall to anything? >> Anyway I gave it a shot, but unfortunately it didn''t make any difference, >> still no joy. >> >> >> Placing DNS names in your configuration is a really bad idea. See: >> >> I agree completely and that wasn''t what I wanted to do, which is one >> reason why I was asking for help. >> >> Perhaps I have something else in the rules file creating a problem, so >> here are the rules that I have >> SECTION NEW >> >> ACCEPT net $FW >> DNAT net loc:XXX.XXX.XXX.13 tcp 22 2222 >> >> DNAT net loc:XXX.XXX.XXX.2 tcp http,https,imap,imaps,smtp >> >> Invalid(DROP) net all >> DNS(ACCEPT) $FW net >> SSH(ACCEPT) loc $FW >> Ping(ACCEPT) loc $FW >> >> >> Ping(DROP) net $FW >> >> ACCEPT $FW loc icmp >> ACCEPT $FW net icmp >> >> >> >> -- >> Unencumbered by the thought process. >> -- Click and Clack the Tappet brothers >> >> >> >> ------------------------------------------------------------------------------ >> Get 100% visibility into Java/.NET code with AppDynamics Lite! >> It''s a free troubleshooting tool designed for production. >> Get down to code-level detail for bottlenecks, with <2% overhead. >> Download for free and get started troubleshooting in minutes. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> >> >------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It''s a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
On 08/06/2013 04:54 PM, Tom Eastep wrote:> On 8/6/2013 10:11 AM, Pete Geenhuizen wrote: > Why don''t you simply have an ACCEPT policy from $FW to net? In > /etc/shorewall/policy: > > $FW net ACCEPT > > > Placing DNS names in your configuration is a really bad idea. See: > > http://www.shorewall.net/configuration_file_basics.htm#dnsnames > http://www.shorewall.net/FAQ.htm#idp3857840 > > -Tom >Well after several miss steps and errors I finally managed to properly implement your simple suggestion which solved the problem. Thanks -- Unencumbered by the thought process. -- Click and Clack the Tappet brothers ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It''s a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
Great glad you got it all sorted out. Once you use Shorewall a few times you''ll really get a hang of it, and it''ll become a very powerful tool for you. On Wed, Aug 7, 2013 at 6:12 AM, Pete Geenhuizen <pete@geenhuizen.net> wrote:> > On 08/06/2013 04:54 PM, Tom Eastep wrote: > > On 8/6/2013 10:11 AM, Pete Geenhuizen wrote: > Why don''t you simply have an ACCEPT policy from $FW to net? In > /etc/shorewall/policy: > > $FW net ACCEPT > > > Placing DNS names in your configuration is a really bad idea. See: > > http://www.shorewall.net/configuration_file_basics.htm#dnsnames > http://www.shorewall.net/FAQ.htm#idp3857840 > > -Tom > > Well after several miss steps and errors I finally managed to properly > implement your simple suggestion which solved the problem. > > Thanks > > > > -- > Unencumbered by the thought process. > -- Click and Clack the Tappet brothers > > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It''s a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It''s a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
Hi Pete, Just a few more comments on your configuration: On 08/07/2013 09:34 AM, Pete Geenhuizen wrote:> > On 08/06/2013 04:54 PM, Tom Eastep wrote: >> On 8/6/2013 10:11 AM, Pete Geenhuizen wrote: >> Why don''t you simply have an ACCEPT policy from $FW to net? In >> /etc/shorewall/policy: >> >> $FW net ACCEPT >> > Thanks Tom for the suggestion, and please forgive my ignorance, but > wouldn''t this open the firewall to anything?The above policy is for traffic FROM the firewall TO net. (The source zone is listed first.)> ... > Perhaps I have something else in the rules file creating a problem, so > here are the rules that I have > SECTION NEW > > ACCEPT net $FW > DNAT net loc:XXX.XXX.XXX.13 tcp 22 2222 > DNAT net loc:XXX.XXX.XXX.2 tcp http,https,imap,imaps,smtp > > Invalid(DROP) net allBe careful with this one - i would recommend putting it at the end of your rules if you bother keeping it. New connections are also invalid, which means that any other net to anything rules after it will be dropped.> ... > Ping(DROP) net $FWI personally find blocking ping causes more problems than it solves. It has been a long time since Linux has seen a ping-based vulnerability, and it''s an important troubleshooting tool. Regards, Paul ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It''s a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
One correction to Paul''s observations below On 8/9/2013 2:34 PM, Paul Gear wrote:> Hi Pete, > > Just a few more comments on your configuration: > > On 08/07/2013 09:34 AM, Pete Geenhuizen wrote: >>>> Invalid(DROP) net all > > Be careful with this one - i would recommend putting it at the end of > your rules if you bother keeping it. New connections are also invalid, > which means that any other net to anything rules after it will be dropped. >Not true. Shorewall historically treated NEW and INVALID the same, since both went through rules generated by the rules file. But NEW and INVALID are separate and disjoint states. The sample rules files have included the above rule for some time. Regards, -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 \________________________________________________ ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It''s a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
On 08/10/2013 07:51 AM, Tom Eastep wrote:> One correction to Paul''s observations below > > On 8/9/2013 2:34 PM, Paul Gear wrote: >> Hi Pete, >> >> Just a few more comments on your configuration: >> >> On 08/07/2013 09:34 AM, Pete Geenhuizen wrote: >>> > >>> Invalid(DROP) net all >> >> Be careful with this one - i would recommend putting it at the end of >> your rules if you bother keeping it. New connections are also invalid, >> which means that any other net to anything rules after it will be dropped. >> > > Not true. Shorewall historically treated NEW and INVALID the same, since > both went through rules generated by the rules file. But NEW and INVALID > are separate and disjoint states. > > The sample rules files have included the above rule for some time.Thanks Tom. I must have been playing with raw iptables rather than Shorewall when i was bitten by this recently. :-) Paul ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It''s a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk