On Friday 11 November 2005 12:34, Fábio Rabelo wrote:> The 631 port is opened to internal network ( yes, this system is a > gateway/Firewall too ) but it is not enough, something is missing !Have you reviewed your logs to see what traffic your Shorewall-generated ruleset is blocking?> There are some change in Shorewall that can do that ? > Or some rule/action that can deal with it ?There were a large number of Shorewall changes between Shorewall 1.4 and Shorewall 2.2. You can review the issues involved in upgrades at http://www.shorewall.net/2.0/upgrade_issues.htm. Whenever you upgrade from one major release of Shorewall to another, it is essential that you review the release notes carefully and make the changes required to insure that your firewall continues to operate properly. -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
I have a system running for 3 years now, in the beginning was Debian Woody ( Kernel 2.4 and shorewall 1.2 ) then I upgrade to Debian Sarge ( Kernel 2.6 , Shrewall 2.x ) In this sistem I always have a cups server to allow use of an Epson Stylus Color 900 be used ass Postscript printer to my Home PC AND My home Macintosh . But recently the cups stoped to work, after more then a week os research I discovered that the cause was an update to Shorewall, I''m not shore hat version was running, but latest update is 2.2.3-12 . Then I changed to the version in Lorenzo Martignoni repository ( 2.2.4-1 ) no efect . If I start the system without Shorewall, cups works fine ... In time, I do not changed any rule, I just updated the version of Shorewall . Someone have had this problem ? The 631 port is opened to internal network ( yes, this system is a gateway/Firewall too ) but it is not enough, something is missing ! There are some change in Shorewall that can do that ? Or some rule/action that can deal with it ? Thanks in advance ... and thanks a lot to great quality of shorewall ... Fábio Rabelo ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
I have a system running for 3 years now, in the beginning was Debian Woody ( Kernel 2.4 and shorewall 1.2 ) then I upgrade to Debian Sarge ( Kernel 2.6 , shorewall 2.x ) In this sistem I always have a cups server to allow use of an Epson Stylus Color 900 be used ass Postscript printer to my Home PC AND My home Macintosh . But recently the cups stopped to work, after more then a week of research I discovered that the cause was an update to Shorewall, I''m not shore hat version was running, but latest update is 2.2.3-12 . Then I changed to the version in Lorenzo Martignoni repository ( 2.2.4-1 ) no effect . If I start the system without Shorewall, cups works fine ... In time, I do not changed any rule, I just updated the version of Shorewall . Someone have had this problem ? The 631 port is opened to internal network ( yes, this system is a gateway/Firewall too ) but it is not enough, something is missing ! There are some change in Shorewall that can do that ? Or some rule/action that can deal with it ? Thanks in advance ... and thanks a lot to great quality of shorewall ... Fábio Rabelo ____________________________________________________________________ ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> In this sistem I always have a cups server to allow use of an Epson > Stylus Color 900 be used ass Postscript printer to my Home PC AND My > home Macintosh . > But recently the cups stoped to work, after more then a week os research > I discovered that the cause was an update to Shorewall, I''m not shore > hat version was running, but latest update is 2.2.3-12 .So the print server runs Shorewall, right?> If I start the system without Shorewall, cups works fine ... > In time, I do not changed any rule, I just updated the version of > Shorewall . > Someone have had this problem ? > The 631 port is opened to internal network ( yes, this system is a > gateway/Firewall too ) but it is not enough, something is missing !Would be good to see which connections you are really allowing. There is more to CUPS than "port 631". Anyway, this is from my personal action.AllowCUPS, wich works perfectly for me. # Allow CUPS connections (client -> server) # TARGET SOURCE DEST PROTO DEST SOURCE # PORT PORT ACCEPT - - udp 631 # IPP browsing ACCEPT - - tcp 631 # IPP printing # ACCEPT - - tcp 515 # LPD # IPP protocol (RFC 2910, 2911) # 631/udp listen for (and send) "IPP Browsing" Informationen (cupsd) # 631/tcp listen for IPP print jobs and HTTP (cupsd) # LPD protocol (RFC 1179) # 515/tcp listen for LPD print jobs (cups-lpd, xinetd) If you''re going to use it, be sure to either make it an Action or set SOURCE and DEST properly. If you''re actually using LPD, you''d want to adjust this as well. Yes, the comments indeed are part of my Action file. :-) HTH Karsten -- Davision - Atelier fuer Gestaltung / Internet / Multimedia UNIX / Linux Netzwerke und Schulungen Telefon +49 6151 273859 Fax +49 6151 273862
K. Bräckelmann escreveu:>>In this sistem I always have a cups server to allow use of an Epson >>Stylus Color 900 be used ass Postscript printer to my Home PC AND My >>home Macintosh . >>But recently the cups stoped to work, after more then a week os research >>I discovered that the cause was an update to Shorewall, I''m not shore >>hat version was running, but latest update is 2.2.3-12 . >> >> > >So the print server runs Shorewall, right? > >Right>>If I start the system without Shorewall, cups works fine ... >>In time, I do not changed any rule, I just updated the version of >>Shorewall . >>Someone have had this problem ? >>The 631 port is opened to internal network ( yes, this system is a >>gateway/Firewall too ) but it is not enough, something is missing ! >> >> > >Would be good to see which connections you are really allowing. There is >more to CUPS than "port 631". Anyway, this is from my personal >action.AllowCUPS, wich works perfectly for me. > >But do not work for me ! Until I can see, the problem is not with station trying to speak with cups, but cups web interface not speaking with core cups, samba not speaking with core cups, netatalk not speaking with core cups end vice-versa ... look at this screen shot of cups web interface : http://hpp.ajato.com.br/fabior/device/nodevice.jpg above is with cups running, no output device is show, and now, anything changed in cups or shorewall conf files, but shorewall not running : http://hpp.ajato.com.br/fabior/device/Devices.jpg When shorewall is not running, windows workstations and macintosh workstation can "see" the printers, and send jobs to the printers, but when shorewall is running, both workstations cannot see the printers, and consequentlý cannot sento jobs to it ! This is my policyes file : #CLIENT SERVER POLICY LOG LEVEL loc net ACCEPT net all DROP info all all REJECT info #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE and this is my rules file : #RESULT CLIENT(S) SERVER(S) PROTO PORT(S) CLIENT PORT(S) ADDRESS ACCEPT loc $FW tcp ssh,ftp,25,53,110,389,548,631,636,5222,5269,10000 ACCEPT loc $FW udp ntp,37,53,88,548,631,5222,5269 ACCEPT loc $FW icmp 8 - - - - ACCEPT $FW loc tcp 80,631 ACCEPT $FW loc udp 631 ACCEPT net $FW tcp ssh,10000 ACCEPT net $FW icmp 8 - - - - ACCEPT $FW net icmp 8 - - - - ACCEPT $FW net udp ntp,53 ACCEPT $FW net tcp ftp,http,53,9120 AllowSMB loc $FW all AllowSMB $FW loc DNAT net loc:192.168.1.100 tcp 6346,6881 DNAT net loc:192.168.1.100 udp 6346,6881 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE It has worked for 3 years, stoped to works just 2 weeks ago ! any other idea ?? Fábio Rabelo ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> >Would be good to see which connections you are really allowing. There is > >more to CUPS than "port 631". Anyway, this is from my personal > >action.AllowCUPS, wich works perfectly for me. > > But do not work for me !Oh, it does -- it just doesn''t fix your issue. Did you note the comment at the beginning? It''s for client/server connections and you already got those in your loc2fw rules.> Until I can see, the problem is not with station trying to speak with > cups, but cups web interface not speaking with core cups, samba not > speaking with core cups, netatalk not speaking with core cups end > vice-versa ...Yes. That''s what I suspect too, after having a look at the screenshots. Your issue is *not* with the communication between your clients and the print server. Ever tried accessing the print server from the clients in a browser? I bet it works. http://192.168.1.102:631/ Sadly, you didn''t even notice anything like this in your OP.> look at this screen shot of cups web interface : > > http://hpp.ajato.com.br/fabior/device/nodevice.jpg > > above is with cups running, no output device is show, and now, anything > changed in cups or shorewall conf files, but shorewall not running : > > http://hpp.ajato.com.br/fabior/device/Devices.jpg > > When shorewall is not running, windows workstations and macintosh > workstation can "see" the printers, and send jobs to the printers, but > when shorewall is running, both workstations cannot see the printers, > and consequentlý cannot sento jobs to it ! > > This is my policyes file : > > #CLIENT SERVER POLICY LOG LEVEL > loc net ACCEPT > net all DROP info > all all REJECT info > #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE > > and this is my rules file : > > #RESULT CLIENT(S) SERVER(S) PROTO PORT(S) CLIENT PORT(S) > ADDRESS > ACCEPT loc $FW tcp ssh,ftp,25,53,110,389,548,631,636,5222,5269,10000 > ACCEPT loc $FW udp ntp,37,53,88,548,631,5222,5269 > ACCEPT loc $FW icmp 8 - - - - > ACCEPT $FW loc tcp 80,631 > ACCEPT $FW loc udp 631 > ACCEPT net $FW tcp ssh,10000^^^ ^^^ ^^^^^ btw, I wouldn''t do this...> ACCEPT net $FW icmp 8 - - - - > ACCEPT $FW net icmp 8 - - - - > ACCEPT $FW net udp ntp,53 > ACCEPT $FW net tcp ftp,http,53,9120 > AllowSMB loc $FW all > AllowSMB $FW loc > DNAT net loc:192.168.1.100 tcp 6346,6881 > DNAT net loc:192.168.1.100 udp 6346,6881 > #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE > > It has worked for 3 years, stoped to works just 2 weeks ago ! > > any other idea ??Maybe providing the info we request when asking for support will help. http://shorewall.net/ , click Support, see Getting Help Karsten (who finally gets a coffee now) -- Davision - Atelier fuer Gestaltung / Internet / Multimedia UNIX / Linux Netzwerke und Schulungen Telefon +49 6151 273859 Fax +49 6151 273862
K. Bräckelmann escreveu:> <>Until I can see, the problem is not with station trying to speak with > cups, but cups web interface not speaking with core cups, samba not > speaking with core cups, netatalk not speaking with core cups end > vice-versa ... > > > Yes. That''s what I suspect too, after having a look at the screenshots. > Your issue is *not* with the communication between your clients and the > print server. Ever tried accessing the print server from the clients in > a browser? I bet it works. > > http://192.168.1.102:631/ > > Sadly, you didn''t even notice anything like this in your OP. > > > > >> look at this screen shot of cups web interface : >> >> http://hpp.ajato.com.br/fabior/device/nodevice.jpg >> >> above is with cups running, no output device is show, and now, >> anything changed in cups or shorewall conf files, but shorewall not >> running : >> >> http://hpp.ajato.com.br/fabior/device/Devices.jpg >> >> When shorewall is not running, windows workstations and macintosh >> workstation can "see" the printers, and send jobs to the printers, >> but when shorewall is running, both workstations cannot see the >> printers, and consequentlý cannot sento jobs to it ! >> >> This is my policyes file : >> >> #CLIENT SERVER POLICY LOG LEVEL >> loc net ACCEPT >> net all DROP info >> all all REJECT info >> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE >> >> and this is my rules file : >> >> #RESULT CLIENT(S) SERVER(S) PROTO PORT(S) CLIENT >> PORT(S) ADDRESS >> ACCEPT loc $FW tcp >> ssh,ftp,25,53,110,389,548,631,636,5222,5269,10000 >> ACCEPT loc $FW udp ntp,37,53,88,548,631,5222,5269 >> ACCEPT loc $FW icmp 8 - - - - >> ACCEPT $FW loc tcp 80,631 >> ACCEPT $FW loc udp 631 >> ACCEPT net $FW tcp ssh,10000 >> > > ^^^ ^^^ ^^^^^ > btw, I wouldn''t do this... > > > >> ACCEPT net $FW icmp 8 - - - - >> ACCEPT $FW net icmp 8 - - - - >> ACCEPT $FW net udp ntp,53 >> ACCEPT $FW net tcp ftp,http,53,9120 >> AllowSMB loc $FW all >> AllowSMB $FW loc >> DNAT net loc:192.168.1.100 tcp 6346,6881 >> DNAT net loc:192.168.1.100 udp 6346,6881 >> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE >> >> It has worked for 3 years, stoped to works just 2 weeks ago ! >> >> any other idea ?? >> > > > Maybe providing the info we request when asking for support will help. > http://shorewall.net/ , click Support, see Getting Help > > Karsten (who finally gets a coffee now) > > >Now, the status.txt is attached, And today, I can look at another machine, with similar setup, but still working, the shorewall version running in that machine is 2.2.3, so this problems appears after this version . Sorry if I do not provide at start all info necessary, but I think something like this, a change in shorewall will be so obvius that the developers can get it at first . I take a look at the status.txt file, and can find nothing ... I home you can .... Tanks in advance ... and sorry for my bad english ... I live in Brasil, a third world country !!! Fábio Rabelo ps.: I know you whote Brasil with Z, but in Portuguese, Brasil is with S .. ;- )
On Monday 14 November 2005 07:17, Fábio Rabelo wrote:> > Now, the status.txt is attached, And today, I can look at another > machine, with similar setup, but still working, the shorewall version > running in that machine is 2.2.3, so this problems appears after this > version .And that is the *only* difference between the machines? (they are running the same distribution at the same version?).> Sorry if I do not provide at start all info necessary, but I think > something like this, a change in shorewall will be so obvius that the > developers can get it at first .2.2.3 and 2.4.5 are almost identical (the only real change in 2.4 was the addition of multiple ISP support which you aren''t using).> I take a look at the status.txt file, and can find nothing ... I home > you can ....Neither can I. There was no traffic blocked from fw->loc or loc->fw and even if there was, the ''shorewall status'' wouldn''t have been of much help because your LOGFILE setting in shorewall.conf is obviously wrong (last log message shown is in July!!!!). And you are logging so much ACCEPT information that the REJECTs and DROPs probably go unnoticed anyway. This isn''t brain surgery -- you need to watch the fw2loc and loc2fw chains and find out what traffic is getting rejected or dropped -- once you discover that, correcting it will be easy. I also see you are running some horrible bandwidth monitoring kludge that has you logging *every message in/out eth0* at level 7. That is really awful! -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 escreveu:>On Monday 14 November 2005 07:17, Fábio Rabelo wrote: > > > >>Now, the status.txt is attached, And today, I can look at another >>machine, with similar setup, but still working, the shorewall version >>running in that machine is 2.2.3, so this problems appears after this >>version . >> >> > >And that is the *only* difference between the machines? (they are running the same distribution at the same version?). > >Almost, the distribution is the same ( Debian Sarge, but the system in my home starts to show the problem just after a security update, them I do not reflect that update to all other systems that I am responsable, I don''t want to spread aou the problem !! ) And this other similar system do not use Samba, they have only MACs there . But I already tried to remove Samba from my system, no efect .>>Sorry if I do not provide at start all info necessary, but I think >>something like this, a change in shorewall will be so obvius that the >>developers can get it at first . >> >> > >2.2.3 and 2.4.5 are almost identical (the only real change in 2.4 was the >addition of multiple ISP support which you aren''t using). > > > >>I take a look at the status.txt file, and can find nothing ... I home >>you can .... >> >> > >Neither can I. There was no traffic blocked from fw->loc or loc->fw and even >if there was, the ''shorewall status'' wouldn''t have been of much help because >your LOGFILE setting in shorewall.conf is obviously wrong (last log message >shown is in July!!!!). > >And you are logging so much ACCEPT information that the REJECTs and DROPs >probably go unnoticed anyway. > >This isn''t brain surgery -- you need to watch the fw2loc and loc2fw chains and >find out what traffic is getting rejected or dropped -- once you discover >that, correcting it will be easy. > >I also see you are running some horrible bandwidth monitoring kludge that has >you logging *every message in/out eth0* at level 7. That is really awful! > >This bandwidth thing is what remainns from experiences, nothing to do wirh this cups/shorewall issues, I must remove it !! sorry ... But I''m pretty shure that the problem is internal to the system, like screensots shows, when shorewall is running, the cups web interface cannot "talk" with core cups ( the log from cups always shows cups recognizing all output devices, shorewall running or not ) all output devices do not shows up in the web interface, but when I do not run shorewall, everyone of the output devices are showed, the portion of cups who is responsable to "read" this devices in core cups and shows it in the web interface cannot do this when Shorewall is running, but ACN do this when Shorewall is not runnig . http://hpp.ajato.com.br/fabior/device/Devices.jpg http://hpp.ajato.com.br/fabior/device/nodevice.jpg The same rappens to Samba and Netatalk . Both need to "talk" with cups core to read printer info durrint initialization to shows up printers . It works fine if I do not run Shorewall, but if I run shorewall Samba and Netatalk cannot talk with cups, then any printer is showed up in workstations .. As experience, I try to statup Netatalk/Samba and cups before shorewall , and after the printers shows up in chooser/network neiborhood in the workstations, then startup Shorewall, the printers still showing, but any job send to it just desapears ... When I look at logs, the error msg is "broken pipe" in netatlk and Samba , so netatalk/Samba cannot send info to cups core ! But worksations still talking with netatalk/Samba, so it is not loc2fw or fw2loc issue ! Is something internal to the system ... At first I think it is a cups issue, after 2 weeks trying everything someone in another list sugests to disable iptables, when I startup the system without Shorewall evething works fine again . Like I said, this was working fine for more then 3 years now, and I do not changed anything in Shorewall or cups conf, just the version of Shorewall has chenged . Fábio Rabelo ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> Like I said, this was working fine for more then 3 years now, and I do > not changed anything in Shorewall or cups conf, just the version of > Shorewall has chenged .I don''t believe that -- As Karsten Bräckelmann has pointed out on IRC, your problem is most likely that you are restricting fw->fw traffic which wasn''t even possible until Shorewall 2.0.0 (May of 2004). So you *must* have changed the Shorewall configuration at least within the past 18 months. You have a rule as follows: AllowSMTP fw fw The fact that you are using an action also means that you changed the configuration since you installed Shorewall 2.2.0 since Actions were first introduced then. Do you have a rule like that in your home configuration? I''m doubtful... On Shorewall versions 2.0 - 2.4, the default intra-zone policy is ACCEPT but as soon as you add a z->z rule, then the policy for z->z is governed by the /etc/shorewall/policy file. Because people have found that confusing (which it is), I changed the behavior in Shorewall 3.0. In 3.0, adding intra-zone rules no longer causes the default ACCEPT policy to be overridden -- it can only be overridden by the presense of an explicit z->z policy in /etc/shorewall/policies. Regardless of which version of Shorewall you are running, the AllowSMTP rule is completely unnecessary. And while running 2.0 - 2.4, it causes other problems (as you have found out the hard way). Remove that rule and see of your problem -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 Monday 14 November 2005 09:49, Tom Eastep wrote:> > Regardless of which version of Shorewall you are running, the AllowSMTP > rule is completely unnecessary. And while running 2.0 - 2.4, it causes > other problems (as you have found out the hard way). Remove that rule and > see if your problem......doesn''t go away (Hit <send> too soon). -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 Monday 14 November 2005 09:49, Tom Eastep wrote:> > Like I said, this was working fine for more then 3 years now, and I do > > not changed anything in Shorewall or cups conf, just the version of > > Shorewall has chenged . > > I don''t believe that -- As Karsten Bräckelmann has pointed out on IRC, your > problem is most likely that you are restricting fw->fw traffic which wasn''t > even possible until Shorewall 2.0.0 (May of 2004). So you *must* have > changed the Shorewall configuration at least within the past 18 months. > > You have a rule as follows: > > AllowSMTP fw fw > > The fact that you are using an action also means that you changed the > configuration since you installed Shorewall 2.2.0 since Actions were first > introduced then.Correction -- Actions were introduced in 2.0.0. -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
[ Resend -- stupid blacklist, this post didn''t show up in over an hour ]> > Yes. That''s what I suspect too, after having a look at the screenshots. > > Your issue is *not* with the communication between your clients and the > > print server. Ever tried accessing the print server from the clients in > > a browser? I bet it works. > > > > http://192.168.1.102:631/ > > > > Sadly, you didn''t even notice anything like this in your OP.[...]> > Maybe providing the info we request when asking for support will help. > > http://shorewall.net/ , click Support, see Getting Help > > Now, the status.txt is attached, And today, I can look at another > machine, with similar setup, but still working, the shorewall version > running in that machine is 2.2.3, so this problems appears after this > version . > Sorry if I do not provide at start all info necessary, but I think > something like this, a change in shorewall will be so obvius that the > developers can get it at first . > I take a look at the status.txt file, and can find nothing ... I home > you can ....Chain fw2fw (1 references) pkts bytes target prot opt in out source destination 9 360 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 9 540 AllowSMTP all -- * * 0.0.0.0/0 0.0.0.0/0 9 540 all2all all -- * * 0.0.0.0/0 0.0.0.0/0 In all 2.x versions, intra-zone traffic is ACCEPTed by default, *unless* you mess with it. Any intra-zone rule causes the policy to *not* be ACCEPT. Explicitly accepting fw2fw packets (although it already is the default) causes the trouble here. Just get rid of the fw2fw rules, and your server happily can talk to himself again. ;) FWIW, this is what I was referring to previously. It didn''t seem to be an issue with any packets to/from the loc zone. That screenshot was suspicious. Anyway, you failed to mention this earlier. Although you copy-n-pasted some rules and policies, this particular "AllowSMTP fw fw" rule was not part of it. FWIW, Tom just told me, this changed since 3.0 -- intra-zone rules will still leave the ACCEPT policy unchanged, unless any other intra-zone policy is set. Karsten -- Davision - Atelier fuer Gestaltung / Internet / Multimedia UNIX / Linux Netzwerke und Schulungen Telefon +49 6151 273859 Fax +49 6151 273862
K. Bräckelmann escreveu:>Chain fw2fw (1 references) > pkts bytes target prot opt in out source destination > 9 360 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED > 9 540 AllowSMTP all -- * * 0.0.0.0/0 0.0.0.0/0 > 9 540 all2all all -- * * 0.0.0.0/0 0.0.0.0/0 > >In all 2.x versions, intra-zone traffic is ACCEPTed by default, *unless* >you mess with it. Any intra-zone rule causes the policy to *not* be >ACCEPT. > >Explicitly accepting fw2fw packets (although it already is the default) >causes the trouble here. Just get rid of the fw2fw rules, and your >server happily can talk to himself again. ;) > >FWIW, this is what I was referring to previously. It didn''t seem to be >an issue with any packets to/from the loc zone. That screenshot was >suspicious. > > >Anyway, you failed to mention this earlier. Although you copy-n-pasted >some rules and policies, this particular "AllowSMTP fw fw" rule was not >part of it. > > >FWIW, Tom just told me, this changed since 3.0 -- intra-zone rules will >still leave the ACCEPT policy unchanged, unless any other intra-zone >policy is set. > >Thats it, thanks .. my fault ... that rule must be fw2net, I put it 3 mounths ago, when I trying to enable smarthost fuctions in this system, and just forgot it there, this rule no longer is needed ... The version 3.x is not in the experimental yet, and in prodution systems I use just stable ( now Sarge ) , and you probably know that the guys from Debian is realy old fashion ( slowly ?!? ) whem moving new versions from Experimental to unstable and do testing !!! So, I thing that I will take some time to start to use 3.x in any system ... Fábio Rabelo ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache''s Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php