[ previous ] [ next ] [ threads ]
 From:  "Philippe Lang" <philippe dot lang at attiksystem dot ch>
 To:  "Jeff Buehler" <jeff at buehlertech dot com>, "Kristian Shaw" <monowall at wealdclose dot co dot uk>
 Cc:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall] outlook -> exchange problem
 Date:  Thu, 9 Feb 2006 18:07:02 +0100
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] 
Envoyé : jeudi, 9. février 2006 17:59
À : Kristian Shaw
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?


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
smime.p7s (4.1 KB, application/x-pkcs7-signature)