How TMG Data Packager can assist you troubleshooting VPN Site to Site Issues
Although the VPN template screen (see figure below) doesn’t seems to have any news on this area, the new TMG Data Packager introduces new logs that can assist you when troubleshooting VPN site to site issues.
The Oakley log file that TMG Data Packager creates contains the IKEEXT.ETL (IKE Tracing) and the WFP.TMF (file that will be used to parse the ETL file) files. In order to parse this file you will need to download the tools TRACEFMT.exe and TRACEPRT.dll from the Windows XP SP2 Support Tools. After installing those tools you can extract the content of the TMG CAB file to a folder and run the command below to parse it:
C:\Program Files\Support Tools>tracefmt.exe Y:\temp\VPN\TmgPackage\IkeExt\ikeext.etl -tmf Y:\temp\VPN\TmgPackage\IkeExt\wfp.tmf -o Y:\temp\IKEOutput.txt
Setting log file to: Y:\temp\VPN\TmgPackage\IkeExt\ikeext.etl
Getting guids from Y:\temp\VPN\TmgPackage\IkeExt\wfp.tmf
Event traces dumped to Y:\temp\VPN\TmgPackage\IkeExt\IKEOutput.txt
Event Summary dumped to Y:\temp\VPN\TmgPackage\IkeExt\IKEOutput.txt.sum
Exit Status: 38
After converting it you can read the IKEOutput.txt file, there you will find the log in the following format:
Package is received and processed according to IPSec Parameters that should match between both endpoints:
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 0|192.168.0.10|Received packet
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 0|192.168.0.10|Local Address: 192.168.0.7.500 Protocol 0
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 0|192.168.0.10|Peer Address: 192.168.0.10.500 Protocol 0
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|iCookie 98b22fe79d9d675f rCookie 1610c0b30c6bbe60
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|Exchange type: IKE Quick Mode Length 300 NextPayload HASH Flags 1 Messid 0x3d6edc77
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|mmSa: 0x000000000265B9F0
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|Create QMSA: qmSA 000000000265ED60 messId 3d6edc77
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|Processing QM. MM 000000000265B9F0 QM 000000000265ED60
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|Process Payload HASH, SA 000000000265B9F0 QM 000000000265ED60
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|Process Payload ID, SA 000000000265B9F0 QM 000000000265ED60
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|Process Payload ID, SA 000000000265B9F0 QM 000000000265ED60
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|Process Payload SA, SA 000000000265B9F0 QM 000000000265ED60
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|QM propNum 1, transformNum 0, peerSpi 3151228040
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|QM transNum 1
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|PROTO: ESP Algo 3
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|IPSEC_LIFE_TYPE: 1
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|IPSEC_LIFE_DUR: 3600
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|IPSEC_ENCAPSULATION_MODE: 1
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|IPSEC_HMAC_ALG: 2
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|IPSEC_GROUP_DESC: 2
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|IsRecvPolicyTunnelPolicy: TRUE
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|Looking up QM policy for IKE
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|QM localAddr : 10.10.10.0.0 Mask 255.255.255.0 Protocol 0
[0]00F8.0B50::01/01/1601-05:01:53.375 [ikeext] 1|192.168.0.10|QM peerAddr : 10.40.40.0.0 Mask 255.255.255.0 Protocol 0
Policy identification and verification
[0]00F8.0B50::01/01/1601-05:01:53.387 [ikeext] 1|192.168.0.10|Policy
GUID: {a167bf6c-78ff-4b3d-b619-1ea03d29664a}
LUID: 0x8000000000000003
Name: ISA VPN S2S tunnel to network STSTMG
Description: (null)
Flags: 0x00000000
Provider: <unspecified>
Provider data:
Verification of the Quick Mode parameters
Type: IKE Quick Mode Tunnel
Proposals: 1
-- 0 --
Lifetime:
Seconds: 3600
Kilobytes: 100000
Packets: 2147483647
PFS group: 2
SA transforms: 1
-- 0 --
Type: ESP-Auth & Cipher
Auth transform:
Type: SHA1
Config: HMAC-SHA1-96
Crypto module: <unspecified>
Cipher transform:
Type: 3DES
Config: CBC-3DES
Crypto module: <unspecified>
Flags: 0x00000080
Dont negotiate 'byte' lifetime
Local tunnelEndpoint: 192.168.0.7
Remote tunnelEndpoint: 192.168.0.10
Normal idle timeout (seconds): 300
Idle timeout in case of failover (seconds): 60
.
.
. log continues..
The log can be pretty extensive and it is very important to know what you are looking for (which error are you chasing), mainly when the scenario is related to TMG site to site VPN with third party vendors. Sometimes the IPSec parameters doesn’t match and this is the most common cause for failures during the IPSec negotiation. This logging can be pretty handy in those scenarios since it gives verbose information about what it is happening behind the scene.
Comments
Anonymous
January 01, 2003
I talked to the Windows Networking guys and they said that the WFP is only public available on the Windows 2008 SP2, that's why you don't see it on R2. Unfortunetly, for R2 the WFP seems to be available internal only.Anonymous
January 01, 2003
Which version of Windows you are using? This blog was written using Windows Server 2008 SP2.Anonymous
July 30, 2010
Thanks for the blog. The problem i encounter when attempting to read the IKE logs is that i don't have the WFP.tmf file. It doesn't seem to be native on the system. The Data packager isn't generating it either. Perhaps my settings are wrong?Anonymous
August 03, 2010
Currently running Server 2008 R2 Standard.Anonymous
January 06, 2014
Pingback from Unable to access resources after enabling site to site connectivity with Windows Azure | UC3