[ previous ] [ next ] [ threads ]
 From:  Jeff Buehler <jeff at buehlertech dot com>
 To:  Jeff Buehler <jeff at buehlertech dot com>
 Cc:  Kris Shaw <monowall at wealdclose dot co dot uk>, m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] outlook -> exchange problem
 Date:  Fri, 17 Feb 2006 16:15:17 -0800
Hi all -

Well, I am sad to report that this did not actually solve the original 
problem, so I thought I would try one more time and see if anyone has 
any other ideas.  To summarize I have two LANS connected via a m0n0wall 
ipsec tunnel (each has it's own m0n0wall device), each on it's own T1.  
LAN B connects to Exchange on LAN A over the the tunnel - nothing goes 
over the WAN.  The issue of fragmented packets (such as those forced by 
MS-RPC) not being allowed through has been resolved and is working.  
Everything works well, but recently when we added some new Dell PC's 
with Intel 100 NICS, the new PC's (with old user accounts) have problems 
staying connecting to the Exchange running Outlook.  This is VERY 
intermittent - if I go into Control Panels -> Mail and modify settings, 
I may fix it for a while, or cause it to happen for a while.  it only 
happens on one or two PC's at a time (so far).  One minute they can 
send, the next minute the connection with the server is lost.  This is 
ONLY a problem with Outlook to Exchange.

The IPSEC tunnel connects properly, but one question - each LAN uses the 
same pre-shared key and no certificate - is this OK, or might it cause 
some kind of connection issue like this somehow?

There is no specific time or pattern to the failures that I can 
discern.  Each of the new PC's uses the same kind of NIC configured at 
Dell - changing NIC settings makes no difference.

I have tried:

1. dealing with fragmented MS-RPC packets - this is resolved
2. dealing with MS Kerberos weirdness by forcing NTDLM authentication 
only - this looked like it might help, but didn't in the end.
3. trying AH mode in place of ESP mode - this seemed to help for awhile, 
but the problem reappeared
4. considered licensing - there are no errors on the Exchange Server 
that I can find that would indicate a licensing issue
5. creating new user accounts - in one case, this helped for awhile for 
no apparent reason, but the issue came back.
6. analyzing the packets on the server side.  Everything looks OK, but 
it's a lot of data and I'm not always clear exactly what I'm looking 
at.  The client is definitely connecting at the right (LAN) IP.
7. logging LAN packets going through in the firewall - they all seem to 
pass OK, and to the right location.
8. lots (!) of other stuff

Has anyone ever seen anything like this?  What is Microsoft doing for 
Outlook/Exchange communication that could cause something like this 
across an IPSEC tunnel?  I am going to have to resort to RPC over 
HTTP(s) - now I know why it exists!

Thanks for any ideas...


Jeff Buehler wrote:
> Hi -
> Aha!  I had a feeling something like that might be the case 
> (everything basically worked without the WAN rules, which was 
> confusing me until now).  Thanks for the clarification...
> That did the trick - I had set the two routers that were able to ping 
> out successfully to allow frags on the LAN, but the router that I had 
> trouble with had that off.
> Thanks again, Kris!
> So, in recap for posterity (anyone unlucky enough to have to deal with 
> this issue in the future, that is), to manage a Microsoft IPSEC VPN 
> that needs log in capability across the VPN, and Outlook -> Exchange 
> capability, it is necessary to:
> 1. Have a version of M0n0wall that allows fragmented packets across 
> IPSEC ( presently http://www.klshaw.co.uk/m0n0wall/)
> 2. No WAN rules are required for IPSEC at all
> 3. For the LAN rule that applies to the IPSEC connection, Allow 
> Fragmented Packets must be set
> This is due to the fact that Microsoft puts packets of 2048 bytes in 
> its RPC protocol for reasons that I can only imagine... but that I try 
> not to because I have enough to irritate me!
> Jeff
> ---------------------------------------------------------------------
> 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