[Openswan Users] Multiple RoadWarrior Connection TYPES

Wed Jan 5 18:26:33 EST 2011

An update on where I'm at with this conundrum:

Using a static IP for the XAUTH client allows Openswan to differentiate between L2TP (below the XAUTH conn, but using "right=%any") and XAUTH clients. I was able then to connect L2TP (on data network IPs) and XAUTH (most of the way... still some problems) with neither connection commented out.

However, that does not help the situation much. It only confirms my earlier stance that Openswan is not applying the entirety of the connection configuration before committing to a pass/fail state, rather than attempting other viable connections instead.

As for the problems with XAUTH, I swapped a Nokia for an iOS device using Cisco IPSec (XAUTH) and it passed the htpasswd step I was stuck on with the Nokia. However it too eventually failed. This pluto log is using the same ipsec.conf listed earlier but with the rightid=Z.Z.Z.Z instead of @NOKIA:

--setup--

XAUTH-PSK-NAT - responding to Main Mode from unknown peer Y.Y.Y.Y
XAUTH-PSK-NAT - transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
XAUTH-PSK-NAT - STATE_MAIN_R1: sent MR1, expecting MI2
XAUTH-PSK-NAT - NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): peer is NATed
XAUTH-PSK-NAT - transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
XAUTH-PSK-NAT - STATE_MAIN_R2: sent MR2, expecting MI3
XAUTH-PSK-NAT - ignoring informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000
XAUTH-PSK-NAT - Main mode peer ID is ID_IPV4_ADDR: 'Z.Z.Z.Z'
XAUTH-PSK-NAT - transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
XAUTH-PSK-NAT - new NAT mapping for #1, was Y.Y.Y.Y:98, now Y.Y.Y.Y.47408
XAUTH-PSK-NAT - STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}
XAUTH-PSK-NAT - Dead Peer Detection (RFC 3706): enabled
XAUTH-PSK-NAT - XAUTH: Sending XAUTH Login/Password Request
XAUTH-PSK-NAT - XAUTH: Sending XAUTH Username/Password request (XAUTH_R0)
XAUTH-PSK-NAT - XAUTH: User dude: Attempting to login
XAUTH-PSK-NAT - XAUTH: md5 authentication being called to authenticate user dude
XAUTH-PSK-NAT - XAUTH: password file (/etc/ipsec.d/passwd) open.
XAUTH-PSK-NAT - XAUTH: checking user(dude:XAUTH-PSK-NAT)
XAUTH-PSK-NAT - XAUTH: User dude: Authentication Successful
XAUTH-PSK-NAT - XAUTH: xauth_inR1(STF_OK)
XAUTH-PSK-NAT - transition from state STATE_XAUTH_R1 to state STATE_MAIN_R3
XAUTH-PSK-NAT - STATE_MAIN_R3 sent MR3, ISAMP SA established
XAUTH-PSK-NAT - Dead Peer Detection (RFC 3706): enabled
XAUTH-PSK-NAT - Sending MODE CONFIG set
XAUTH-PSK-NAT - received MODECFG message when in state STATE_MODE_CFG_R1, and we aren't xauth client

-- last message repeated 9 times

XAUTH-PSK-NAT - received Delete SA payload: deleting ISAKMP State #1

--etc--

This sounds like an isolated problem...?

A final thought in regards to determining the difference between connection types: do you think that use of certificates would remedy the issue? I figure that XAUTH certificates would be presented in a different way, making it easier for Openswan to determine the type of connection when in my XAUTH conn "right=%any"

I've been stuck on this problem for weeks. Any ideas would be great.

Thanks.

On Dec 15, 2010, at 6:20 PM, Richard Schmidt wrote:

> Greetings.
> 
> SHORT VERSION:
> 
> The 2 conns below are for Nokia devices (using XAUTH) and L2TP devices. Given the conn's, why are my L2TP devices associating with the XAUTH (other than the XAUTH section is typed above L2TP section in the ipsec.conf), and how do I differentiate them? "rightid=> seems to have no effect.
> 
> Does Openswan perform the xauthserver and modecfg or is there another service (similar to xl2tpd and pppd for L2TP) that needs to perform that interaction?
> 
> LONG VERSION:
> 
> I've been crawling the mailing list for some time (using Google) trying to figure out how to accomplish the following:
> 
> Clients on mobile data networks that want to VPN into the company network are using different mobile devices with different VPN methods. Most models support L2TP/IPSec with PSK or certificates. Right now I'm configuring the servers to use PSK until I can get all the devices online. Currently I've achieved connectivity on most/all devices using L2TP/IPSec with a PSK. However, a few customers handle Nokia S60's and upward. My question pertains to maintaining the L2TP/IPSec connectivity while also bringing the Nokia's online as well.
> 
> My L2TP conn (I have verified this works with L2TP/IPSec devices):
> 
> -------------------------------------------
> conn L2TP-PSK-NAT
> 	rightsubnet=vhost:%priv
> 	also=L2TP-PSK-noNAT
> 
> conn L2TP-PSK-noNAT
> 	authby=secret
> 	pfs=no
> 	auto=add
> 
> 	keyingtries=3
> 	rekey=no
> 	ikelifetime=8h
> 	keylife=1h
> 
> 	type=transport
> 
> 	dpddelay=40
> 	dpdtimeout=130
> 	dpdaction=clear
> 
> 	left=X.X.X.X
> 	leftprotoport=17/1701
> 
> 	right=%any
> 	rightprotoport=17/%any
> 
> -------------------------------------------
> 
> Nokia's are different in that they only support IPSec via XAUTH. Thus I've written a different conn for them, distinguishing Nokia phones from others by using the right ID "NOKIA" in the Nokia VPN policy.
> 
> The XAUTH conn (I have been unable to get Nokia's online using this conn... something to do with not using ipsec.secrets OR ipsec.d/passwd and possibly using htpasswd incorrectly):
> 
> -------------------------------------------
> conn XAUTH-PSK-NAT
> 	rightsubnet=vhost:%priv
> 	#rightid=@NOKIA			# I've also tried putting the rightid here to no effect.
> 	also=XAUTH-PSK-noNAT
> 
> conn XAUTH-PSK-noNAT
> 	authby=secret
> 	pfs=no
> 	auto=add
> 
> 	keyingtries=3
> 	rekey=no
> 	ikelifetime=8h
> 	keylife=1h
> 	
> 	leftxauthserver=yes
> 	leftmodecfgserver=yes
> 	
> 	type=tunnel
> 
> 	dpddelay=40
> 	dpdtimeout=130
> 	dpdaction=clear
> 
> 	left=X.X.X.X
> 
> 	right=%any
> 	rightid=@NOKIA
> 	
> 	rightxauthclient=yes
> 	rightmodecfgclient=yes
> 
> -------------------------------------------
> 
> My problems are many: first, even though I've identified the XAUTH tunnels as using <rightid=@NOKIA>, my regular L2TP devices are failing when the XAUTH conns are uncommented. Pluto reports "policy mandates Extended Authentication (XAUTH) with PSK of initiator (we are responder)." 
> 
> Cut/Paste-ing the XAUTH section below the L2TP section allows L2TP connection, but then I get the reverse problem for the Nokia's. Instead "policy mandates XAUTH" I get "policy does not allow XAUTH." 
> 
> I'm guessing that the step where rightid matters is unfortunately after Openswan has decided which conn section to use. However, I feel like if the connection presented doesn't match all of the criteria in the conn section, it should try the other conn's before failing. The fact that I have a working conn description below the non-working one is evidence Openswan is not doing that.
> 
> This means that even though my L2TP device is not providing a [rightid==@NOKIA], openswan is determining the connection to be of conn XAUTH-PSK-* (and vice-versa for Nokias when the L2TP conn is pasted above the XAUTH conn). How can I define the criteria for each connection so that Openswan will choose L2TP-PSK-* instead? Apparently setting rightid for one conn doesn't do the trick.
> 
> Second, it's obvious that I don't have a clue how to handle XAUTH authentications, but I think I can be helped a great deal if I knew whether or not that Openswan with XAUTH handles the xauthserver and modecfgserver, aka I don't need any other software running on the backend (like xl2tpd and ppd for the L2TP conn). This seems like a safe assumption since XAUTH is an extension for IPSec. The Nokias seem to be a battle on both ends as configuring the VPN policy needs to be done by hand and it seems (from reading online) that if the two don't agree on everything then nothing works.
> 
> Therefore I'm more concerned right now with the L2TP devices being judged under the XAUTH criteria for conn evaluation. But any help with the Nokias would be greatly appreciated.
> 
> Thank you.