Date: Sun, 22 Nov 2009 14:36:59 +0600 From: Victor Lyapunov <fullblaststorm@gmail.com> To: freebsd-pf@freebsd.org Subject: Re: sending mail with attachments always fails (FreeBSD/pf) Message-ID: <6c51dbb10911220036x55bc9753m421f4641d5f9e871@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mss 1460,nop,nop,sackOK> rule 1/0(match): pass out on em0: 192.168.0.5.2029 > 74.125.39.109.465: S 207714378:207714378(0) win 65535 <mss 1460,nop,nop,sackOK> 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 <mss 1460,nop,nop,sackOK> rule 1/0(match): pass in on em0: 192.168.0.1.2442 > 192.168.0.3.445: S 3154965483:3154965483(0) win 65535 <mss 1460,nop,nop,sackOK> rule 1/0(match): pass in on em0: 192.168.0.1.2444 > 192.168.0.3.445: S 3857149154:3857149154(0) win 65535 <mss 1460,nop,nop,sackOK> rule 1/0(match): pass in on em0: 169.254.113.220.2447 > 192.168.0.3.139: S 4208647498:4208647498(0) win 65535 <mss 1460,nop,nop,sackOK> rule 1/0(match): pass in on em0: 192.168.0.1.2448 > 192.168.0.3.139: S 3459916613:3459916613(0) win 65535 <mss 1460,nop,nop,sackOK> rule 1/0(match): pass in on em0: 169.254.113.220.2449 > 192.168.0.3.139: S 2672892612:2672892612(0) win 65535 <mss 1460,nop,nop,sackOK> 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 <mss 1460,nop,nop,sackOK> rule 1/0(match): pass out on em0: 192.168.0.5.2035 > 94.100.177.1.25: S 237079791:237079791(0) win 65535 <mss 1460,nop,nop,sackOK> 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 <fox@verio.net>: > Michael Proto <mike@jellydonut.org> 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6c51dbb10911220036x55bc9753m421f4641d5f9e871>