Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Nov 2009 21:35:24 -0900
From:      Mel Flynn <mel.flynn+fbsd.questions@mailing.thruhere.net>
To:        Victor Lyapunov <fullblaststorm@gmail.com>
Cc:        RW <rwmaillists@googlemail.com>, FreeBSD Mailing List <freebsd-questions@freebsd.org>
Subject:   Re: sending mail with attachments always fail (FreeBSD/pf)
Message-ID:  <fed98083777691e5cbd1afee1c77a249@sbmail.office-on-the.net>
In-Reply-To: <6c51dbb10911210936m67b2127cif8074723049c7046@mail.gmail.com>
References:  <6c51dbb10911210659t2e7b87dcg66d71544312d4172@mail.gmail.com> <20091121152720.GA3878@current.Sisis.de> <20091121170341.2c1bf3cb@gumby.homeunix.com> <6c51dbb10911210936m67b2127cif8074723049c7046@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 21 Nov 2009 23:36:33 +0600, Victor Lyapunov
<fullblaststorm@gmail.com> wrote:
>> This kind of thing is often due to a mtu blackhole - when a larger
>> email causes a full size IP packet to be sent. I don't see why PF
>> should make a difference though, IFAIK it's supposed to let ICMP throu=
gh
>> when it's learned state on a tcp connection.
>=20
> Thanks for your answer.
> Don't know whether it is relevant to the particular issue, but i tried
> both rulesets first with `scrub in all fragment reassemble` and
> another one without it, but neither worked for me. I'm kinda upset by
> the fact that pf can't handle large emails.
>=20
> Any other ideas how to possibly fix it, please?

If on FreeBSD 7 or higher you can get rid of the keep state. It's implici=
t.
Secondly, please test if the problem disappears by removing the rules and
simply allowing outgoing traffic.
Your rules would be:
scrub in on $ext_if fragment reassemble
block in on $ext_if
pass out on $ext_if from $int_if:network to any

If that works, then your problem is likely that you're creating 2 states
for one connection causing confusion.
--=20
Mel




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fed98083777691e5cbd1afee1c77a249>