--QKdGvSO+nmPlgiQ/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

What is presently the accepted/recommended way to avoid fragmentation
of ESP tunnel mode packets when the traffic being tunnelled is tcp?

I've just traced really lousy wireless performance after a recent
upgrade to this, because I protect my wireless by using ipsec.  I only
see the problem in on direction/case, which is why it took me a while
to even realise there was an issue.

The relevant portion of my setup is like this:

  {I}
     \
      [G]--[AP] /\/\/ [W]
     /
  [L]

Host L on a wired LAN (with other boxes)
Host W in wireless, via an AP
Host G an ipf/ipsec gateway/router
Host I on the general Internet cloud

I have IPsec tunnel mode between G-W for traffic both to/from the LAN with
L, and for traffic to/from the internet.  I use IPsec transport mode
for traffic between hosts on the wireless lan, including W and G.

All boxes (except some I's, alas :) are NetBSD-current, I recently
upgraded G from a few-months-old -current.

Now, when L or I sends W large packets, they get encapsulated by G and
then the ESP packets get fragmented, and TCP throughput is truly
abysmal.  When W sends large packets, they are not fragmented as far
as I have seen; certainly the throughput is as it was before G was
upgraded.

I'm not sure really what changed - the performance impact of
fragmentation, or the fragmentation itself, or both.  For the sake of
experiment, while a large file copy from L->W was running, I changed
the MTU of L'd ethernet interface from 1500 -> 1430 to avoid the
fragmentation at G, and suddenly the transfer speed shot up massively
- not just to where it used to be before G was upgraded, but even
higher (~500K/s where previously I'd get ~350K/s). I was getting
~15K/s with fragmentation.

Fiddling with net.inet.ipsec.dfbit on G seems to have no effect, not
that I really expected it to (since that would be for other gateways
with narrow MTU's between G and W).

I also have another setup where I effectively use gif tunnels
encapsulated in ESP transport mode. There are a number of reasons to
prefer that setup, and now I have another: I could set the MTU of
gif0, and I would expect that to be properly exposed to
PMTU-discovery.  But that is not this setup, and does have some other
restrictions, especially since gif no longer has multipoint.

So, for the straight ESP-tunnel setup, what is the "official"
configuration to avoid the fragmentation at all, by exposing the
narrower tunnel-MTU to TCP and PMTU-discovery?=20

(If there's a new performance problem with ESP fragmentation, that
also needs to be looked into).

Is the FAST_IPSEC code any different in this behaviour? I haven't yet
tried it.

--
Dan.
--QKdGvSO+nmPlgiQ/
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iD8DBQFAI1IFEAVxvV4N66cRAuzOAJ0VY/MngXJsLaO89yNqxBqgoLDkTQCeMS5h
fJF2Uuchudtx+It71aly0Rk=
=FuHI
-----END PGP SIGNATURE-----

--QKdGvSO+nmPlgiQ/--