IPSec L2TP site-to-site VPN from ISA 2004 on SBS to Windows 2003 - no longer working
As of today the remote office Windows 2003 Server was no longer able to connect in our site-to-site VPN. There were no changes to either server.
We have since tried anything we could think of. We are using pre-shared key rather than certificates so the pre-shared keys were re-entered, we rechecked the AD VPN user's to make sure they were active, IPSec and RRAS services were restarted at both locations. And we checked event logs (more on that below). Client's connecting through PPTP are still able to connect.
Event log: Error 20111 from RemoteAccess "A Demand Dial connection to the remote interface VPN_*HEADOFFICE* on port VPN3-127 was successfully initiated but failed to complete successfully because of the following error: The L2TP connection attempt failed because security negotiation timed out.
Prior to that error, however, there are two events 20186 "Interface VPN_*HEADOFFICE* is now reachable." and 20180 "Interface VPN_*HEADOFFICE* is unreachable because the connection attempt failed."
So it appears to make a connection, but then drops the connection. I've also looked into the Oakley logs and found the following:
-
-
-
-
- 6-08: 22:20:13:367:c04 MatchMMFilter failed 13013
- 6-08: 22:20:13:367:c04 Responding with new SA 0
- 6-08: 22:20:13:367:c04 HandleFirstPacketResponder failed 3601
-
-
-
I wasn't able to locate any information that would resolve this issue based on the highlighted items. There are other people reporting similar issues, but no one with a resolution.
I also noticed that the "Receive: (get) SA" value was "0x00000000" for transmissions from the Remote office VPN. Obviously those should be filled with a real value. When I looked at the oakley log in more detail I was able to find SA values but they would then be followed by other transmissions where the SA was reset back to 0. I wasn't able to find any information about the cause of this.
Finally, I found this in the log:-
-
-
-
- Sending: SA = 0x07DB3BC8 to xxx.xxx.xxx.xxx:Type 2.500
- sadb_schedule_kill_oldPolicy_sas
- isadb_set_status sa:07DB3BC8 centry:00000000 status 3619
- New policy invalidated SAs formed with old policy
- Sent first (SA) payload Initiator. Delta Time 30 0x0 0x0
- constructing ISAKMP Header
- constructing DELETE. MM 07DB3BC8
- 6-08: 22:49:27:874:c04
-
-
-
What that appears to be saying is that a new policy is invalidating and destroying the old policy (the old SA?). However, we did not implement any new policy?! No changes were made until after the VPN broke and I have kept notes of those changes (the most significant being the change in the shared key).
Ideas anyone?-
Answers
Hi,
Thank you for your information.
As far as I know, bad network probably fragment the pre-shared key exchange connection. The ISA firewall will work great in L2TP/IPSec and IPSec tunnel mode with good quality network. Meanwhile, please refer to the following article about the error message.
http://support.microsoft.com/kb/299307/en-us
Regards,
Nick Gu - MSFT- Marked As Answer byNick Gu - MSFTMSFT, ModeratorWednesday, June 24, 2009 6:43 AM
All Replies
Hi,
Thank you for your post.
According to your description, I understand that you have problem with site to site VPN about ISA 2004.
I did some research regarding this issue. based on my experience, MatchMMFilter means that the ISA could not find a Main Mode matching policy for the client. To resolve this issue, we may try to reset the policy store: delete the registry subkey and then rebuild the policy.
1. Delete the local policy registry subkey. To do this, follow these steps:
1).Click Start, click Run, type regedit , and then click OK.
2).In Registry Editor, locate and then click the following subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local
3).On the Edit menu, click Delete.
4).Click Yes to confirm that you want to delete the subkey.
5).Quit Registry Editor
2. Rebuild a new local policy store. To do this, follow this step:
1).Click Start, click Run,
2).type regsvr32 polstore.dll , and then click OK.
Regards,
Nick Gu - MSFT- Update
We eventually decided to take both servers through full reboot cycles (we try to avoid doing this with the SBS box because it's boot cycle time is long). We were still getting errors after the reboot (the same "MatchMMFilter failed" and "New policy invalidated SAs formed with old policy" errors). The VPN was disabled on both boxes (from within RRAS, not ISA) and then re-enabled. Then we got e more "New policy invalidated SAs formed with old policy" error - then it seemed to repair itself?
While the issue does appear to be resolved now, this isn't the first time that the VPN has gone "wonky" so I do want to take this opportunity to understand what I can from the oakley logs.
Nick
Thank you for responding. I'm definitely going to make note of this for future reference. The "new policy invalidated" errors seemed to indicate to me that something had to be reset somewhere, but no amount of googling (or binging) was producing any results that helped with that.
Can you tell me if there was any reason or meaning to the message "Receive: (get) SA = 0x00000000" in the oakley log? I would take that to mean that it's not receiving a proper authentication request from the remote Site (in our case the Windows 2003 box).
Also, do you have any specific information related to the "New policy invalidated SAs formed with old policy" message? Again, google showed other reports of this message with people having issues, but no resolutions. I'd just like to understand what it means. Is it related to the MatchMMFilter?
Thanks Nick. Hi,
Thank you for your information.
As far as I know, bad network probably fragment the pre-shared key exchange connection. The ISA firewall will work great in L2TP/IPSec and IPSec tunnel mode with good quality network. Meanwhile, please refer to the following article about the error message.
http://support.microsoft.com/kb/299307/en-us
Regards,
Nick Gu - MSFT- Marked As Answer byNick Gu - MSFTMSFT, ModeratorWednesday, June 24, 2009 6:43 AM

