Windows 2008 IPSec tunnel goes down between RODC and DC
We are using Windows 2008 IPsec tunnel between RODC located in DMZ and DC located on corporate network. When the IPsec tunnel goes down no one can be authenticated and we can't get in the RODC anymore because the passwords are not preserved on RODC by our design. That is fine. The question is why the tunnel does down and don't get up again by itself ? To have the tunnel reinitiate again we must access the DC located in the corporate network and then ping the RODC. Doing that extra step we are fine. We schedule a task in scheduler to initiate a ping every 5 minutes. Doing that extra step or using the scheduler is fine but I feel that is not the best way to fix it. The RODC has been deployed following this technet : http://technet.microsoft.com/en-us/library/dd728035(WS.10).aspx The IPsec has been deployed following this technet : http://technet.microsoft.com/en-us/library/bb742429.aspx Stephane
January 13th, 2011 12:05pm

Hi, Thank you for your post here. 1. What is the symptom when the IPsec connection drops? Does it get dropped after a period of time? 2. Is there any error message which may indicate the reason why it doesn't get reconnected?
Free Windows Admin Tool Kit Click here and download it now
January 14th, 2011 5:09am

Hey Miles, First I don't want focus on the reason of the tunnel drop for now because we can find legit reason by example a windows update happen on the RODC and then the server must reboot. I would like more focus on why the tunnel don’t get up again by itself. I mean from my previous example if the RODC server reboot because of a windows update we can’t be authenticated anymore by this server or we can’t locally log on because the tunnel is down. So we must get in the primary DC and then ping the RODC so this action will force the tunnel to be mounted and authenticated by the RODC Stephane
January 14th, 2011 11:24am

I finally opened a case with Microsoft Support. Here is what they told me. The IPsec client will send the QM deletes only if the oakley shutdown is not due to machine shutdown. It is a by design behavior for shutdown security. Therefore, when the RODC is shutting down, it won’t send QM deletes to the internal DC for the security design. (I guess so we are still protected by IPSEC until the machine is offline) When the RODC comes back up then the other end is still using the same SA and thus we can't reconnect until the SA timeout has passed. This happens because when you restart the RODC, the Quick Mode SA teardown on the internal DC doesn't happen. Therefore, after the RODC has rebooted, it forgets to do the IPSEC Kerberos key exchange what it has done with the internal DC before RODC shutdowns, whereas the DC hasn't and will only accept encrypted traffic from the RODC until the SA Idle Time is hit and then we can re-negotiate the key. It is a by design behavior which is confirmed by our security engineer. It seems a ping from the DC to the RODC could force the IPSEC Kerberos key exchange to be re-negotiated. I have found a similar case we met before. At that case, the workaround is the schedule ping which you have done. And another workaround is to choose pre-shared key or certificate authentication mode. Stephane
Free Windows Admin Tool Kit Click here and download it now
January 25th, 2011 3:18pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics