The problem was a bad user account, as in "Active Directory bug".  Once 
I replaced the account with a new "fresh" account, everything went 
smoothly.  Why I didn't try that in the first 15 minutes is still a 
matter of internal debate, but at least I know what (AD) and who (MS) to 
blame.

Thanks for all of your ideas and input!
Jeff

Bryan K. Brayton wrote:

>Well, you can throw a sniffer on there and compare working/nonworking
>for any significant differences in the frames/packets.
>
>Also, there is a tool called RPCping that is designed for testing
>exchange RPC connectivity.  I think it is on the Exchange CD, but if not
>just google for it.
>
>-Bryan
>
>
>-----Original Message-----
>From: Jeff Buehler [mailto:jeff at buehlertech dot com] 
>Sent: Thursday, February 02, 2006 5:40 PM
>To: Chris Buechler
>Cc: m0n0wall at lists dot m0n0 dot ch
>Subject: Re: [m0n0wall] outlook -> exchange problem
>
>Presently the workstations in question get DNS (and DHCP) from the 
>m0n0wall device (as do the other workstations that are working 
>properly), which passes the domain server on the network for DNS.  The 
>DNS resolves properly, and immediately, for the Exchange server across 
>the VPN, so this doesn't seem to be the issue.
>
>The most likely thing that seems to make any sense is some sort of MTU 
>issue, in which fragmented packets are getting dropped.  I enabled 
>"Allow fragmented packets" on the ESP rule for the ipsec vpn, and I also
>
>added it to the LAN interface just for local Active Directory resolution
>
>(which was working anyway so that may be unnecessary).  A ping -f -l 
>1472 to the Exchange Server across the VPN does not fragment, so the 
>default of 1500 should be OK.
>
>All versions are the most recent: Exchange 2003 latest SP, Outlook 2003 
>with any updates.
>
>The ONLY difference that I can pin down, which I am now exploring, is 
>the newer Intel pro card on the workstations that are having the 
>problem.  I am putting an older card (from a machine that works 
>properly) in one of the problem machines to see if that makes any 
>difference at all.
>
>Bizarre problem.  I have been working on it for 6  or so hours now.  Has
>
>anyone tried to bill Microsoft for this kind of problem?  I hate to bill
>
>the client...
>
>Thanks,
>Jeff
>
>
>
>Chris Buechler wrote:
>
>  
>
>>On 2/2/06, Jeff Buehler <jeff at buehlertech dot com> wrote:
>> 
>>
>>    
>>
>>>1. Network of 20 or so workstations connected like this:  workstation
>>>      
>>>
>->
>  
>
>>>switch -> m0n0wall -> internet.
>>>   
>>>
>>>      
>>>
>>What are these machines using as their DNS server?  Lack of proper DNS
>>resolution is the #1 cause of Outlook delays that I've run into at
>>least.  They'll need to be using a DNS server that knows how to
>>resolve your AD DNS info appropriately.
>>
>>-Chris
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>>
>>
>> 
>>
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>
>
>  
>