On 7/2/05, Tommaso Di Donato <tommaso dot didonato at gmail dot com> wrote:
> Are you sure that this is _not_ the right way to be?? Have you tried to use
> "Active directory Site and Link" and set up the properties of the other
> side? I never tried, nut I am quite sure that between different sites MS
> does not sent a so big ping....
AD sites are only for DC replication purposes, and to help users find
the closest DC. Since I presume there is no DC on the other end of
this connection, that won't help.
Path MTU Discovery (PMTUD) and passing fragmented packets are two
different things. Since racoon seems to not do PMTUD properly,
reducing the MTU fixes problems with packets that are oversized. ICMP
doesn't have the DF (don't frag) bit set by default, so even if PMTUD
did work properly, it wouldn't matter. In contrast, TCP and UDP
packets originating from a host with PMTUD enabled (basically
everything by default) will have the DF bit set and seem to just be
dropped if they're too big to traverse the VPN. Hence reducing MTU
works for TCP and UDP.
The ICMP is getting fragmented, so reducing the MTU might help because
the first frag might be 1500 bytes, and then too big to go across the
VPN once you add IPsec. But my XP box sends 2000 byte pings as a 1314
and 762 byte packets, both to the LAN (which respond), across a Cisco
client VPN connection (which respond), and to destinations across a
m0n0wall site to site VPN (which don't respond). So if your system is
doing the same, reducing the MTU will have no effect.
Basically fragmented packets don't make it for some reason, and it
doesn't appear to be firewall-rule related (nothing in the logs
getting dropped, it shows it passed, and I'm logging everything passed
or dropped, and permitting frags).
I'm going to chalk this up to a racoon limitation, unless somebody
knows better. The solution would be to disable slow link detection,
as described later in the thread the original poster quoted. Not a
great solution, but it'll work.