IMON blocking ActiveSync

I saw a few other reports of this around, but never a very conclusive fix on it. So here it goes, as we say.

We have primarily Windows Mobile Treo devices, which sync directly with our exchange server. When not in a cradle, Exchange syncing is done over the air through the cellular network. Once put in a cradle (all USB at this point), they tunnel through the Microsoft Windows Mobile Remote Adapter virtual connection to whatever interface can get them to the server. Without Nod32 on a system, we didn't have a problem with this. Once it was installed with the IMON module running, the connection to the exchange server breaks. Files and favorites still sync correctly, but anything that has to cross that NAT boundary fails. Disabling the IMON service with the check box, along with giving exclusive trusts to the host names and IPs of all steps involved, did nothing to correct the problem. Only telling the module to Quit gets the device syncing again.

On with the packet captures
http://e.photos.cx/ethernetsidecrop-ff2.png
This is a capture across the ethernet adapter after a failed sync while the IMON module is loaded. It repeats that general cycle you see about 10 times or so before it finally fails. A whole mess of reset flags and I'm not really sure what is going on. Sorry for having to obscure IPs but we use public ones so I will error on the side of caution. The checksum errors are a result of crappy Broadcom nics and are normal.

http://e.photos.cx/ethernetsidecrop-646.png
This is a capture on the same ethernet adapter after IMON is unloaded. Everything runs smooth and there are no conflicts or communication issues with our exchange server.

So any ideas? I'm ripping my hair out trying to find a setting to fix this. I also tried disabling the DMON and EMON services just to be safe but they did not seem to be in conflict with anything. It just seems like whatever hooks the IMON module puts in to Winsock breaks whatever address translation or tunneling ActiveSync uses to reach an exchange server. This behavior persists across clients running XP and Vista.

 

Server and IMON running are two different and incompatiable things . IMON must be off on server due to many factors/reasons . The way it is created is not suitable for servers at all , that is why by default the setup advices IMON to be off.

AMON , DMON , EMON , XMON are your other products which will do the job very well.

 

You misunderstand; the exchange server doesn't have IMON on it. It doesn't even run Nod32. This is all from within a client machine that acts as the middleman between a Windows Mobile device connecting to the exchange server via the conduits created in ActiveSync.

 

Ok , I apologies .

There might be an issue .
There will be no security problems if you disable/unload IMON from all the problematic machines

 

I ended up tracking down someone on a different forum who had Eset on the phone about this one at some point. It has to do with how IMON injects itself in to the Winsock layers and screws up the conduit ActiveSync creates. Disabling IMON is an option but I would like to avoid that considering the number of reckless users accessing the kinds of sites that would contain 0-day vulnerabilities. v3 seems to have addressed the problem from what I can tell, so I will just sit tight until the corporate client is out; that or re-deploy the ActiveSync 4.7 package on top of Nod32 and see if that sorts it out.