Hello,
I get nothing inside ipfilter logs.
Here is the ipf.conf file (public ip has been coded into {public-ip}) :
pass out quick on lo0 all
#Everything is safe on loopback and local network
pass in quick on lo0 all
pass out quick on bge0 all
pass in quick on bge0 all
#No private or strange packets from the inside to the outside
block out quick on nge0 from any to 192.168.0.0/16
block out quick on nge0 from any to 172.16.0.0/12
block out quick on nge0 from any to 127.0.0.0/8
block out quick on nge0 from any to 10.0.0.0/8
block out quick on nge0 from any to 0.0.0.0/8
block out quick on nge0 from any to 169.254.0.0/16
block out quick on nge0 from any to 192.0.2.0/24
block out quick on nge0 from any to 204.152.64.0/23
block out quick on nge0 from any to 224.0.0.0/3
#Pass anything from this public machine to the Internet
#and keep state for reply packets to be accepted
pass out quick on nge0 from {public-ip}/32 to any keep state
#Pass NAT pc-x
pass out quick on nge0 from 192.168.0.x/32 to any keep state
#Block anything else going out
block out log quick on nge0 from any to any
#Block any spoofing or strange packet coming from the Internet
block in quick on nge0 from 192.168.0.0/16 to any
block in quick on nge0 from 172.16.0.0/12 to any
block in quick on nge0 from 10.0.0.0/8 to any
block in quick on nge0 from 127.0.0.0/8 to any
block in quick on nge0 from 0.0.0.0/8 to any
block in quick on nge0 from 169.254.0.0/16 to any
block in quick on nge0 from 192.0.2.0/24 to any
block in quick on nge0 from 204.152.64.0/23 to any
block in quick on nge0 from 224.0.0.0/3 to any
block in log quick on nge0 from 192.165.21.0/24 to any
block in log quick on nge0 from any to 192.165.21.0/32
block in log quick on nge0 from any to 192.165.21.255/32
#Permit normal ICMP (ping, traceroute) but not spoofed ICMP
pass in quick on nge0 proto icmp from any to {public-ip}/32 icmp-type 0
pass in quick on nge0 proto icmp from any to {public-ip}/32 icmp-type 11
block in log quick on nge0 proto icmp from any to any
#Permit specific services from the outside
pass in quick on nge0 proto tcp from any to {public-ip}/32 port = 80 keep state
pass in quick on nge0 proto tcp from any to {public-ip}/32 port = 25 keep state
pass in quick on nge0 proto tcp from any to {public-ip}/32 port = 110 keep state
pass in quick on nge0 proto tcp from any to {public-ip}/32 port = 143 keep state
pass in quick on nge0 proto tcp from any to {public-ip}/32 port = 22 keep state
#Block anything else from the outside
block in log quick on nge0 from any to any
pass in all
In any case, be it kernel code or not, I still believe there must be some sort
of difference in the way ipfilter is distributed in latest Solaris 10 and what
comes out of the manual build from sources, when everything works fine using
the same configuration.
And again about black-list stuff, I understand what you say, but that should be
true even when ipfilter is disabled (content inspection should be still there
indipendently of my firewall state), while mails go out quickly when the
firewall is down.
Thanx again for all the support.
Gabriele.
Gabriele Bulfon - Sonicle S.r.l.
Tel +39 028246016 Int. 30 - Fax +39 028243880
Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY
http://www.sonicle.com
----------------------------------------------------------------------------------
Da: Jefferson Ogata <[EMAIL PROTECTED]>
A: Ipfilter <[email protected]>
Data: 23 gennaio 2008 21.04.02 CET
Oggetto: Re: Postfix timeouts
On 2008-01-23 19:55, Ken Jones wrote:
> I had the issue with sendmail under solaris 10. EMail that relayed thru
> prodigy.net (MX) had the symptom of geting thru the data phase then timing
> out. By disabling ipfilter, the email delivers without issue.
>
> I upgraded to the latest ipfilter / pfil and the issue went away, using
> exactly the same config.
Understood. But Postfix is not kernel code. There's nothing it is doing
that some other program might not do as well, which is why I encourage
Gabriele to look at what's really going on on the network and try to
identify the real problem. If we can get details on the packets and
logging maybe we can determine this.
--
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service
