The "pass out quick on $WAN proto tcp all flags S/SA" that was just a editing bug.. I was changing it from modulate state to keep state but it didn't get saved right.. Probably to much coffee.. Or not enough..
I am going to try some more logging to see if I can find something. Thanks for the help. Mvh Daniel Rapp Incabus Systems AB Direkt: + 46 8 410 115 45 [EMAIL PROTECTED] > -----Original Message----- > From: Daniel Hartmeier [mailto:[EMAIL PROTECTED] > Sent: den 5 juli 2006 14:32 > To: Daniel Rapp > Cc: pf@benzedrine.cx > Subject: Re: Strange smtp problem.. > > On Tue, Jul 04, 2006 at 12:12:51PM +0200, Daniel Rapp wrote: > > > pass out quick on $WAN proto tcp all flags S/SA > > Why no 'keep state' here? You really only pass out SYNs, don't pass > SYN+ACK back in, and neither pass further (non-SYN) packets? Makes no > sense. > > > If i do a "tcpdump -e -n -ttt -vv -i pflog0" i get: > > " > > Jul 04 11:48:30.678318 rule 88/(match) [uid 0, pid 6857] pass in on > > sis3: bbb.bbb.bbb.bbb.2916 > aaa.aaa.aaa.aaa.25: [|tcp] > (DF) (ttl 120, id 41053, len 40, bad cksum 0! differs by d68) " > > Bad checksum on incoming packets ?, could that be the problem? > > Retry with added -s 1700 to the tcpdump command. The default > snaplen is too short, truncating packets ("[|tcp]"), > producing the checksum warnings. > > > An thoughts ? > > I see nothing wrong with that dump. If that winsock error is > reliable and means the server got a TCP RST, it almost > certainly was the external peer sending it. > > You'll have to get a tcpdump capture of one connection that > produces the error in the server, preferably on both > interfaces of the bridge. > Depending on traffic volume, it might be difficult to get, > but try tcpdump'ing all port 25 traffic into a file, then > wait until the next server error occurs, then filter the file > using the peer's random port number. > > To prove that it's pf at fault producing the RST, you'll have > to show that the server is receiving an RST, the RST was sent > out from the bridge's internal interface, and that is has not > arrived in on the bridge's external interface. > > Those peers don't happen to be all from China [1], by any chance? :) > > Daniel > > [1] > http://www.lightbluetouchpaper.org/2006/06/27/ignoring-the-gre > at-firewall-of-china/ >
smime.p7s
Description: S/MIME cryptographic signature
