TESTING:

1) we have adapted the code such that openswan 2.x can operate
   as both a client and a server.

2) we have made the client and server components interoperate with
   each other.

3) we have interoperated the server components with SafeNet and SSH
   Sentinel.

4) we have interoperated the client components with a Cisco VPN3K system.
   (note: this system does not run IOS. IOS code could be different)

All tests were done with static configurations - i.e. we did not configure
the inner IP address or policy with Mode-Configuration. 

There are some limitations at present, whic are beyond our control.

Openswan 2.x (as of 2.3.x) supports aggressive mode, using aggrmode=yes
Special code has been written to avoid a trivial distributed denial
of service attack on Aggressive Mode to take down the rest of the
non-aggressive mode tunnels with it, by offloading the aggressive mode
crypto work into crypto helpers, which can be limitted in resource
consumption and take a lower priority then other crypto operations.
It is still strongly recommended to avoid using aggressive mode whenever
possible.




Due to a design limitation of main made, when using pre-shared keys, 
(aka "group passwords") one may have only one group password (the default
one), or one must configure a group password by IP address. 

Clearly, for a road warrior, limiting them to one IP address is not very
useful.

There seems to be, however, a limitation in the Cisco VPN3K (with 4.0-April
2003 code) such that the default group may not contain any users. We are
in contact with Cisco about this limitation, but so far, we have not received
a clear answer. It is possible that this is fixed in the 4.04 code, which
we have not yet received.

If one were to use RSA keys, no limitation would occur.

When interoperating Openswan clients with an Openswan server, we recommend
use of RSA keys (stored in DNS) for phase 1 authentcation, with
username/password in XAUTH to "upgrade" the connection from Opportunistic
Encryption, to VPN-Road-Warrior. We will be documenting this mode of
operation soon. 

Configuration of the XAUTH client for group-pre-shared-key is simple: the
"group" key goes into /etc/ipsec.secrets like:

	@groupname    1.2.3.4 : PSK "grouppass"

(where 1.2.3.4 is the IP address of the "VPN concentrator")

One then add a connection like:

    conn myclient
	 left=%defaultroute
	 leftid=@groupname
	 leftxauthclient=yes
	 right=1.2.3.4
	 rightsubnet=192.168.1.0/24	 # corporate private network
	 rightxauthserver=yes
	 authby=secret
	 auto=add

  and does:

      ipsec auto --up myclient

  the user will then be prompted for username/password.

uml2:/etc# ipsec auto --up jacen--ipsecgroup-xauth 
104 "jacen--ipsecgroup-xauth" #1: STATE_MAIN_I1: initiate
003 "jacen--ipsecgroup-xauth" #1: ignoring Vendor ID payload [4048b7d56ebce885...]
106 "jacen--ipsecgroup-xauth" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "jacen--ipsecgroup-xauth" #1: ignoring Vendor ID payload [Cisco-Unity]
003 "jacen--ipsecgroup-xauth" #1: received Vendor ID payload [XAUTH]
003 "jacen--ipsecgroup-xauth" #1: ignoring Vendor ID payload [f6b0b8b25776ba99...]
003 "jacen--ipsecgroup-xauth" #1: ignoring Vendor ID payload [1f07f70eaa6514d3...]
108 "jacen--ipsecgroup-xauth" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "jacen--ipsecgroup-xauth" #1: STATE_MAIN_I4: ISAKMP SA established
003 "jacen--ipsecgroup-xauth" #1: XAUTH-Message: Enter Username and Password.
041 "jacen--ipsecgroup-xauth" #1: jacen--ipsecgroup-xauth prompt for Username:
Name enter:   testuser
040 "jacen--ipsecgroup-xauth" #1: jacen--ipsecgroup-xauth prompt for Password:
Secret enter: 


  Alternately, one may avoid the prompt, by calling whack directly,
with additional arguments:
   ipsec whack  --name jacen--ipsecgroup-xauth --xauthname testuser --xauthpass testuser --initiate

  We expect to have a version of "ipsec whack" that can be made setuid root,
such that it can be invoked safely from a GUI, that will prompt at the
appropriate times, and listen for results from the GUI. We do not have a
timeframe for this work.