Dimante Computer Services LLC : Forum / threads

UseBB to Vanilla Conversion Script

dimante — Wed, 23 Apr 2008 12:35:30 -0500

Do you have a UseBB database that you want to convert to Vanilla? No problem!

Get the script here

Post any questions or problems here.
-D-

Identify Errors using the NCP Log

dimante — Sat, 05 Apr 2008 02:58:46 -0500

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.

Openswan/Freeswan & NCP Secure Client

dimante — Sat, 05 Apr 2008 02:53:31 -0500

A lot of customers opt to use their existing Open/Freeswan VPN Servers in conjunction with our VPN Client, and this is no problem. Please bear in mind that NCP also provides an IPsec and feature rich VPN gateway ("Secure Server") for Linux (SuSE & RedHat / Fedora)

You may also be interested to know that we have the same client available for Linux platforms (primarily SuSE and RedHat/Fedora), as well as for PDAs running on PocketPC2002/3.

Below there's an example configuration (which is to be used as a starting point, please refer to the URLs listed at the end of the document for further information on how to implement other features as this is by no means a 'full configuration'). In this test set up, the VPN server "vpn-gw01" is listening on 22.23.24.25. (Please also have a look at a document on our website with how to configure the client: http://www.ncp.de/fileadmin/pdf/service_support/NCP_QCG_Entry_Client_VPNC.pdf)

The items within the < and > are variables you need to enter, such as passwords. This configuration assumes you're using certificates as a basis to authenticate with. Unfortunatly there isn't an example on how to configure it with the use of pre-shared keys. If you are not familiar with how to create the certificates, please refer to the http://www.natecarlson.com/linux/ipsec-x509.php#gencert which nicely outlines how to do this on a Linux box.

Two files that need to be configured: ipsec.secrets and ipsec.conf

[root@vpn-gw01]# less /etc/ipsec.secrets
#
# IPSEC SECRET FILE
#
%any 22.23.24.25 : RSA vpngw.key ""
#

[root@vpn-gw01]# less /etc/ipsec.conf
# /etc/ipsec.conf - Openswan IPsec configuration file
version 2.0 # conforms to second version of ipsec.conf specification

# basic configuration
config setup
interfaces=ipsec0=eth1
#interfaces=%defaultroute
nat_traversal=yes
virtual_private=%v4:x.x.x.x/24 # x.x.x.x internal network
# Debug-logging controls: "none" for (almost) none, "all" for lots.
# klipsdebug=none
plutodebug="control parsing"

# Add connections here
conn %default
keyingtries=1
compress="no" #this should now be supported: so "yes" is possible

disablearrivalcheck=no
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert
left=22.23.24.25
leftcert=vpngw.pem #vpngw.pem is the server's certificate

conn roadwarrior-net
leftsubnet=x.x.x.x/24 # x.x.x.x internal network
also=roadwarrior

conn roadwarrior-all
leftsubnet=0.0.0.0/0
also=roadwarrior

conn roadwarrior
right=%any
rightsubnet=vhost:%no,%priv
auto=start
pfs=yes

include /etc/ipsec.d/examples/no_oe.conf

[root@vpn-gw01 /]#

Other links that may be helpful:
http://www.openswan.org/docs/local/README.x509 &
http://wiki.openswan.org
/index.php/Configuring &
http://www.natecarlson.com/linux/ipsec-x509.php#configgw

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.

SonicWALL Pro 200 / SOHO Configuration

dimante — Fri, 15 Feb 2008 13:23:02 -0600

SonicWALL PRO 200 / SOHO VPN Setup Instructions for use with NCP Secure Client

IMPORTANT NOTE: The NCP Client (or derivative thereof, also referred to as NCP Client in this document) cannot co-exist with another VPN Client, so it
is imperative that other VPN clients have been removed before
proceeding. You will be able to use the NCP VPN Client to establish
connections to many other VPN Gateways, and are by no means locked down to only using specific vendor's VPN gateways.

SonicWALL Setup

Click on the VPN button on the left and the following is displayed:

Write the Firewall Unique Identifier down (You will need this later in the NCP setup).

Click on “Configure”

Set a shared secret on this page. Make note of this also for the NCP client setup later in this post.

Click advanced:

IMPORTANT: Make sure perfect forward secrecy is checked.

NCP Secure Client Configuration

Next we will configure the NCP client for connection:

In the NCP Client click Configuration > Profile Settings

Choose New Entry and follow each of the prompts with what is displayed below:

Give the connection a freindly name so that you can easily identify it.

The LAN selection is proper for most installations. If you use ISDN or Dial up then
you will need to make a different choice above.

Enter your shared secret that you recoded earlier and repeat it in the confirm box to
the left. For local identity put the unique identifier in that you recorded in the SonicWALL
setup section.

Click Finish.

Click Connect

A successful connection looks like this.

Thoughts?

dimante — Sat, 01 Dec 2007 11:00:10 -0600

For those of you that have UDR installed what are your initial thoughts on it?

Welcome

dimante — Tue, 27 Nov 2007 05:11:54 -0600

Welcome to the forums. If you have any suggestions or requests to make the forums better please let me know. You need to sign up on the website to make posts or reply to posts. I hope to see more and more people come and this forum become a reliable and informational location for the APECS / DISCOVERY.NET platform.

-Gates-

Cisco 3000 / PIX NCP Client Configuration

dimante — Sun, 25 Nov 2007 07:14:53 -0600

NCP Secure Client and Cisco (3000series & PIX)
ID: 10127
Operating Systems: Keines / None,
Typ: Information
NCP Secure Enterprise Client 8.10
NCP Secure Enterprise CE Client 2.0x
NCP Secure Entry Client 8.12

Some important things to be sure of before starting:

1). the NCP Client (or derivative thereof, also referred to as NCP Client in this document) cannot co-exist with another VPN Client, so it is imperative that other VPN clients have been removed before proceeding. You will be able to use the NCP VPN Client to establish connections to many other VPN Gateways, and are by no means locked down to only using specific vendor's VPN gateways.

In the case of the integrated VPN functionality of the PocketPC operating system, this is not to be activated, seeing as it cannot be removed.

2). in this scenario, the NCP Client will emulate a Cisco Unity Client, so you do not need to enable special "Movian" options- some users had this enabled, thinking it would be necessary in order to let the NCP CE Client function seeing it too is a PDA VPN client. The NCP Client strictly uses IPsec standards and drafts; such as XAUTH, IKE-ConfigMode and NAT-T, and so there is no need to enable options specifically for the Movian, some of which are not even supported, such as Diffie-Hellman Group 7.

3). The NCP client does NOT support the TCP encapsulation with a static/variable port number. The Cisco MUST BE configured to support NAT-T (IPSec over NAT-T). This requires configuration on the server side. This 'mode' works in parallel with existing configurations (does not influence existing connections) using TCP-encapsulation and is a standard defined by Cisco to replace the TCP encapsulation. The newer versions of the clients (v2.2x onwards) do support variable UDP (default:10000) encapsulation though. (see important note below)

Cisco 3000: Configuration | System | Tunneling Protocols | IPSec | NAT Transparency
Enable the IPSec over NAT-T.
See for more information:
http://www.cisco.com/univercd/cc/td/doc/product/vpn/vpn3000/4_0/config/tunnel.htm#1029463

Cisco PIX: isakmp nat-traversal [natkeepalive]
See for more information:
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/gl.htm#wp1027312

IMPORTANT NOTE: It may occur that the connection is succesfully negotiated, but no traffic is passing through the tunnel; that is to say; the symbols all indicate that a connection has been established, but the Rx (receive) counter remains on 0. Upon inspecting the log, you will see that NAT-T is supported but has not been negotiated, because no NAT devices were detected between the concentrator and the client. However, the Cisco will still expect the packets to be encapsulated within UDP(default:10000), and therefore not respond. This is automatically negotiated with the v2.2x and newer clients; and will adapt to the UDP port set on the Cisco. If
however a connection is used where NAT devices are detected, the frames will be encapsulated within UDP4500, which then will work.

Configuration:
For some tips in how to configure a connection to the ISP using a PDA please refer to http://www.ncp.de/english/services/cekompat/

IPSec General Settings:
you may want to define both the IKE and IPsec policies and lifetimes manually, but using Automatic Mode will normally work fine. If you do choose to manually define them; make sure these match the configuration as defined in the Cisco. Please note, the Automatic Mode will NOT negotiate proposals using DES, seeing as this is not considered secure. AES is a suitable replacement, as it is faster and more secure.
Exchange Mode: Depending on whether you are using pre-shared keys or certificates you want to select either:
Pre-shared keys (PSK): select Aggressive Mode or
X509 Certificates (RSA): select Main Mode.

NOTE: Please also select the correct DH-Group for the PFS (Perfect Forward Secrecy).

Identities:
When using Pre-shared keys: select Free string used to identify groups as (IKE-)Type and enter in the group name as the (IKE-)ID. Enable the use of Pre-shared keys, and enter in the group password there.

When using certificates: select ASN1 Distinguished name, as (IKE-)Type and then the information will be extracted from the certificate. Remember also to define which certificates are to be used (and in the case of PDAs, upload the certificates to the PDA)!

Also enable the use of XAUTH, and enter in the XAUTH username and password.

IP Address Assignment:
The NCP client supports Cisco's IKE-Config Mode, which you'll want to enable as well, this saves a lot of trouble configuring IP addresses that the client is going to use.

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.

NCP Support / Questions Forum

dimante — Sun, 11 Nov 2007 06:09:38 -0600

Post any issues with NCP Secure VPN Client software here! We can help you with setup, configuration, and general questions.