[Openswan Users] A working example of use of X.509 certificates, Linux -- Windows XP

[Miguel Dilaj]

Hi all,

Usually I can't contribute too much, asking a lot and providing no
solutions, so after getting a VPN with Linux and WinXP working here I
decided to share my little experience.

Setup:
This is not a "typical" one, both the VPN box and the roadwarriors are in
the same public subnet (don't ask... I told you it's strange), and the 2nd
interface of the VPN box is connected to a private subnet.
Graphically:

Roadwarrior ===== VPN box ===== private subnet
a.a.a.a/aa        a.a.a.a/aa    b.b.b.b/bb
                  b.b.b.b/bb

The VPN box is running Debian testing, kernel 2.6.11-1-686, OpenSWAN 2.3.0-2
Debian package. Because it's a 2.6 kernel you don't need the
kernel-patch-openswan Debian package.
The roadwarriors are WinXP Pro SP2 machines using Safenet 8.x (old one,
latest is 10.x or 11.x).
NOTE: the XP firewall sometimes blocks traffic to the VPN box, even when all
traffic is allowed. This behaviour is not consistent (as usual with M$
products), so I'm not able to identify the reason, I just deactivated the
crap firewall of XP on the roadwarriors.

I created our own CA using openssl and the procedure described in millions
of websites out there. Then I created sepparate certificates for each user
and signed them using our CA.
NOTE: certificates/CA created TODAY are rejected by Windows. If you create
your certificate/CA today, use it tomorrow, otherwise change the time of the
machine in which you're using openssl to generate the certificates/CA with
yesterday's date. Annoying, isn't it?

The configuration of the VPN box is as follows (/etc/ipsec.conf):

# /etc/ipsec.conf - Openswan IPsec configuration file
# RCSID $Id: ipsec.conf.in,v 1.13 2004/03/24 04:14:39 ken Exp $

# This file:  /usr/share/doc/openswan/ipsec.conf-sample
#
# Manual:     ipsec.conf.5

version 2.0     # conforms to second version of ipsec.conf specification

config setup
    interfaces="ipsec0=eth0"
    nat_traversal=yes
    forwardcontrol=yes
    uniqueids=yes
#    virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16

conn %default
    keyingtries=3
    compress=no
    disablearrivalcheck=no
    authby=rsasig
    leftrsasigkey=%cert
    rightrsasigkey=%cert

conn roadwarrior
    left={_IP of the VPN box on the external interface_}
    leftcert={_filename of the VPN server certificate_}
    leftid={_distinguished name of the server, as stated in the certificate,
see note 1 below_}
    leftsubnet=0.0.0.0/0
    leftupdown=/etc/ipsec.d/ipsec.masquerade
    right=%any
    rightid={_distinguished name of the roadwarriors, as stated in their
certificates, see note 2 below_}
    auto=add
    pfs=yes

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


NOTE 1: the distinguished name of the certificate of the server looks like
"C={country}, ST={state}, L={city}, O={organization}, OU={department},
CN={email I used in the server's certificate}"

NOTE 2: the distinguished name of the certificates of the roadwarriors looks
like "C={country}, ST={state}, L={city}, O={organization}, OU={department},
CN=*"
The * in the last field does the magic, this is the only portion that
changes for each roadwarrior.

I'm not sure if the line
	interfaces="ipsec0=eth0"
is required, but it works...

The line
	#
virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16
is actually commented because both the roadwarriors and the server are in
the same subnet. Further testing soon, that will include a roadwarrior using
a private IP address from the home internal network...

The line
	    leftupdown=/etc/ipsec.d/ipsec.masquerade
is executing a simple iptables script that does the masquerading from
network A to network B.


My /etc/ipsec.secrets looks like:

# RCSID $Id: ipsec.secrets.proto,v 1.2 2004/03/13 17:13:47 rene Exp $
# This file holds shared secrets or RSA private keys for inter-Pluto
# authentication.  See ipsec_pluto(8) manpage, and HTML documentation.

# RSA private key for this host, authenticating it to any other host
# which knows the public part.  Suitable public keys, for ipsec.conf, DNS,
# or configuration of other implementations, can be extracted conveniently
# with "ipsec showhostkey".

: RSA {_filename of the VPN server private key_} "{_very secret password
here!_}"


The configuration of Safenet in the XP clients is as follows:

1) I used the Certificate Manager provided to import the roadwarrior
certificate and the CA certificate.

2) I created a Secure connection with the following details:

	Connection security: Secure
	Remote Party Identity and Addressing:
		ID Type: IP Address range
		From: 0.0.0.0
		To: 255.255.255.255
		Port: all
		Protocol: all
		Connect using: Secure Gateway Tunnel
		ID Type: Distinguished name
			Name: {_email address as used in the server
certificate distinguished name_}
			Department: {_department, as above_}
			Company: {_organization, as above_}
			City: {_city, as above_}
			State: {_state, as above_}
			Postal code: {_EMPTY_}
			Country: {_country, as above_}
			Email address: {_EMPTY_}
		Gateway IP Address: {_external IP address of the VPN
server_}

	My Identity: {_select the roadwarrior certificate_}
	ID Type: Distinguished name (the information will be automatically
completed from the certificate)
	Virtual adapter: Disabled
	Internal network IP address: 0.0.0.0
	Internet Interface: {_select the proper interface if the roadwarrior
has more than one_}
		The IP address will be completed automatically from the one
in use by the interface above

	Security Policy
	Phase 1 negotiation mode: Main mode
	Enable PFS
	Use DH group 2
	Enable replay detection

	Authentication (phase 1) proposal
	Authentication method: RSA signatures
	Encryption: 3DES
	Hash: MD5
	SA life: whatever you like, I use 18000 seconds
	Key group: DH group 2

	Key exchange (phase 2) proposal
	SA life: whatever you like, I use 18000 seconds
	Compression: none
	Enable ESP
		Encryption: 3DES
		Hash: MD5
		Encapsulation: tunnel
	Disable AH


That's it... The setup above works. I can be further tweaked, I'm sure.
I hope it's of help for someone.
Cheers,

Miguel






***********************************************************************************************************
DISCLAIMER:                                                                                                
This e-mail contains proprietary information, some or all of which may be legally privileged.              
It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, 
please notify the author by replying to this e-mail. If you are not the intended recipient you may not use,
disclose, distribute, copy, print or rely on this e-mail.                                                  
***********************************************************************************************************