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