[Openswan Users] OpenSWAN and iPhone IPSec only VPN
John A. Sullivan III
jsullivan at opensourcedevel.com
Sat May 5 22:57:44 EDT 2012
Hello, all. I've been beating my head against the wall for days trying
to get the built-in iPhone IPSec only (Cisco) client working with
OpenSWAN. We need to use the IPSec only approach rather than L2TP/IPSec
because we need to preserve the association between the certificate
fields and the IP address; we lose then when IPSec is only used to drop
off a PPP packet as with L2TP.
I'll try to summarize days of work and endless permutations as
succinctly as possible. We first tried PSK. According to the iOS
documentation, this requires XAUTH. I also apparently requires modecfg.
Among many variations, we used these OpenSWAN settings - we are
experimenting in our test lab so the "public" addresses are all RFC1918:
conn iPhone
leftxauthserver=yes
rightxauthclient=yes
rightmodecfgserver=yes
#leftxauthusername=phone
leftmodecfgserver=yes
#leftmodecfgclient=yes
ikev2=never
rekey=no
modecfgdns1=4.2.2.2
also=RWNAT
conn Android
rightprotoport=17/%any
leftprotoport=17/1701
leftsubnet=192.168.223.81/32
also=RWNAT
conn RWNAT
rightsubnet=vhost:%priv
also=RW
conn RW
right=%any
#rightsubnet=vhost:%no,%priv
#rightid=192.168.223.210
leftupdown=/etc/PEP/X509updown
authby=secret
#type=transport
#pfs=no
dpddelay=9
dpdtimeout=30
compress=no
keylife=1h
ikelifetime=3h
auto=add
conn %default
keyingtries=10
disablearrivalcheck=no
authby=rsasig
left=192.168.223.81
#leftnexthop=%direct
leftsubnet=192.168.15.0/24
leftrsasigkey=%cert
leftcert="testswitch01c.pem"
leftid="DC=com,DC=pacifera,OU=VPN,CN=testswitch01.pacifera.com"
rightrsasigkey=%cert
keylife=60m
rekeymargin=5m
ikelifetime=3h
auto=ignore
config setup
nat_traversal=yes
# exclude networks used on server side by adding %v4:!a.b.c.0/24
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%
v4:172.16.0.0/12,%v4:!192.168.15.0/24.%v4:!192.168.20.0/24,%v4:!
192.168.223.0/24
oe=off
protostack=netkey
plutowait=no
hidetos=no
# Close down old connection when new one using same ID shows up.
uniqueids=yes
The server key is 2048 bits, the cert contains the FQDN in the CN, and
the subjAltName contains both the FQDN and the IP address.
The iPhone is set up to access the gateway by IP address at
192.168.223.81 from 192.168.223.208. It uses a local user account one
the gateway to authenticate. XAUTH appears to succeed:
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: responding to Main Mode from unknown peer 192.168.223.208
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: STATE_MAIN_R1: sent MR1, expecting MI2
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): no NAT detected
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: STATE_MAIN_R2: sent MR2, expecting MI3
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: ignoring informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: Main mode peer ID is ID_IPV4_ADDR: '192.168.223.208'
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: new NAT mapping for #4, was 192.168.223.208:500, now 192.168.223.208:4500
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: Dead Peer Detection (RFC 3706): enabled
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: XAUTH: Sending XAUTH Login/Password Request
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: XAUTH: Sending Username/Password request (XAUTH_R0)
switch01 pluto[2821]: XAUTH: User myuser: Attempting to login
switch01 pluto[2821]: XAUTH: pam authentication being called to authenticate user myuser
switch01 pluto[2821]: XAUTH: User myuser: Authentication Successful
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: XAUTH: xauth_inR1(STF_OK)
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: transition from state STATE_XAUTH_R1 to state STATE_MAIN_R3
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: STATE_MAIN_R3: sent MR3, ISAKMP SA established
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: Dead Peer Detection (RFC 3706): enabled
That's when the trouble starts with modecfg. It is almost as if the
iPhone itself is trying to set parameters:
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: Sending MODE CONFIG set
switch01 pluto[2821]: pam_unix(pluto:session): session opened for user user by (uid=0)
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: received MODECFG message when in state STATE_MODE_CFG_R1, and we aren't xauth client
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: received MODECFG message when in state STATE_MODE_CFG_R1, and we aren't xauth client
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: received MODECFG message when in state STATE_MODE_CFG_R1, and we aren't xauth client
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: DPD: could not find newest phase 1 state
switch01 pluto[2821]: "iPhone"[1] 192.168.223.208 #4: received MODECFG message when in state STATE_MODE_CFG_R1, and we aren't xauth client
As you can see from some of the commented and uncommented connection
parameters above, I tried several approaches to resolve this. I tried
designating rightmodecfgserver=yes, rightmodecfgclient=yes and none of
those worked. I tried reversing it and making the gateway the client as
much as that seemed wrong. That had a different effect but was still a
failure. If I auto-started (not correct according to the man page), the
iPhone prompted me for a user and password for the connection. If I
tried to manually start the OpenSWAN connection with a username and
password, it complained that it needed to know the address of the other
side of the connection.
So no success with PSK. What do we need to do to get PSK IPSec working?
Actually our goal is to use certs. We tried that with XAUTH but had
even less success. In that case, the XAUTH communication appears to
break down. We commented out the above authby=secret, restarted
OpenSWAN, and deleted the Android connection. After enabling the cert
on the iPhone, we saw:
5 testswitch01 pluto[3475]: "iPhone"[1] 192.168.223.208 #4: responding to Main Mode from unknown peer 192.168.223.208
5 testswitch01 pluto[3475]: "iPhone"[1] 192.168.223.208 #4: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
5 testswitch01 pluto[3475]: "iPhone"[1] 192.168.223.208 #4: STATE_MAIN_R1: sent MR1, expecting MI2
5 testswitch01 pluto[3475]: "iPhone"[1] 192.168.223.208 #4: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): no NAT detected
5 testswitch01 pluto[3475]: "iPhone"[1] 192.168.223.208 #4: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
5 testswitch01 pluto[3475]: "iPhone"[1] 192.168.223.208 #4: STATE_MAIN_R2: sent MR2, expecting MI3
6 testswitch01 pluto[3475]: "iPhone"[1] 192.168.223.208 #4: ignoring informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000
6 testswitch01 pluto[3475]: "iPhone"[1] 192.168.223.208 #4: Main mode peer ID is ID_DER_ASN1_DN: 'DC=com, DC=pacifera, OU=Phone, CN=myphone'
6 testswitch01 pluto[3475]: "iPhone"[1] 192.168.223.208 #4: no crl from issuer "DC=com, DC=pacifera, OU=PKI, CN=TestCA" found (strict=no)
6 testswitch01 pluto[3475]: "iPhone"[1] 192.168.223.208 #4: switched from "iPhone" to "iPhone"
6 testswitch01 pluto[3475]: "iPhone"[2] 192.168.223.208 #4: deleting connection "iPhone" instance with peer 192.168.223.208 {isakmp=#0/ipsec=#0}
6 testswitch01 pluto[3475]: "iPhone"[2] 192.168.223.208 #4: I am sending my cert
7 testswitch01 pluto[3475]: "iPhone"[2] 192.168.223.208 #4: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
7 testswitch01 pluto[3475]: "iPhone"[2] 192.168.223.208 #4: new NAT mapping for #4, was 192.168.223.208:500, now 192.168.223.208:4500
7 testswitch01 pluto[3475]: "iPhone"[2] 192.168.223.208 #4: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=aes_256 prf=oakley_sha group=modp1536}
7 testswitch01 pluto[3475]: "iPhone"[2] 192.168.223.208 #4: Dead Peer Detection (RFC 3706): enabled
7 testswitch01 pluto[3475]: "iPhone"[2] 192.168.223.208 #4: XAUTH: Sending XAUTH Login/Password Request
7 testswitch01 pluto[3475]: "iPhone"[2] 192.168.223.208 #4: XAUTH: Sending Username/Password request (XAUTH_R0)
0 testswitch01 pluto[3475]: "iPhone"[2] 192.168.223.208 #4: discarding duplicate packet; already STATE_XAUTH_R0
1 testswitch01 CRON[3559]: pam_unix(cron:session): session opened for user root by (uid=0)
1 testswitch01 CRON[3559]: pam_unix(cron:session): session closed for user root
We then tried to disable XAUTH since the iOS docs state that IPSec
without XAUTH is supported when using certificates so we restarted
OpenSWAN, deleted the iPhone and Android connections, removed the user
and password from the iPhone VPN connection definition and tried again.
We assumed that not entering a name and password and not having the
server advertise itself as an XAUTH server was the way to disable XAUTH
and lots of Internet research yielded no firm instructions on how to do
so. We got:
3798]: packet from 192.168.223.208:500: received Vendor ID payload [RFC 3947] method set to=109
3798]: packet from 192.168.223.208:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set to=110
3798]: packet from 192.168.223.208:500: ignoring unknown Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
3798]: packet from 192.168.223.208:500: ignoring unknown Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
3798]: packet from 192.168.223.208:500: ignoring unknown Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
3798]: packet from 192.168.223.208:500: ignoring unknown Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
3798]: packet from 192.168.223.208:500: ignoring unknown Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
3798]: packet from 192.168.223.208:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 110
3798]: packet from 192.168.223.208:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 110
3798]: packet from 192.168.223.208:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
3798]: packet from 192.168.223.208:500: received Vendor ID payload [XAUTH]
3798]: packet from 192.168.223.208:500: received Vendor ID payload [Cisco-Unity]
3798]: packet from 192.168.223.208:500: received Vendor ID payload [Dead Peer Detection]
3798]: "RWNAT"[1] 192.168.223.208 #4: responding to Main Mode from unknown peer 192.168.223.208
3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD
3798]: "RWNAT"[1] 192.168.223.208 #4: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
3798]: "RWNAT"[1] 192.168.223.208 #4: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
3798]: "RWNAT"[1] 192.168.223.208 #4: no acceptable Oakley Transform
3798]: "RWNAT"[1] 192.168.223.208 #4: sending notification NO_PROPOSAL_CHOSEN to 192.168.223.208:500
3798]: "RWNAT"[1] 192.168.223.208: deleting connection "RWNAT" instance with peer 192.168.223.208 {isakmp=#0/ipsec=#0}
So it appears it is trying to use XAUTH anyway. We commenting out the
iPhone and Android sessions and then restarting OpenSWAN in case just
having the connections defined loaded some XAUTH listener that remained
listening even after the connections were deleted.
So how do we get certs working with iPhone IPSec only and particularly,
how do we do so with XAUTH disabled? Thanks. My apologies for the
length. Hopefully the detail is helpful - John
More information about the Users
mailing list