Dimante Computer Services LLC: Forums / NCP Software Support/Questions / Identify Errors using the NCP Log

Dimante Computer Services LLC :: Forums :: General :: NCP Software Support/Questions		<< Previous thread \| Next thread >>
Identify Errors using the NCP Log


Moderators: dimante	This thread is now closed

Author

Post

dimante

Sat Apr 05 2008, 09:58AM

dimante

Registered Member #1

Joined: Sun Nov 04 2007, 06:22PM

Posts: 11

NCP Secure Enterprise Client 8.10
NCP Secure Enterprise Linux Client 2.01
NCP Secure Enterprise CE Client 2.0x
NCP Secure Entry Client 8.12
Troubleshooting the IPsec connection can be intimidating at first, but if one knows what to look for, things aren't as daunting as they would seem.

First of all, lets have a look at the log file:

Extended Firewall: is stopped
Warning: could not open file - c:\crypt.key
Found adapter: ASYNCMAC1 with MTU 1500 bytes
Found adapter: PRISM1 with MTU 1500 bytes
Installed as a test license.

The first line will indicate the status of the personal firewall.
The second line regarding crypt.key can safely be ignored.
Then follows a listing of all available network interfaces the client has detected that can be used.
Followed by the status of the license, in this case, it's a test license that will expire within 30 days.

This entry in the knowledge base will not cover the connection to the ISP, but concentrate on building the IPSec VPN tunnel.

IPSDIAL::DNSREQ: resolving dnserver over provider: myvpngateway.example.com
IPCP - connected to with IP Address: 062.123.044.037. : 146.007.073.242.
IPSDIAL->DNSREQ: resolved ipadr: 198.147.245.21

In this example, the VPN gateway has not been configured as an IP address, but as a FQDN, so the first step the client does is resolve the name to an IP address so the VPN gateway can be reached.
Then the client will attempt to make a connection:

NCPIKE-phase1:name() - outgoing connect request -main mode.
XMIT_MSG1_MAIN -

We see it's a Main Mode connection. If the client does not proceed past this point, please refer to the table below. To understand the table, one needs to know what it is that is transmitted within this first message. By way of example, we'll look at this first transmission: XMIT_MSG1_MAIN contains the Proposals and Vendor IDs. If it fails here, it's most likely that the tunnel endpoint is not available, wrong IKE proposals have been selected or the wrong connection mode has been selected. Steps can be taken to verify the VPN gateway is online. Furthermore check that the proposals match that what the VPN gateway expects
(Note: "automatic mode" does not support proposals with 'mere' DES, if DES is used, please manually define a proposal. If proposals using 3DES or AES are used, then "automatic mode" will generally work.)
The Vendor IDs sent here also tells the VPN gateway what modes the Client supports; such as XAUTH, IKE-CFG, and NAT-T. In this example, only NAT-T is negotiated.

RECV_MSG2_MAIN -
IKE phase I: Setting LifeTime to 28800 seconds
->Support for NAT-T version - 3

Gateway returns with a confirmation that NAT -T is going to be used and this is negotiated. One would not expect an error to occur after this step

XMIT_MSG3_MAIN -
IPSDIAL->FINAL_TUNNEL_ENDPOINT:198.147.245.21
RECV_MSG4_MAIN -
Turning on NATD mode - - 2

NAT-T is now enabled. Errors don't usually happen after 3rd message. Had a certificate been used, and the it wasn't available, the log may have stopped here and the connection attempt aborted.

XMIT_MSG5_MAIN -

Had the log stopped after this step, then one would look in the table and see that it could be that the IKE-ID (see the Identities section in the configuration paramaters) type, or pre-shared key was incorrect, or when using a certificate, there was an error with the certificates. Another possible cause is that NAT-T has been negotiated as shown above, which means that traffic will now be encapsulated within UDP4500 datagrams and possibly there is a firewall that's prohibiting the datagrams from reaching the VPN gateway.
(Note:: NCP Secure Clients do NOT support TCP encapsulation)

RECV_MSG6_MAIN -
NCPIKE-phase1:name() - connected

Phase One has successfully negotiated. If XAUTH and IKE-CFGmode were used, they would be negotiated here before proceeding to Phase Two.
Phase Two is also referred to as Quick Mode.

XMIT_MSG1_QUICK -

This is often a point where confusion arrises. When IKE-ConfigMode is not used, one needs to define the ID1 and ID2.
ID1 is the IP address the client is going to be known as, this could be the local IP address it has, or a virtual IP address that's been 'assigned' but not pushed to the client by the VPN gateway. (The latter happens when using IKE-CFGMode).
ID2 are the networks that the client is going to reach. Some gateways are more particular about this than others. These "remote networks" can also be individual hosts, or network ranges. Pay special attention to defining the netmasks correctly as well.
Another common mistake is the incorrect definition of the PFS Group that is going to be used.

RECV_MSG2_QUICK -
XMIT_MSG3_QUICK -
NCPIKE-phase2:name() - connected
IPSDIAL - connected to on channel 1.
IPCP - connected to with IP Address: 010.000.000.010. : 010.000.000.011.

And here a connection has been made, confirmed by the presenting of the IP addresses the client is going to use.

Please note that in the table below there may be differences depending on whether one uses a certificate (RSA) to authenticate, or if pre-shared keys (PSK) are used.

Message / Sequence
Content
Possible error
MAIN MODE (PHASE 1)
XMIT_MSG1_MAIN PROP, [VID] Tunnel Endpoint (Not reachable),
IKE proposals,
Mode (Aggressive)
RECV_MSG2_MAIN PROP, [VID] Internal Error
XMIT_MSG3_MAIN KE, N, [NAT-D] Communication Error
RECV_MSG4_MAIN KE, N, [NAT-D] RSA: PKI-error (no certificate or incorrect PIN)
XMIT_MSG5_MAIN ID, [CERT], HASH/SIG PSK & RSA:
Invalid IKE-ID,
NAT-T enabled, but firewall blocking it (UDP4500)
PSK:
Invalid PSK
RSA:
PKI-error (local or remote)
RECV_MSG6_MAIN ID, [CERT], HASH/SIG PSK:
Invalid HASH (problem with the PSK)
RSA:
PKI-error, invalid signature
AGGRESSIVE MODE (PHASE 1)
XMIT_MSG1_AGGR PROP, KE, N, ID, [VID]
Tunnel Endpoint not reachable
IKE proposals
Mode (Main)
Invalid IKE-ID
RECV_MSG2_AGGR PROP, KE, N, ID, [VID], [NAT-D], [CERT], HASH
PSK:
Invalid PSK
RSA:
PKI-error (local), Invalid signature
Invalid signature
XMIT_MSG3_AGGR
HASH, [CERT], [NAT-D]
PSK & RSA:
NAT-T enabled, but firewall blocking it (UDP4500)
Waiting for XAUTH
RSA:
PKI-error (remote)

Message / Sequence
Content
Possible error
IPSEC "QUICK MODE" (PHASE 2)
XMIT_MSG1_QUICK HASH, PROP, [KE], N, ID1 & ID2 Invalid proposals, invalid ID1 or ID2 (also check Compression & PFS!)
RECV_MSG2_QUICK HASH, PROP, [KE], N, ID1 & ID2 Illegal Hash
XMIT_MSG3_QUICK HASH Remote doesn't like my HASH

Used Acronyms
PROP
Proposal
HASH
Hash< br>VID
Vendor ID
SIG
Signature
KE
Key Exchange
ID1
Source / Local IP Address
N
Nonce
ID 2
Destination Network(s) / Host(s)
NAT-D
Network Address Translation Detection
IP-COMP
IP Compression
ID
IKE-ID "Identity"
PFS
Perfect Forward Secrecy
CERT
x509v3 Certificate

Disclaimer
Considerable care has been taken in the preparation of this document, errors in content, typographical or otherwise may occur. If you have any comments or recommendations concerning the accuracy, then please contact NCP as desired.
NCP makes no representations or warranties with respect to the contents or use of this document, and explicitly disclaims all expressed or implied warranties of merchantability or use for any particular purpose. Furthermore, NCP reserves the right to revise this publication and to make amendments to the content, at any time, without obligation to notify any person or entity of such revisions and changes.

Trademarks
All trademarks or registered trademarks appearing in this manual belong to their respective owners.

© 2005 NCP Engineering GmbH. All rights reserved.


Jump: Back to top