Ping Size Windows GPO

[Mat Murdock]

I was wondering if there was a way to increase the allowed ping size
over a m0n0 to m0n0 ipsec vpn. The reason is as follows:

When running a M$ based network with a central location and numerous
satellite locations, you may encounter a rather nasty problem.
Windows 2000's method for locating a domain controller is not
exactly flawless. When a workstation checks connectivity with the DC
it first uses a normal icmp ping. If the normal ping succeeds it
then tests the connection speed with an oversized ping.
Specifically the size is 2048k* which puts the total packet size
over 2k due to headers. This isn't a problem when you are on a
local network with nothing between you and the DC but a switch.
However, if you are at a satellite location and you must traverse a
VPN to speak to the DC there may be trouble. This functionality is
designed to prevent ye-old ping flood among other things. Because
of this behavior workstations at satellite sites succeed with the
first normal ping but fail on the oversized one.

Any help would be appreciated.

Thanks,

Mat Murdock

[edward mzj]

try to allow fragmented icmp echo-request and echo reply packets. i'm not sure

Post by Mat Murdock
I was wondering if there was a way to increase the allowed ping size
When running a M$ based network with a central location and numerous
satellite locations, you may encounter a rather nasty problem.
Windows 2000's method for locating a domain controller is not
exactly flawless. When a workstation checks connectivity with the DC
it first uses a normal icmp ping. If the normal ping succeeds it
then tests the connection speed with an oversized ping.
Specifically the size is 2048k* which puts the total packet size
over 2k due to headers. This isn't a problem when you are on a
local network with nothing between you and the DC but a switch.
However, if you are at a satellite location and you must traverse a
VPN to speak to the DC there may be trouble. This functionality is
designed to prevent ye-old ping flood among other things. Because
of this behavior workstations at satellite sites succeed with the
first normal ping but fail on the oversized one.
Any help would be appreciated.
Thanks,
Mat Murdock

[George Bourozikas]

Post by edward mzj
try to allow fragmented icmp echo-request and echo reply packets. i'm not sure

Post by Mat Murdock
I was wondering if there was a way to increase the allowed ping size
When running a M$ based network with a central location and numerous
satellite locations, you may encounter a rather nasty problem.

No this does not work. The only way I have found to get IPsec VPN's to work
with m0n0 is by decreasing the MTU until there are no fragmented packets, at
least in the next hop (in my case ADSL).

--george

[Mat Murdock]

Post by George Bourozikas

Post by edward mzj
try to allow fragmented icmp echo-request and echo reply packets. i'm not sure

Post by Mat Murdock
I was wondering if there was a way to increase the allowed ping size
When running a M$ based network with a central location and numerous
satellite locations, you may encounter a rather nasty problem.

No this does not work. The only way I have found to get IPsec VPN's to work
with m0n0 is by decreasing the MTU until there are no fragmented packets, at
least in the next hop (in my case ADSL).
--george
---------------------------------------------------------------------

I think this is a IPsec setting that allows large ping packets.

Mat

[George Bourozikas]

Post by Mat Murdock

Post by George Bourozikas

Post by edward mzj
try to allow fragmented icmp echo-request and echo reply packets. i'm not sure

Post by Mat Murdock
I was wondering if there was a way to increase the allowed ping size
When running a M$ based network with a central location and numerous
satellite locations, you may encounter a rather nasty problem.

No this does not work. The only way I have found to get IPsec VPN's to
work with m0n0 is by decreasing the MTU until there are no fragmented
packets, at least in the next hop (in my case ADSL).
--george

I think this is a IPsec setting that allows large ping packets.
Mat

It is, but it did not work for me with v1.11, 1.12b3 and 1.2b7. After
numerous attempts to get info from the list I had an off-list discussion with

Post by Mat Murdock
Are you on DSL?
------------------------------------------------------------
Jason J Ellingson
I think that is the problem. All mine are on Cable or DS-1/3.
My guess is that the 1492 MTU used for DSL PPPoE on the WAN configuration
page isn't being observed by packets entering the IPSec tunnel.
------------------------------------------------------------
Jason J Ellingson

Unfortunately I was unable to set the MTU successfully on the m0n0 boxes (I
guess packets enter the tunnel before the hit the interface) so I had to clip
he MTU's on each server and client on both ends. This degrades LAN
performance slightly but it does improve Internet and IPsec performance - in
the latter case it's a division by zero :-)

Let us know something like this works for you.

Good luck,
--george

[edward mzj]

but how could you "decrease" the mtu size to "2048+"???
even on classic ethernet, these large packets will be splitted
into small pieces, unless you are using gigabit ethernet and
have enabled jumbo frames

Post by George Bourozikas
No this does not work. The only way I have found to get IPsec VPN's to work
with m0n0 is by decreasing the MTU until there are no fragmented packets, at
least in the next hop (in my case ADSL).
--george
---------------------------------------------------------------------

[Tommaso Di Donato]

Post by Mat Murdock
This isn't a problem when you are on a
local network with nothing between you and the DC but a switch.
However, if you are at a satellite location and you must traverse a
VPN to speak to the DC there may be trouble. This functionality is
designed to prevent ye-old ping flood among other things. Because
of this behavior workstations at satellite sites succeed with the
first normal ping but fail on the oversized one.

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....
Sorry if it is a stupid thought
Tom

[Chris Buechler]

Post by Tommaso Di Donato
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.

http://lists.virus.org/ntbugtraq-0310/msg00008.html

-Chris

[Mat Murdock]

Post by Chris Buechler

Post by Tommaso Di Donato
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.
http://lists.virus.org/ntbugtraq-0310/msg00008.html
-Chris
---------------------------------------------------------------------

It's a awful solution to fix the problem because you have to edit the
registry for the local machine but also the current user registry. So
if you have more then one user on a machine you have to edit part of the
registry for each user.

Mat