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 this: # 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: tcp 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. If 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 == Network Admin == fox@verio.net > "I don't like spinach, and I'm glad I don't, because if I > 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 been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in 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. Thank 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>