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-great-firewall-of-china/
RE: Strange smtp problem..
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
