[Openswan Users] Openswan as modecfgserver?

[Freeman Wang]

It seems I can not make openswan to work with clients as a MODECFG
server. Is it supposed to work?
 
The client is an openswan instance too. The client configuration is set
to be both xauthclient and modecfgclient and the server side to be
xauthserver and modecfgserver. XAUTH passed successfully and both server
and client happily moved to next phase. The client log file shows
 

	"net-to-road-xauth" #1: XAUTH: Successfully Authenticated
	! complete state transition with STF_OK
	"net-to-road-xauth" #1: transition from state STATE_XAUTH_I0 to
state STATE_XAUTH_I1
	...
	"net-to-road-xauth" #1: STATE_XAUTH_I1: XAUTH client - awaiting
CFG_SET
	modecfg pull: noquirk policy: pull modecfg-client 
	modecfg client is starting due to policy
	"net-to-road-xauth" #1: modecfg: Sending IP request (MODECFG_I1)
	...
	state object #1 found, in STATE_MODE_CFG_I1
	processing connection net-to-road-xauth
	"net-to-road-xauth" #1: Mode Config message is unacceptable
because it is for an incomplete ISAKMP SA ( state STATE_MODE_CFG_I1)

 
And the server side log file shows
 

	"road-warrior-host"[1] 192.168.2.66 #1: XAUTH: User test3:
Authentication Succes
	sful
	...
	"road-warrior-host"[1] 192.168.2.66 #1: XAUTH:
xauth_inR1(STF_OK)
	| complete state transition with STF_OK
	"road-warrior-host"[1] 192.168.2.66 #1: transition from state
STATE_XAUTH_R1 to
	state STATE_MAIN_R3
	| deleting event for #1
	| inserting event EVENT_SA_REPLACE, timeout in 3330 seconds for
#1
	| event added after event EVENT_REINIT_SECRET
	"road-warrior-host"[1] 192.168.2.66 #1: STATE_MAIN_R3: sent MR3,
ISAKMP SA estab
	lished
	| modecfg pull: noquirk policy:push not-client
	| processing connection road-warrior-host[1] 192.168.2.66
	"road-warrior-host"[1] 192.168.2.66 #1: Sending MODE CONFIG set
	...
	| ****emit ISAKMP ModeCfg attribute:
	|    ModeCfg attr type: INTERNAL_IP4_ADDRESS
	| emitting 4 raw bytes of IP4_addr into ISAKMP ModeCfg attribute
	| IP4_addr  c0 a8 02 42
	| emitting length of ISAKMP ModeCfg attribute: 4
	| ****emit ISAKMP ModeCfg attribute:
	|    ModeCfg attr type: INTERNAL_IP4_SUBNET
	| emitting 4 raw bytes of IP4_subnet into ISAKMP ModeCfg
attribute
	| IP4_subnet  c0 a8 00 00
	| emitting 4 raw bytes of IP4_submsk into ISAKMP ModeCfg
attribute
	| IP4_submsk  ff ff ff 00
	| emitting length of ISAKMP ModeCfg attribute: 8
	| emitting length of ISAKMP Mode Attribute: 28
	...
	| state hash entry 25
	| peer and cookies match on #1, provided msgid cd7e8fcd vs
00000000/7dfadb20
	| p15 state object not found
	| ICOOKIE:  56 be 47 76  79 60 bb d9
	| RCOOKIE:  4b c8 b1 eb  91 3f 3a 12
	| state hash entry 25
	| peer and cookies match on #1, provided msgid 00000000 vs
00000000/7dfadb20
	| p15 state object #1 found, in STATE_MODE_CFG_R1
	| processing connection road-warrior-host[1] 192.168.2.66
	| last Phase 1 IV:  d8 3b 77 2d  d6 49 fe 81
	| current Phase 1 IV:  e4 46 51 94  73 5e 2b 22
	| computed Phase 2 IV:
	|   13 5b bf cc  e6 30 7a 93  a5 69 37 61  1c 1d 10 1b
	"road-warrior-host"[1] 192.168.2.66 #1: received MODECFG message
when in state S
	TATE_MODE_CFG_R1, and we aren't xauth client
	| * processed 0 messages from cryptographic helpers
	 

A couple of questions:
 
1. Why the server tried to push IP settings? Shouldn't it wait for the
client to pull? What if the client side does not have modecfg set? How
can I stop that from happening on the server side?
2. Why the internal IP4 address the server tried to push is the public
IP address of the remote peer instead of an 'internal' one?
3. Does openswan support the idea of virtual adaptor? I thought the
remote must be in a different subnet, but modecfg seems to allow the
remote to join the local network.
4. I couldn't find anything from the document about how to fine control
what is pushed to the client. Can I only push DNS stuff and avoid
passing IP settings?
5. What kind of changes I need to do to make modecfg to work with two
openswan boxes?
 
Thanks a lot
Freeman
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090908/12ce1dab/attachment.html