11100000
10000000
11111011
11110000
11011110 

/*
______________
Date:
        2006-12-01

______________
Author:
        Anna Wiejak
        anias@popoludnica.pl


______________
Buzzwords:
	
	softremote, safenet, ikecfg, modecfg, mode config, road-warrior,
openswan, dns, wins

______________
Description:

	This is a workaround for openswan server, fixing the modeconfig issue
for softremote clients. 

______________
References:
http://www.safenet-inc.com/products/vpn/softRemote.asp
http://www.openswan.org/
http://www.openswan.org/docs/local/ietf-drafts/draft-dukes-ike-mode-cfg-02.txt
http://www.ietf.org/rfc/rfc2409.txt
http://www.ietf.org/rfc/rfc2408.txt

*/





1) Introduction

Safenet SoftRemote is a windows based client for remote vpn users. Basically it
is able to operate with openswan server, but any attempts to use the
mode-config feature were unsuccesfull, despite the fact both SoftRemote and
Safenet conform to the same draft-dukes-ike-mode-cfg-02.  Modeconfig support
would be more then desired, as this:

* allows to have unified configuration for each of the clients
* is the only way (at least for all >10.x versions) to set the internal network
  DNS and WINS addresses on a softremote road-warrior client machine 

The SoftRemote support wasn't very helpful - after an extensive email
conversation they requested to buy a support agreement from a local distributor
for all the licenses, without a time-range and warranty they would be able to
fix the problem.

I decided to spend no more then a week and make an attempt to locate and fix
the problem on my own.


2) Some interesting details

It turned out to be an encryption problem of mode config payloads (thanks to
awesome windows disassemblers/debuggers and openswan extensive debug output).

The draft-dukes-ike-mode-cfg-02 specifies that a mode config transaction takes
place "once the ISAKMP security association has been established" and "the
derivation of the initialization vector IV for the first message, used with
SKEYID_e to encrypt the message" is described in Appendix B of RFC2049. 
However it's still not clear whether the IV vector should be generated as for 
Phase1 or Phase2, as the mode config exchange takes place between the two.  
Openswan decides to use Phase1 initialization vector IV, SoftRemote uses Phase2
initialization vector IV, which is the cause of confusion and cause "malformed
packet" messages in SoftRemote logs, when openswan attempts to send MODECFG SET
packets.

Only the openswan server modeconfig payload encryption was fixed. If you start
to use it - be warned that modeconfig server may no longer be compatible with
openswan modeconfig client!

When the initialization vector issue was fixed, SoftRemote started to parse
modeconfig packets properly. But the latter conversation was still failing -
because of silent abandoning the already initiated IPsec SA conversation by
SoftRemote (after the virtual interface with the new IP address was up).
SoftRemote attempted to start a new IPsec SA conversation, what wasn't properly
handled on the server side. 
The quick workaround was done stopping openswan from accepting Quick Mode 
messages util the mode config conversation is not finished. 
There may be a better solution - the suggested one unfortunately can
cause a problem, when the configuration forces the server to send mode config
packet, but these are silently discarded by the client. Then the IPsec
conversation would never success, because the mode config transaction would
never reach STATE_MODE_CFG_R1.
 
Also four parameters were added for openswan to allow setting two DNS server
and two WINS servers for the connection:

* modecfgdns1
* modecfgdns2
* modecfgwins1
* modecfgwins2

The mode config implementation on openswan should use a PAM module to assign
IP/DNS/WINS IP addresses. I prefer not to, so the above change was required. I
keep separate entries for each user in the ipsec.conf file, what allows me to
set the specific IP address for each user:

conn rw_usernnn
        leftid=""
        also=road_warrior 
        leftsubnet=


3) The fix

The fix can be implemented both on SoftRemote client and Openswan server.  
I decided to publish only the Openswan fix, as the SoftRemote binary patch in
version sensitive and Openswan source patch is easier to understand.

What the openswan fix does is:

* set the Phase2 initialization vector IV for modeconfig conversation instead
  of using Phase1 vector, workaround of a problem with double QUICK MODE
* conversations (described above),
* introduction of four new parameters
 
4) How to benefit

* patch the openswan source (version 2.4.7) with the openswan_modeconfig-2.4.7.patch
* build and install openswan with MODECFG=true feature compiled in
* add the following parameters for the connection(s) which will use modeconfig:

        modecfgclient=yes
        modecfgserver=yes
        modecfgdns1=xxx.xxx.xxx.xxx
        modecfgwins1=xxx.xxx.xxx.xxx

* configure softremote to use the virtual adapter (preferred or required)
* start the connection and observe the logs.
A