sending mail with attachments always fails (FreeBSD/pf)

Sun Nov 22 08:37:01 UTC 2009

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 at verio.net>:
> Michael Proto <mike at 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 at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
>