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
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)
...? 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.
Philippe Lang wrote:
> 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?