I would be surprised if MTU adjustments will fix things, given that you have
now established that large packets pass through OK.
I am not sure about your description of the AD setup. I sounds like you have
one domain but I am not sure about your sites configuration.
If you have sites connected together using slower links it is common to
create sites in AD, and then define a subnet to that site. Clients will then
use that information to locate the nearest DC/GC. Exchange will also use
that information to find a DC/GC. I wonder if perhaps the clients/exchange
aren't always locating the best DC to use?
Can I ask, where you found that RPC packets are 2048 bytes?
----- Original Message -----
From: "Jeff Buehler" <jeff at buehlertech dot com>
To: "Kristian Shaw" <monowall at wealdclose dot co dot uk>
Cc: <m0n0wall at lists dot m0n0 dot ch>
Sent: Monday, February 20, 2006 3:04 AM
Subject: Re: [m0n0wall] RE: RE : [m0n0wall] outlook -> exchange problem
> Hi Kris -
> I will try the different timeouts tonight. The MTU sounds like a stretch
> to me, since every ping test I have tun is clean at 1472 (mtu 1500) and I
> have seen no evidence of a fragmented packet, aside from the RPC which is
> a packet size of 2048. In addition, if it were actually necessary to make
> those changes on every client platform I add to the network and the server
> itself because of a very intermittent MTU fragmentation problem, that
> would imply to me that something serious is broken somewhere (and I
> strongly doubt it is on the T1 lines in question which have operated
> flawlessly for several years).
> By the way, does anyone know why RPC enforces a packet size of 2048 so
> that it is guaranteed to fragment across most WANs, by the way? Is this
> just the Microsoft RPC implementation that does this? It seems incredibly
> stupid to me to create a protocol that is going to fragment off the
> starting block across most LANs and almost any WAN.
> The AD configuration is very standard. There is actually one AD "site"
> that replicates across 3 DCs. So each LAN knows about the users in the
> other LAN as they all belong in the same "scope" (is that the correct MS
> terminology?). In sites and services there is a separate subnet for each
> LAN with the servers correctly specified. Keep in mind that each of these
> LANs operates flawlessly (except for this Outlook -> Exchange issue) - I
> have very few events of note in a given month which is unusual for any MS
> network I have seen. Replication is clean, file sharing across the VPN is
> clean, AD log in works fine, etc.
> I'll let you know if IPSEC lifetime changes make a difference, but it will
> be a bit hard to tell until next weekend when the bees are away and I can
> go back to the IPSEC VPN from the now working RPC over HTTPS for testing.
> How do I change the TCP/IP Idle timeout?