From owner-freebsd-pf@FreeBSD.ORG Sun Nov 22 08:37:01 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C205106566B for ; Sun, 22 Nov 2009 08:37:01 +0000 (UTC) (envelope-from fullblaststorm@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 298E98FC12 for ; Sun, 22 Nov 2009 08:37:00 +0000 (UTC) Received: by fxm10 with SMTP id 10so2071019fxm.14 for ; Sun, 22 Nov 2009 00:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=wwalG64oTkrRg9yFH5nrEvhEf9n+VlC7rUXTA2ns+8U=; b=W5dlgiWisHw6pPVqiGoMCEbbKXNDGPc63OXQ4U/mpuFgfvOCS4hmgdiWOnBbYq5bOt qPt8/2PSp9nBTzSVUQizfRbc/ya8T7JioSpUybh64aPSXqfXOH2kRDc17xNS9SN0E0yb UUZ+cGpP/YUNfOL3Scg6qlFvYcmjjOyGUk3kk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Xxqi22qTuBPaJPS649+5nXzkChxeb4AUVjx6IAT+QkMx56v1bAiN4BaEk0bhcnhRGq y3wItbxJLXp8bx1nLhxnSt6JwitJaE6jB5LRCKr4H5lUeRskpoas9dSGAdGRFB/fo3Yn ew9o1l4g2fjre06BnLl0un+unQUnFUwSfgglo= MIME-Version: 1.0 Received: by 10.239.139.32 with SMTP id r32mr336031hbr.86.1258879019110; Sun, 22 Nov 2009 00:36:59 -0800 (PST) In-Reply-To: <20091122022346.GK2392@verio.net> References: <6c51dbb10911210706g3490e463x7fdf3809243e30d2@mail.gmail.com> <4B082302.3040704@gmx.de> <6c51dbb10911211007x4ea07528y7642460629788903@mail.gmail.com> <1de79840911211023n165ecbd0h1051aaada4acefb@mail.gmail.com> <20091122022346.GK2392@verio.net> Date: Sun, 22 Nov 2009 14:36:59 +0600 Message-ID: <6c51dbb10911220036x55bc9753m421f4641d5f9e871@mail.gmail.com> From: Victor Lyapunov To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: sending mail with attachments always fails (FreeBSD/pf) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 08:37:01 -0000 Thank you guys for your attention to my problem. This time i increased the tcpdump capture buffer to 128 bytes and i got thi= s: # tcpdump -s 128 -net -i pflog0 (I tried to send mail with an attachment(700kb) to gmail.com(REQUIRES SSL) using outlook, which again timeout- failed) rule 0/0(match): block in on em0: 192.168.0.1.2078 > 192.168.0.3.445: P 794764624:794764677(53) ack 146734048 win 65535 rule 0/0(match): block in on em0: 192.168.0.1.2078 > 192.168.0.3.445: P 0:53(53) ack 1 win 65535 rule 0/0(match): block in on em0: 192.168.0.1.2078 > 192.168.0.3.445: P 0:53(53) ack 1 win 65535 rule 0/0(match): block in on em0: 192.168.0.1.2078 > 192.168.0.3.445: P 0:53(53) ack 1 win 65535 rule 1/0(match): pass in on em0: 192.168.0.5.1025 > 192.168.0.3.53: 1016+ A? smtp.gmail.com. (32) rule 1/0(match): pass out on em0: 192.168.0.3.61974 > 208.67.222.222.53: 44197+% [1au] A? smtp.gmail.com. (43) rule 1/0(match): pass out on em0: 192.168.0.3.53758 > 208.67.222.222.53: 57704+% [1au][|domain] rule 1/0(match): pass in on em0: 192.168.0.5.2029 > 74.125.39.109.465: S 207714378:207714378(0) win 65535 rule 1/0(match): pass out on em0: 192.168.0.5.2029 > 74.125.39.109.465: S 207714378:207714378(0) win 65535 rule 1/0(match): pass out on em0: 192.168.0.3.55398 > 208.67.222.222.53: 26150+% [1au][|domain] rule 0/0(match): block in on em0: 192.168.0.1.2078 > 192.168.0.3.445: P 0:53(53) ack 1 win 65535 rule 1/0(match): pass in on em0: 192.168.0.1.2437 > 192.168.0.3.445: S 3245362396:3245362396(0) win 65535 rule 1/0(match): pass in on em0: 192.168.0.1.2442 > 192.168.0.3.445: S 3154965483:3154965483(0) win 65535 rule 1/0(match): pass in on em0: 192.168.0.1.2444 > 192.168.0.3.445: S 3857149154:3857149154(0) win 65535 rule 1/0(match): pass in on em0: 169.254.113.220.2447 > 192.168.0.3.139: S 4208647498:4208647498(0) win 65535 rule 1/0(match): pass in on em0: 192.168.0.1.2448 > 192.168.0.3.139: S 3459916613:3459916613(0) win 65535 rule 1/0(match): pass in on em0: 169.254.113.220.2449 > 192.168.0.3.139: S 2672892612:2672892612(0) win 65535 17 packets captured 17 packets received by filter 0 packets dropped by kernel After that i tried to send mail to a server that does not require ssl and i got this: rule 1/0(match): pass in on em0: 192.168.0.5.2035 > 94.100.177.1.25: S 237079791:237079791(0) win 65535 rule 1/0(match): pass out on em0: 192.168.0.5.2035 > 94.100.177.1.25: S 237079791:237079791(0) win 65535 2 packets captured 2 packets received by filter 0 packets dropped by kernel The sending process fails regardless of whether i use SSL or not. 192.168.0.1 -- Router 192.168.0.3 -- The FreeBSD box 192.168.0.5 -- Windows machine with default gateway set to 192.168.0.3 The ruleset is: block drop log on em0 all pass log on em0 all flags S/SA keep state I can't figure out what might be the cause of the problem... Is it possible that the router causes this? 2009/11/22 David DeSimone : > Michael Proto wrote: >> >> > rule 4/0(match): pass out on em0: (tos 0x0, ttl 127, id 19860, offset >> > 0, flags [DF], proto TCP (6), length 48) 192.168.0.5.1822 > >> > 209.85.129.111.465: =A0tcp 28 [bad hdr length 0 - too short, < 20] >> >> This looks to be your problem-- bad hdr length 0. > > This is caused when tcpdump has too small a snaplen; it is not seeing > enough of the packet from the pflog interface, so it reports incorrect > information at the end. > > Try adding "-s 128" to collect a larger packet and you should see the > full description from tcpdump. > > > That said, the original problem seems like it could easily be caused by > a PF state mismatch resulting from assymetric routing. =A0If packets come > in a different interface than they go out, or worse, if the return path > doesn't even go through the firewall, PF cannot see the reply traffic > allowing it to update its TCP window tracking. > > As a result, short TCP sessions, such as those that fit within the > default TCP window, can work okay, but longer sessions that go beyond > that window will stall out and fail. > > -- > David DeSimone =3D=3D Network Admin =3D=3D fox@verio.net > =A0"I don't like spinach, and I'm glad I don't, because if I > =A0 liked it I'd eat it, and I just hate it." -- Clarence Darrow > > > This email message is intended for the use of the person to whom it has b= een sent, and may contain information that is confidential or legally prote= cted. If you are not the intended recipient or have received this message i= n error, you are not authorized to copy, distribute, or otherwise use this = message or its attachments. Please notify the sender immediately by return = e-mail and permanently delete this message and any attachments. Verio, Inc.= makes no warranty that this email is error or virus free. =A0Thank you. > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >