[ previous ] [ next ] [ threads ]
 
 From:  Jeff Buehler <jeff at buehlertech dot com>
 To:  Philippe Lang <philippe dot lang at attiksystem dot ch>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] outlook -> exchange problem
 Date:  Thu, 09 Feb 2006 09:58:39 -0800
Hi Phillipe -

I run all FreeBSD myself, but this client is 100% MS.  So, I can provide 
a Network Monitor trace of each state (ESP and AH), but not until 
tonight when people are off the system.  I will pass that along this 
evening sometime.

Thanks,
Jeff

Philippe Lang wrote:

>Hi Jeff,
>
>Can you post maybe a network trace (do you have a unix machine , where you
>could run tcpdump?) of both situations (AH - ok / ESP - not OK)?
>
>If I'm not wrong, Outlook is connected to Exchange precisely with UDP, and
>that problem look really similar to the AD problem I had.
>
>-----Message d'origine-----
>De : Jeff Buehler [mailto:jeff at buehlertech dot com] 


>Cc : Philippe Lang; m0n0wall at lists dot m0n0 dot ch
>Objet : Re: [m0n0wall] outlook -> exchange problem
>
>The problem is very selective (it affects ONLY Outlook to Exchange) and in a
>production environment, so I am a little hesitant to try a version that
>hasn't gone through a lot of testing.  There is also not an easy way for me
>to lab this, since the problem is intermittent - some systems seem to
>exhibit it, while others are OK - and I have to get on a plane to get at
>this particular network physically.
>
>I ran ping tests from the client system to the Exchange system (ping
>the.server.com -f -l 1472) the result of these was no fragmentation up to
>1472.  I also ran Network Monitor on the Exchange Server, which was
>inconclusive, but admitting my ignorance: is there a way to detect
>fragmented packets using Network Monitor?  There was nothing obvious in the
>traces that I ran.
>
>My best guess at this point is some sort of latency issue, where the
>encryption/decryption of the packets is somehow taking long enough to cause
>timeouts on the server or client for this Outlook -> Exchange operation -
>poorly handled fragmented packets would make sense in terms of causing this,
>but wouldn't the ping detect this?  The network itself is a 1.5 mb T1 to
>another 1.5 mb T1.
>
>Also, each of the m0n0wall's in question is running a Duron 1.8 GhZ
>processor - I have never seen the load on these go above 2%, so the hardware
>should be able to handle the compression and decompression without lagging,
>I assume.  The speed improvement using AH instead of ESP is noticeable
>across remote desktop.  What is the point of AH across IPSEC if it provides
>little or no security?  Is it just an issue of the key exchange, or is it
>the whole data packet that Phase 2 deals with?
>
>Thanks,
>Jeff
>
>Kristian Shaw wrote:
>
>  
>
>>Hello Jeff, Philippe,
>>
>>I have created a version of m0n0wall that just corrects the fragmented 
>>packet issue and you can download it from the link below. I've also 
>>done an image for the net48xx but I have no way of testing it.
>>
>>http://www.klshaw.co.uk/m0n0wall/
>>
>>Please don't make this link public - it's not hosted on a very fast 
>>connection.
>>
>>Regards,
>>
>>Kris.
>>
>>----- Original Message ----- From: "Philippe Lang" 
>><philippe dot lang at attiksystem dot ch>
>>To: "Jeff Buehler" <jeff at buehlertech dot com>; <m0n0wall at lists dot m0n0 dot ch>
>>Sent: Thursday, February 09, 2006 9:44 AM
>>Subject: RE: [m0n0wall] outlook -> exchange problem
>>
>>
>>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
>>
>>
>>
>>    
>>
>
>
>  
>