Hi,

Have you tried using a sniffer on the network? There are issues with
fragmented packets and monowall inside VPNs, which can create problems for
example accessing Active Directory from a remote location. I wouldn't be
surprised if you had this kind of problem too.

Kris Shaw has just release a monowall image that corrects that: have a look
at his message of yersterday "Version of m0n0wall that filters VPN
traffic/Allows fragments".

Also, look at my two messages from 06.02.06 "Fragmented packets, VPN  &
Windows 2000 domain problem".

Hope this helps. Feedback is welcome...

Philippe

-----Message d'origine-----
De : Jeff Buehler [mailto:jeff at buehlertech dot com] 
Envoyé : jeudi, 9. février 2006 08:47
À : m0n0wall at lists dot m0n0 dot ch
Objet : Re: [m0n0wall] outlook -> exchange problem

Hi all -

My previous email was incorrect about the cause of the Outlook -> Exchange
failure over the ipsec VPN.  The creation of a new account was just a red
herring that coincidentally worked.  It seems that the ESP Protocol during
the Key Exchange was causing the failures.  When I changed it to AH,
everything started to run as expected.  Has anyone seen this behavior?  I
don't need strong security - is AH adequate?

Thanks,
Jeff

Jeff Buehler wrote:

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

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