On 2010-01-12, Dirk Mast <condo...@gmail.com> wrote:
> Dirk Mast wrote:
>
>> Peter N. M. Hansteen wrote:
>
>>> the problem went away. tcpdump output of successful and failing
>>> connetions would be instructive, along with the actual error messages,
>>> if any.
>
> Request to wiki (see those long timestamps), hope this helps_
>
> Jan 12 23:22:06.181513 PPPoE
> code Session, version 1, type 1, id 0x0580, length 114
> IP: 195.50.140.178.53 > x.x.x.x.18336: 26867 2/0/1 CNAME
> rr.esams.wikimedia.org., A 91.198.174.2 (84)
> Jan 12 23:22:06.184287 PPPoE
> code Session, version 1, type 1, id 0x0580, length 62
> IP: x.x.x.x.51519 > 91.198.174.2.80: S 126511392:126511392(0) win
> 5840 <mss 1460,sackOK,timestamp 6393340 0,nop,wscale 7> (DF)
^^^^^^^^
Your 'match in all scrub (no-df max-mss 1440)' is not affecting
the mss on these packets, take a close look at your ruleset to try
and work out why, though it might be as simple as removing 'in'..
> Peter N. M. Hansteen wrote:
>> lscarne...@veltrac.com.br writes:
>>
>>> My script is very simple (as you will see below), but by some reason,
>>> my machines behind the firewall can't send large emails, or emails
>>> with attached files.
>>
>> You don't offer any details of the other parts of the mail handling
>> setup, but my first suspect would be content filtering of some kind
>> kicks in noticeably only when there's attachments to be dechiphered.
If it's happening when sending everywhere, MTU/MSS problems are
more likely.
>> My other suspect is that
>>
>>> match in all scrub (no-df)
>>
>> somehow tickles the receiving end the wrong way. Others have reported
>> to me privately that going from 4.4 and
>>
>> scrub in all
>>
>> to 4.6 and
>>
>> match in all scrub (reassemble tcp)
>>
>> worked OK on most traffic, but slowed down some https traffic
>> horribly. Then some apparently random experimentation lead to trying
>> different max-mss values and with
>>
>> match in all scrub (no-df max-mss 1440)
>>
>> the problem went away. tcpdump output of successful and failing
>> connetions would be instructive, along with the actual error messages,
>> if any.
The sense of 'no-df' was inverted in 4.6, fixed in -current.
----------------------------
revision 1.120
date: 2009/09/01 15:51:06; author: jsing; state: Exp; lines: +1 -1
Clear the IP_DF bit if no-df is enabled, not if it is not enabled.
Issue reported by Matthew Dempsky. Same fix suggested by fg...@.
