Oakley.log for IPSec...
Hello. I was wondering if anyone knows how to turn on the Oakley log for detailed IKE Logging on a Server 2008 box. I tried the:Netsh ipsec dynamic setconfig ikelogging 1but I receive a message:The request is not supported.Help? :) Thanks in Advance!--Gene.
July 24th, 2008 1:08pm

With the redesign of the IPsec and Firewall components into the Windows Filtering Platform (WFP), Oakley logging is no longer available. However, logging for IKEv1 and AuthIP is possible through IKE Tracing. IKE Tracing provides information about IPsec negotiations for IKEv1 and AuthIP. IKE Tracing uses ETW Tracing and creates a non-human readable ETL format file. This file then needs to be converted to analyze the data. 1. Create a local \Tools directory and copy in TRACEFMT.exe and TRACEPRT.dll from the Windows XP SP2 support tools as a free download. http://www.microsoft.com/downloads/details.aspx?FamilyID=49AE8576-9BB9-4126-9761-BA8011FABF38&displaylang=en 2. Set the following registry key: RegKey: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters RegValue: EnableLogging RegData: 0x1 RegType: DWORD 3. Stop/Start the IKEEXT service. 4. Repro the problem. 5. Verify the log file was created: %windir%\system32\ikeext.etl and has flushed the memory buffers into the file. (Verify the file is not a 0 byte value.) 6. Run the following command from an elevated command prompt with the working directory set to the \Tools directory: tracefmt.exe %systemroot%\system32\ikeext.etl -tmf %systemroot%\System32\wfp.tmf -o %TEMP%\wfpdiag.txt 7. Review the WFPDiag.txt file for Oakley-level data. Because Windows Vista/Windows Server 2008 support both IKEv1 and AuthIP, both protocols log into IKE Tracing. 8. Disable Logging after reproducing the problem: RegKey: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters RegValue: EnableLogging RegData: 0x1 RegType: DWORD 9. Stop/Start the IKEEXT service. Laura Zhang - MSFT
Free Windows Admin Tool Kit Click here and download it now
July 28th, 2008 6:00am

Related to this thread...we seemed to have found a bug...we had two "Connection Security Policies" with clear separation of the IPs/subnets assigned to each...the DC Server that received the GPO was applying the wrong authentication method to the rule. It seemed that the processing was assigning the authentication method of one policy to the other policy. Double-checking all the rules, the settings all seem correct. It just seemed to be a parsing bug in the computer scope of the connection security policy causing it to try and negotiate with authentication method of the other rule. As seen below...it should have pulled a auth method "preshared key" from the correct policy with the explit IP in the computer scop of 10.10.15.8, but it selected the auth method from the other rule seemingly out of thin air as that IP or subnet is not listed at all in other Connection security policy scope.[2]0420.0D48::00/00/0000-00:00:00.000 [ikeext] 0|10.10.15.8|Processing acquire with ipsec context 44, keyMod 0 [2]0420.0D48::00/00/0000-00:00:00.000 [ikeext] 0|10.10.15.8|QM localAddr: 10.10.70.195.0 Protocol 0 [2]0420.0D48::00/00/0000-00:00:00.000 [ikeext] 0|10.10.15.8|QM peerAddr: 10.10.15.8.0 Protocol 0 [2]0420.0D48::00/00/0000-00:00:00.000 [ikeext] 0|10.10.15.8|Acquire flags 1 [2]0420.0D48::00/00/0000-00:00:00.000 [ikeext] 0|10.10.15.8|Peer State 0 [2]0420.0D48::00/00/0000-00:00:00.000 [ikeext] 0|10.10.15.8|IkeBeginMMInitiator: Setting acquire 02A31510 as prime acquire for MM SA 02A431B0 [2]0420.0D48::00/00/0000-00:00:00.000 [ikeext] 0|10.10.15.8|Looking up MM policy for IKE [2]0420.0D4C::00/00/0000-00:00:00.000 [ikeext] 0|10.10.15.8|Processing acquire with ipsec context 44, keyMod 1 [2]0420.0D4C::00/00/0000-00:00:00.000 [ikeext] 0|10.10.15.8|QM localAddr: 10.10.70.195.0 Protocol 0 [2]0420.0D4C::00/00/0000-00:00:00.000 [ikeext] 0|10.10.15.8|QM peerAddr: 10.10.15.8.0 Protocol 0 [2]0420.0D4C::00/00/0000-00:00:00.000 [ikeext] 0|10.10.15.8|Acquire flags 1 [2]0420.0D48::00/00/0000-00:00:00.000 [ikeext] 0|10.10.15.8|Policy GUID: {58ce97c1-b435-41f5-9937-55caa16785b6} LUID: 0x8000000000000029 Name: 01807538-e66c-4e9d-be32-c764f5384435:DC Replication Description: Flags: 0x00000000 Provider: {1bebc969-61a5-4732-a177-847a0817862a} Provider data: 00000000 02 00 00 00 00 00 00 00 ........ Type: IKE Main Mode Soft expiry: 0 InitiatorImpersonationType: None Auth methods: 2 -- 0 -- Type: Kerberos Flags: 0x00000000 -- 1 -- Type: Certificate Inbound config: Type: Allow explicit trust list UC Berkeley
October 23rd, 2008 2:12pm

This looks like a backward step. Any improvements on troubleshooting this in 4 years, or is the security audit log the best method now?
Free Windows Admin Tool Kit Click here and download it now
May 9th, 2012 3:48am

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

Other recent topics Other recent topics