Hello,

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?

Regards,

Kris.

----- 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?
>
> Jeff