[Openswan Users] Ike Mode Config and virtual IP

Andreas Steffen andreas.steffen at strongsec.net
Wed Feb 8 19:14:27 CET 2006


strongSwan's configuration setup for an IKE Mode Config server is
quite different from Openswan's.

Here is an example taken from

   http://www.strongswan.org/uml/testresults/mode-config/

------------------------------------------------------------------------
# /etc/ipsec.conf - strongSwan IPsec configuration file

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

config setup
	crlcheckinterval=180
	strictcrlpolicy=no

conn %default
	left=192.168.0.1
	leftsubnet=10.1.0.0/16
	leftsourceip=10.1.0.1
	leftnexthop=%direct
	leftcert=moonCert.pem
	leftid=@moon.strongswan.org
	leftupdown=/etc/ipsec.updown

conn rw-carol
	right=%any
	rightid=carol at strongswan.org
	rightsourceip=10.3.0.1         # virtual IP reserved for carol
	auto=add

conn rw-dave
	right=%any
	rightid=dave at strongswan.org
	rightsourceip=10.3.0.2         # virtual IP reserved for dave
	auto=add

------------------------------------------------------------------------

Relevant excerpt from the log:

    ...
: "rw-dave"[2] 192.168.0.200 #3: Peer ID is ID_USER_FQDN: 
'dave at strongswan.org'
: "rw-dave"[2] 192.168.0.200 #3: we have a cert and are sending it
: "rw-dave"[2] 192.168.0.200 #3: sent MR3, ISAKMP SA established
: "rw-dave"[2] 192.168.0.200 #3: modecfg_inR0 ok
: "rw-dave"[2] 192.168.0.200 #3: sent ModeCfg reply
: "rw-dave"[2] 192.168.0.200 #4: responding to Quick Mode
    ...

With strongSwan

    right|leftsourceip=x.x.x.x automatically implies
    right|leftsubnet=x.x.x.x/32 if subnet is not defined

whereas Openswan requires an explicit subnet definition.

Regards

Andreas
Marco Berizzi wrote:
> 
> Andreas Steffen wrote:
> 
>> The NCP Secure Entry Client works perfectly with
>> strongSswan as IKE Mode Config server.
>>
>>  http://www.ncp.de/english/home/index.html
> 
> 
> Hi Andreas,
> thanks for the reply. I did try NCP: it's working with
> strongSswan ;-))
> Just for record: the same ipsec.conf with OSW 2.4.5rc4
> doesn't work with NCP. Here is ipsec.conf and log:
> 
> conn IMCFG
>        left=%any
>        leftid=10.1.2.1
>        leftsourceip=172.31.254.55
>        right=10.1.2.10
>        rightid=10.1.2.10
>        rightsubnet=172.16.1.0/24
>        authby=secret
>        auto=add
>        pfs=yes
>        compress=yes
>        leftrsasigkey=none
>        rightrsasigkey=none
>        keyingtries=0
>        rightupdown=/usr/local/lib/ipsec/_updown_x509
> 
> Feb  8 11:36:58 Calimero pluto[7788]: packet from 10.1.2.1:500: ignoring 
> unknown Vendor ID payload [da8e937880010000]
> Feb  8 11:36:58 Calimero pluto[7788]: packet from 10.1.2.1:500: received 
> Vendor ID payload [XAUTH]
> Feb  8 11:36:58 Calimero pluto[7788]: packet from 10.1.2.1:500: received 
> Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but port 
> floating is off
> Feb  8 11:36:58 Calimero pluto[7788]: packet from 10.1.2.1:500: received 
> Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but port 
> floating is off
> Feb  8 11:36:58 Calimero pluto[7788]: packet from 10.1.2.1:500: ignoring 
> Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
> Feb  8 11:36:58 Calimero pluto[7788]: packet from 10.1.2.1:500: received 
> Vendor ID payload [RFC 3947] meth=109, but port floating is off
> Feb  8 11:36:58 Calimero pluto[7788]: packet from 10.1.2.1:500: received 
> Vendor ID payload [Dead Peer Detection]
> Feb  8 11:36:58 Calimero pluto[7788]: packet from 10.1.2.1:500: ignoring 
> unknown Vendor ID payload [eb4c1b788afd4a9cb7730a68d56d088b]
> Feb  8 11:36:58 Calimero pluto[7788]: packet from 10.1.2.1:500: received 
> Vendor ID payload [Cisco-Unity]
> Feb  8 11:36:58 Calimero pluto[7788]: "IMCFG"[1] 10.1.2.1 #1: responding 
> to Main Mode from unknown peer 10.1.2.1
> Feb  8 11:36:58 Calimero pluto[7788]: "IMCFG"[1] 10.1.2.1 #1: transition 
> from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Feb  8 11:36:58 Calimero pluto[7788]: "IMCFG"[1] 10.1.2.1 #1: 
> STATE_MAIN_R1: sent MR1, expecting MI2
> Feb  8 11:36:59 Calimero pluto[7788]: "IMCFG"[1] 10.1.2.1 #1: transition 
> from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Feb  8 11:36:59 Calimero pluto[7788]: "IMCFG"[1] 10.1.2.1 #1: 
> STATE_MAIN_R2: sent MR2, expecting MI3
> Feb  8 11:36:59 Calimero pluto[7788]: "IMCFG"[1] 10.1.2.1 #1: ignoring 
> informational payload, type IPSEC_INITIAL_CONTACT
> Feb  8 11:36:59 Calimero pluto[7788]: "IMCFG"[1] 10.1.2.1 #1: Main mode 
> peer ID is ID_IPV4_ADDR: '10.1.2.1'
> Feb  8 11:36:59 Calimero pluto[7788]: "IMCFG"[1] 10.1.2.1 #1: I did not 
> send a certificate because I do not have one.
> Feb  8 11:36:59 Calimero pluto[7788]: "IMCFG"[1] 10.1.2.1 #1: transition 
> from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Feb  8 11:36:59 Calimero pluto[7788]: "IMCFG"[1] 10.1.2.1 #1: 
> STATE_MAIN_R3: sent MR3, ISAKMP SA established 
> {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5 
> group=modp1024}
> Feb  8 11:36:59 Calimero pluto[7788]: "IMCFG"[1] 10.1.2.1 #1: received 
> MODECFG message when in state STATE_MAIN_R3, and we aren't xauth client
> Feb  8 11:37:08 Calimero last message repeated 3 times
> Feb  8 11:37:11 Calimero pluto[7788]: "IMCFG"[1] 10.1.2.1 #1: received 
> Delete SA payload: deleting ISAKMP State #1
> Feb  8 11:37:11 Calimero pluto[7788]: "IMCFG"[1] 10.1.2.1: deleting 
> connection "IMCFG" instance with peer 10.1.2.1 {isakmp=#0/ipsec=#0}
> Feb  8 11:37:11 Calimero pluto[7788]: packet from 10.1.2.1:500: received 
> and ignored informational message

=======================================================================
Andreas Steffen                   e-mail: andreas.steffen at strongsec.com
strongSec GmbH                    home:   http://www.strongsec.com
Alter Zürichweg 20                phone:  +41 1 730 80 64
CH-8952 Schlieren (Switzerland)   fax:    +41 1 730 80 65
==========================================[strong internet security]===


More information about the Users mailing list