[ previous ] [ next ] [ threads ]
 From:  "Kristian Shaw" <monowall at wealdclose dot co dot uk>
 To:  "Jeff Buehler" <jeff at buehlertech dot com>
 Cc:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] RE: RE : [m0n0wall] outlook -> exchange problem
 Date:  Mon, 20 Feb 2006 00:17:09 -0000

I've been reading the suggestions and I must admit it seems you've tried 
most of the obvious things. There is no RPC protocol inspection in m0n0wall 
so I don't think its an issue with that and you are unlikely to reach the 
firewalls' state limit of 30k connections. However, you could try these 
settings for the firewall:

- TCP Idle Timeout: try 86400 (24hrs)
- IPSEC timeouts: for phase 1 try 86400 (24 hrs) and for phase 2 try 3600 (1 

Perhaps you also need to start looking at your AD configuration. Have you 
set up different sites for each location and assigned subnets for each in AD 
Sites and Services?



----- Original Message ----- 
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>
Sent: Sunday, February 19, 2006 7:31 PM
Subject: Re: [m0n0wall] RE: RE : [m0n0wall] outlook -> exchange problem

> Hi Phillipe -
> Yes, I tried a bunch of different static NIC settings, and other Intel Pro 
> specific settings - no change in behavior at all.  No packets are lost 
> between the machines with the Outlook problem (at all) and the server, 
> even when the problem is active with any protocols/ports that I have 
> tested using ping or rpingc/rpings, etc.  Even fully fragmented packets 
> are not lost as I am using a modified version of m0n0wall 1.22 that allows 
> fully fragmented packets across ipsec.  The problem ONLY occurs within 
> Outlook.
> The switch does not have an admin interface, but the network is strong and 
> solid even with the PC's that have the problem so I think the switch can 
> safely be rules out.  The problem is ONLY with Outlook to Exchange, 
> everything else is rock solid.  These same four problem platforms connect 
> to shares across the IPSEC VPN, do remote desktop, connect to the 
> Internet, and ping with no problems whatsoever.  RPC tests to the server 
> and back across IPSEC are perfect (to the extent I tested them with rpingc 
> and rpings), and packet analysis (to the extent I am able to 
> read/understand it - I have not compared a good connection snapshot with a 
> bad connection snapshot, but frankly I don't think the client wants to pay 
> me for 4 hours of detailed packet analysis for this problem) all look 
> good.  My best guesses at this point (and believe me, these all sound far 
> fetched to me):
> 1. IPSEC combined with some unknown element, such as Intel NICS, or AD 
> account slightly modified by addition of new machine, is somehow munging 
> some noxious MS protocol (RPC/Kerberos) just enough that it fails 
> intermittently (?)
> 2. Some timing problem with IPSEC and some noxious MS protocol that can't 
> cope with whatever the timing issue is, like the IPSEC lifetime.  Changing 
> the IPSEC lifetime didn't help.
> 3. Some licensing bug in which there is an unknown problem with X users, 
> and Exchange fails to notify in any way
> 4. Some intermittent problem with m0n0wall in which the firewall closes 
> and reopens certain ports across IPSEC, or interferes with them, when a 
> certain number of users become active over it or a certain amount of a 
> specific kind of traffic passes over it.
> 5. some problem with  ipsec over m0n0wall when a certain number of users 
> are active (strangely enough 16 seems to be the magic number)
> 6. ???
> WarningGripeFunction {
>        ...?  I am finding new reasons to despise Outlook with Exchange, as 
> if I needed any more.  Why can't MS/Exchange just pick a couple of 
> standard ports and use them like any decent service?  Just implementing 
> RPC over HTTPS made me want to commit seppeku. On a *BSD or Linux system 
> this stuff is a cake walk.
> }
> Sorry for the gripe!  Thanks again for your thoughts on this.
> Jeff
> Philippe Lang wrote:
>> Hi,
>> Have you tried setting the NIC of the new PCs to a static Ethernet speed,
>> like 100 Mbits/s Half/Full Duplex?
>> One thing you could try is to launch "ping the_server_ip -t" on all the
>> machines, make your problem happen, and check if you have more ICMP 
>> packets
>> being lost on your new machines. This could help solving the problem.
>> Bye the way, is your switch administrable? What model do you have?
> ---------------------------------------------------------------------
> 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