On Tue, 27 Jun 2006 09:56:46 +0200
Daniel Hartmeier <[EMAIL PROTECTED]> wrote:

> On Tue, Jun 27, 2006 at 09:17:18AM +0530, Ajith Kumar wrote:
> 
> > I had modified the entry like this
> > 
> > pass in quick log on fxp0 from any to  x.x.x.x  keep state flags S/
> > SA  #1 pass out quick log on fxp1 from   any to x.x.x.x keep state
> > flags S/ SA  #2
> > 
> > pass in  quick log on fxp1  from x.x.x.x  to  any keep state flags
> > S/SA #3 pass  out quick log on  fxp0 from  x.x.x.x  to any  keep
> > state flags S/SA #4
> > 
> > ( fxp0 is internal interface card. fxp1 is external interface card)
> > 
> > where x.x.x.x is ip address of mail server.Still I am not able to
> > send mail with big attachments.
> > I am able to send and receive other mails.
> 
> The test with disabling pf was a good one.
> 
> Next, enable pf but load an empty ruleset (pfctl -Fa, pfctl -e) and
> retry. Still working?
> 
> If so, load only the four rules you pasted above, retry. Still
> working?
> 
> If so, take a good look at your other rules. The difference between
> your real ruleset and the four rules quoted above must explain the
> breakage. Post the real ruleset if you can't spot it. If any other
> rule matches and creates state (for those TCP connections), make sure
> all states are created on the initial SYN only.
> 
> If connections break with an empty ruleset or just the four rules
> above, enable debug logging (pfctl -xm), reproduce the problem, then
> check /var/log/messages for entries from pf. Post them.
> 
> Run pfctl -si before and after reproducing the problem, what counters
> are increasing? Post both outputs.
> 
> Daniel

I just wanted throw this into the debugging mix as well, anywhere you
have a block statement add 'log' to the statement.  Then you can run
`tcpdump - n -e - vv -i pflog0` and it will list the rule number that
the packet matched in the ruleset.

Tim Donahue

Reply via email to