Hello Gabriele
have you ever tryed something like that?
pass in quick on nge0 proto tcp from any to {public-ip}/32 port = 25
keep state keep frags
Gabriele Bulfon schrieb:
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.
<http://www.sonicle.com>
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
--
Gruss
Pitsch
__________________________________________________________________________
Peter Bickel e-mail: [EMAIL PROTECTED]
IDV & Network Consulting Telefon: +41 1 853 24 16
Gumpenwiesenstrasse 38 Fax: +41 1 853 27 04
CH-8157 Dielsdorf Mobile: +41 79 666 15 50
__________________________________________________________________________
