I have a fileserver in a standard W2003 SP2 joined to a native 2003 domain.I haveenabled IPSec for CIFS/SMB/NetBios to my fileserver allowing to communicate also with non IPSec clients.With group policy i have enabled IPSec for CIFS/SMB/NetBios to some of my clients.All my clients works in XP Pro SP2 systems.My problem is that the clients that do not have IPSec policy and try to work with Microsoft's Office Access databases which are stored to the fileserver after a period of inactivity while the database is open they get a "Network error OR File not found" and the database goes to a "non responding" state.They do not have problem with anything else.The clients with IPSec policy enabled do not have any problem at all.My network is an Intranet separated with vlans for the servers and the clients and are routed by a Cisco router (intervlan).All my clients have roaming profiles and works OK.Any help is apreciated.Thank's in advance.

It sounds like you may have configured your IPsec rules to "REQUIRE" IPsec authentication, instead of "REQUEST". If you set the server to require IPsec authentication, then client computers that do not support the IPsec rules cannot communicate with that server at all.If you set the server to request authentication instead, then it will authenticate with clients that it can, and will continue to work in plaintext with computers that cannot authenticate.I hope this helps.Dave Bishop

Dave my IPSec rules have Filter Action "Request Security (Optional)" because i have clients that are not IPSec enabled and must use the fileserver.The problem is that everybody have access to the fileserver IPSec enabled AND no IPSec enabled , BUT the no IPSec enabled after some time they experience problems with the data that are on the fileserver.It seems like the session with the fileserver closes and when they try to open it again they get errors "Network drive not found OR the file location is missing etc" and they have to try again.This a serious problem because if they have let's say a Word document open with some changes in it and they try to save it , they loose everything.This happens only with the non IPSec enabled users!

It's not obvious where the disconnect is actually occurring. I recommend that you 1) dig through the event logs on both the server and the clients to look for events that you might be able to correlate with the disconnects. Also, consider using Netmon (http://go.microsoft.com/fwlink/?linkid=94770) to capture network traffic between the two computers to see which is actually causing the drop and investigate from there. What version of Windows (both client and server) are we talking about? Any other differences between the IPsec-enabled and non-IPsec clients?One of my peers on the IPsec team suspected the following:Can you set up an IPsec "Permit" rule from the Client_IP <-> Server_IP for one of the non-IPsec clients? What happens to that client then? Does the problem still repro? If so, then it's likely not an IPsec problem since that client is now out of the picture that way. If the problem does not repro any longer, then that's when you'll have to dig through thenetmon traffic to find out where the disconnect isoccuring, and in the event log to hopefully figure out why.Dave Bishop - MSFT

Dave first of all i want to thank you about your concern in my problem.My servers uses Windows 2003 Enterprise SP2 and my clients Windows XP Pro SP2 and all my events logs are clean without any errors or warnings.I tried the IPSec Diagnostic tools to a non IPSec client and fileserver with the following indications into theipseCureLocalModeLog.txt:When everything is OKIPsec filters, SAs Diagnosis:--Passed : Generic MM Filters Configured--Passed :Specific MM Filters Configured--Information: No Specific Tunnel Filters Configured--Passed: Main Mode Policies Configured correctly--Passed: Quick Mode Policies Configured correctly--Failed: No Main Mode SAs exist between "fileserver's IP" and "client's IP"--Passed: Quick Mode SA exists between "fileserver's IP" and "client's IP". Traffic will be secured--Soft SA exists between "fileserver's IP" and "client's IP". Traffic will not be protectedWhen the problem occursIPsec filters, SAs Diagnosis:--Passed : Generic MM Filters Configured--Passed :Specific MM Filters Configured--Information: No Specific Tunnel Filters Configured--Passed: Main Mode Policies Configured correctly--Failed: Quick Mode Policies Configured correctly--Failed: No Main Mode SAs exist between "fileserver's IP" and "client's IP"--Failed : No SA exists between "fileserver's IP" and "client's IP"----However filters exist. Refer logs to debug the failureI tried to capture the traffic with "Wireshark" but i was not able to find out any problem. Now i have disabled the IPSec rules and everybody is happy.I will try the "Permit" rule and i will inform you.

Clients unaware of IPSec should be able to connect to a server that requests but does not require IPSec. If your clients can successfully make an initial connection to your file server, then IPSec itself is set up "correctly" for request only. However, the server still sets up security associations for such clients. On the server, if you use the IPSec Monitor snap-in to view Security Associations under Quick Mode, you will see SAs for IPSec unaware client IPs. They are the ones that will have Request Security as the negotiation policy but identify "<none>" as the negotiated terms of integrity and encryption. These SAs will expire after a certain number of seconds or KB of data transmitted as with any other SA. When the client tries to reconnect after that, a security association must again be negotiated on the server side. I think Access may failing only after inactivity because it times out before an SA can be re-negotiated. The initial Access connection may be able to deal with the latency of setting up a connection, but subsequent connections from an open and running process may not be able to account for it. I vaguely recall problems posted about NIC auto-speed negotiation causing similar behavior with Access. Using explicit Permit rules for those IPs may work around the issue, but I recommend you also consider modifying the filter action check box called "Access unsecured communication, but always respond using IPSec." In the built-in Request Security filter action that box is checked by default. I have not tested this extensively myself, but you might want to test a new Request Security filter action that has that box unchecked. That would make the policy like a Respond Only policy. In that case I would expect the server to just accept all traffic from your IPSec unaware clients without ever attempting to negotiate an SA. If that works, that would be easier than managing extra Permit rules -- just be sure to test it with your IPSec aware clients as well. Traffic to and from them will not be secured in this situation unless they initially request it. In any event, your bestcourse of action may be to investigate if there are any Access client network settings that can be configured to account for network latencyin restablishing a connection after long periods of inactivity. The less you have to muck around with established and otherwise working IPSec policies the better. I hope this helps.

Thank you about the info that you gave me.The behavior of my unaware clients are exactly as you described.I will follow your proposal about the filter "always respond using IPSec", and i will inform about the results.

The solution to the problem was that the IPSec service was running to the clients that were IPSec unaware.When i stopped the service everything worked OK.