[Openswan Users] Apparent XAUTH failre iPhone to Openswan, ipsec w/ identity certificates
Michael Rightmire
rightmire at team-datentechnik.de
Thu Oct 13 04:15:08 EDT 2011
Hey,
I'm an experienced administrator but new to openswan and iPhone VPN connectivity.
I am running...
Gentoo Base System release 2.0.3
Linux <system> 2.6.39-hardened-r8 #2 SMP Wed Sep 21 17:35:56 CEST 2011 i686 Intel(R) Xeon(R) CPU E5620 @ 2.40GHz GenuineIntel GNU/Linux
Linux Openswan 2.6.35 (klips)
xl2tpd-1.2.4
iPhone 4.2.1 (8C148)
I have been able to VPN from the iPhone to the Gentoo server using l2tp and PSK, but not with signed identity certificates (this is mandated by my company to set up).
The ipsec.log shows the connection starting, the iPhone sends its cert, the cert is authenticated, and then the iPhone (appears) to start sending XAUTH authentication requests which are simply never responded to.
Openswan was installed via emerge, however when I manually open the /usr/portage/distfiles/openswan-2.6.35.tar.gz (which SHOULD be the install file used by emerge...I think) it looks like the XAUTH was enabled...
(from Makefile.inc)
USE_XAUTH?=true
USE_XAUTHPAM?=false
I did not change these settings. These were what I found in the default downloaded file.
!!!Question 1: Is there a way to actually confirm XAUTH is activated in openswan beside examining the Makefile,inc?
!!!Question 2: How can I trace the failure of he XAUTH password requests. The ipsec.log (even when ipsec.conf is set to plutodebug="all") doesn't really seem to show much info about where these requests are disappearing to.
!!!Question 3: Any other suggestions to make this work :-)?
Thanks!
Mike
LOGS and CONFIGS:
(ipsec.log)
MARK START IPHONE VPN CONNECT ATTEMPT
MARK START IPHONE VPN CONNECT ATTEMPT
MARK START IPHONE VPN CONNECT ATTEMPT
|
| *received 644 bytes from 89.XXX.XXX.89:500 on ppp0 (port=500)
| processing version=1.0 packet with exchange type=ISAKMP_XCHG_IDPROT (2)
packet from 89.XXX.XXX.89:500: received Vendor ID payload [RFC 3947] method set to=109
packet from 89.XXX.XXX.89:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set to=110
packet from 89.XXX.XXX.89:500: ignoring unknown Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
packet from 89.XXX.XXX.89:500: ignoring unknown Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
packet from 89.XXX.XXX.89:500: ignoring unknown Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
packet from 89.XXX.XXX.89:500: ignoring unknown Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
packet from 89.XXX.XXX.89:500: ignoring unknown Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
packet from 89.XXX.XXX.89:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 110
packet from 89.XXX.XXX.89:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 110
packet from 89.XXX.XXX.89:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
packet from 89.XXX.XXX.89:500: received Vendor ID payload [XAUTH]
packet from 89.XXX.XXX.89:500: received Vendor ID payload [Cisco-Unity]
packet from 89.XXX.XXX.89:500: received Vendor ID payload [Dead Peer Detection]
| creating state object #2 at 0x13c688b8
| processing connection td-L2TP[2] 89.XXX.XXX.89
| ICOOKIE: 34 ce 98 50 65 42 94 85
| RCOOKIE: 5c b0 70 eb c1 e1 50 b3
| state hash entry 18
| inserting state object #2 on chain 18
| inserting event EVENT_SO_DISCARD, timeout in 0 seconds for #2
"td-L2TP"[2] 89.XXX.XXX.89 #2: responding to Main Mode from unknown peer 89.XXX.XXX.89
| complete state transition with STF_OK
"td-L2TP"[2] 89.XXX.XXX.89 #2: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
| sending reply packet to 89.XXX.XXX.89:500 (from port 500)
| sending 152 bytes for STATE_MAIN_R0 through ppp0:500 to 89.XXX.XXX.89:500 (using #2)
| inserting event EVENT_RETRANSMIT, timeout in 10 seconds for #2
"td-L2TP"[2] 89.XXX.XXX.89 #2: STATE_MAIN_R1: sent MR1, expecting MI2
| modecfg pull: quirk-poll policy:push not-client
| phase 1 is done, looking for phase 2 to unpend
| * processed 0 messages from cryptographic helpers
| next event EVENT_RETRANSMIT in 10 seconds for #2
| next event EVENT_RETRANSMIT in 10 seconds for #2
.
.
.
| helper 0 has finished work (cnt now 1)
| helper 0 replies to id: q#3
| processing connection td-L2TP[2] 89.XXX.XXX.89
| started looking for secret for (none)->C=DE, ST=Niedersachsen, O=team Datentechnik, CN=89.166.154.251, E=rightmire at team-datentechnik.de of kind PPK_PSK
| actually looking for secret for (none)->C=DE, ST=Niedersachsen, O=team Datentechnik, CN=89.166.154.251, E=rightmire at team-datentechnik.de of kind PPK_PSK
| 1: compared key %any to (none) / C=DE, ST=Niedersachsen, O=team Datentechnik, CN=89.166.154.251, E=rightmire at team-datentechnik.de -> 2
| 2: compared key %any to (none) / C=DE, ST=Niedersachsen, O=team Datentechnik, CN=89.166.154.251, E=rightmire at team-datentechnik.de -> 2
| line 1: match=2
| best_match 0>2 best=0x13c635a8 (line=1)
| concluding with best_match=2 best=0x13c635a8 (lineno=1)
| parent1 type: 7 group: 5 len: 2668
| 0: w->pcw_dead: 0 w->pcw_work: 0 cnt: 1
| asking helper 0 to do compute dh+iv op on seq: 4 (len=2668, pcw_work=1)
| crypto helper write of request: cnt=2668<wlen=2668.
| inserting event EVENT_CRYPTO_FAILED, timeout in 300 seconds for #2
| complete state transition with STF_OK
"td-L2TP"[2] 89.XXX.XXX.89 #2: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
| sending reply packet to 89.XXX.XXX.89:500 (from port 500)
| sending 292 bytes for STATE_MAIN_R1 through ppp0:500 to 89.XXX.XXX.89:500 (using #2)
| inserting event EVENT_RETRANSMIT, timeout in 10 seconds for #2
"td-L2TP"[2] 89.XXX.XXX.89 #2: STATE_MAIN_R2: sent MR2, expecting MI3
| modecfg pull: quirk-poll policy:push not-client
| phase 1 is done, looking for phase 2 to unpend
| * processed 1 messages from cryptographic helpers
| next event EVENT_RETRANSMIT in 10 seconds for #2
| next event EVENT_RETRANSMIT in 10 seconds for #2
! helper 0 read 2664+4/2668 bytesfd: 7
! helper 0 doing compute dh+iv op id: 4
.
.
.
| *received 1804 bytes from 89.XXX.XXX.89:4500 on ppp0 (port=4500)
| processing version=1.0 packet with exchange type=ISAKMP_XCHG_IDPROT (2)
| ICOOKIE: 34 ce 98 50 65 42 94 85
| RCOOKIE: 5c b0 70 eb c1 e1 50 b3
| state hash entry 18
| v1 peer and cookies match on #2, provided msgid 00000000 vs 00000000
| v1 state object #2 found, in STATE_MAIN_R2
| processing connection td-L2TP[2] 89.XXX.XXX.89
"td-L2TP"[2] 89.XXX.XXX.89 #2: ignoring informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000
"td-L2TP"[2] 89.XXX.XXX.89 #2: Main mode peer ID is ID_DER_ASN1_DN: 'C=DE, ST=Niedersachsen, O=team Datentechnik, CN=89.166.154.251, E=rightmire at team-datentechnik.de'
"td-L2TP"[2] 89.XXX.XXX.89 #2: no crl from issuer "C=DE, ST=Niedersachsen, L=Georgsmarienh\303\274tte, O=team Datentechnik, CN=teamDatentechnik, E=rightmire at team-datentechnik.de" found (strict=no)
| reached self-signed root ca
| requested CA: '%any'
| started looking for secret for (none)->C=DE, ST=Niedersachsen, O=team Datentechnik, CN=89.166.154.251, E=rightmire at team-datentechnik.de of kind PPK_RSA
| searching for certificate PPK_XAUTH:N/A vs PPK_RSA:AwEAAQsJs
| searching for certificate PPK_RSA:AwEAAbBkW vs PPK_RSA:AwEAAQsJs
| searching for certificate PPK_RSA:AwEAAQsJs vs PPK_RSA:AwEAAQsJs
| started looking for secret for (none)->(none) of kind PPK_RSA
| searching for certificate PPK_XAUTH:N/A vs PPK_RSA:AwEAAQsJs
| searching for certificate PPK_RSA:AwEAAbBkW vs PPK_RSA:AwEAAQsJs
| searching for certificate PPK_RSA:AwEAAQsJs vs PPK_RSA:AwEAAQsJs
| offered CA: 'C=DE, ST=Niedersachsen, L=Georgsmarienh\303\274tte, O=team Datentechnik, CN=teamDatentechnik, E=rightmire at team-datentechnik.de'
| required CA is '%any'
| key issuer CA is 'C=DE, ST=Niedersachsen, L=Georgsmarienh\303\274tte, O=team Datentechnik, CN=teamDatentechnik, E=rightmire at team-datentechnik.de'
| an RSA Sig check passed with *AwEAAbBkW [preloaded key]
| thinking about whether to send my certificate:
| I have RSA key: OAKLEY_RSA_SIG cert.type: CERT_X509_SIGNATURE
| sendcert: CERT_ALWAYSSEND and I did not get a certificate request
| so send cert.
"td-L2TP"[2] 89.XXX.XXX.89 #2: I am sending my cert
| started looking for secret for (none)->C=DE, ST=Niedersachsen, O=team Datentechnik, CN=89.166.154.251, E=rightmire at team-datentechnik.de of kind PPK_RSA
| searching for certificate PPK_XAUTH:N/A vs PPK_RSA:AwEAAQsJs
| searching for certificate PPK_RSA:AwEAAbBkW vs PPK_RSA:AwEAAQsJs
| searching for certificate PPK_RSA:AwEAAQsJs vs PPK_RSA:AwEAAQsJs
| signing hash with RSA Key *AwEAAQsJs
| complete state transition with STF_OK
"td-L2TP"[2] 89.XXX.XXX.89 #2: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
| processing connection td-L2TP[2] 89.XXX.XXX.89
| processing connection td-L2TP[2] 89.XXX.XXX.89
"td-L2TP"[2] 89.XXX.XXX.89 #2: new NAT mapping for #2, was 89.XXX.XXX.89:500, now 89.XXX.XXX.89:4500
| sending reply packet to 89.XXX.XXX.89:4500 (from port 4500)
| sending 1644 bytes for STATE_MAIN_R2 through ppp0:4500 to 89.XXX.XXX.89:4500 (using #2)
| inserting event EVENT_SA_EXPIRE, timeout in 3600 seconds for #2
"td-L2TP"[2] 89.XXX.XXX.89 #2: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=aes_256 prf=oakley_sha group=modp1536}
"td-L2TP"[2] 89.XXX.XXX.89 #2: XAUTH: Sending XAUTH Login/Password Request
"td-L2TP"[2] 89.XXX.XXX.89 #2: XAUTH: Sending Username/Password request (XAUTH_R0)
| sending 76 bytes for XAUTH: req through ppp0:4500 to 89.XXX.XXX.89:4500 (using #2)
| inserting event EVENT_RETRANSMIT, timeout in 30 seconds for #2
| * processed 0 messages from cryptographic helpers
| next event EVENT_RETRANSMIT in 13 seconds for #1
| next event EVENT_RETRANSMIT in 13 seconds for #1
.
.
.
| *received 1804 bytes from 89.XXX.XXX.89:4500 on ppp0 (port=4500)
| processing version=1.0 packet with exchange type=ISAKMP_XCHG_IDPROT (2)
| ICOOKIE: 34 ce 98 50 65 42 94 85
| RCOOKIE: 5c b0 70 eb c1 e1 50 b3
| state hash entry 18
| v1 peer and cookies match on #2, provided msgid 00000000 vs 00000000
| v1 state object #2 found, in STATE_XAUTH_R0
| processing connection td-L2TP[2] 89.XXX.XXX.89
"td-L2TP"[2] 89.XXX.XXX.89 #2: discarding duplicate packet; already STATE_XAUTH_R0
| * processed 0 messages from cryptographic helpers
| next event EVENT_RETRANSMIT in 3 seconds for #1
| next event EVENT_RETRANSMIT in 3 seconds for #1
.
.
.
(the above block repeated three times)
.
.
.
| next event EVENT_RETRANSMIT in 0 seconds for #1
| *time to handle event
| handling event EVENT_RETRANSMIT
| event after this is EVENT_NAT_T_KEEPALIVE in 5 seconds
| processing connection td-L2TP[2] 89.XXX.XXX.89
| handling event EVENT_RETRANSMIT for 89.XXX.XXX.89 "td-L2TP" #1
| sending 76 bytes for EVENT_RETRANSMIT through ppp0:4500 to 89.XXX.XXX.89:4500 (using #1)
| inserting event EVENT_RETRANSMIT, timeout in 40 seconds for #1
| next event EVENT_NAT_T_KEEPALIVE in 5 seconds
|
| next event EVENT_NAT_T_KEEPALIVE in 0 seconds
| *time to handle event
| handling event EVENT_NAT_T_KEEPALIVE
| event after this is EVENT_PENDING_DDNS in 0 seconds
| processing connection td-L2TP[2] 89.XXX.XXX.89
| processing connection td-L2TP[2] 89.XXX.XXX.89
| handling event EVENT_PENDING_DDNS
| event after this is EVENT_SHUNT_SCAN in 0 seconds
| inserting event EVENT_PENDING_DDNS, timeout in 60 seconds
| handling event EVENT_SHUNT_SCAN
| event after this is EVENT_PENDING_PHASE2 in 0 seconds
| inserting event EVENT_SHUNT_SCAN, timeout in 120 seconds
| scanning for shunt eroutes
| handling event EVENT_PENDING_PHASE2
| event after this is EVENT_RETRANSMIT in 12 seconds
| inserting event EVENT_PENDING_PHASE2, timeout in 120 seconds
| pending review: connection "td-L2TP" was not up, skipped
| pending review: connection "td-L2TP" was not up, skipped
| next event EVENT_RETRANSMIT in 12 seconds for #2
|
| *received 1804 bytes from 89.XXX.XXX.89:4500 on ppp0 (port=4500)
| processing version=1.0 packet with exchange type=ISAKMP_XCHG_IDPROT (2)
| ICOOKIE: 34 ce 98 50 65 42 94 85
| RCOOKIE: 5c b0 70 eb c1 e1 50 b3
| state hash entry 18
| v1 peer and cookies match on #2, provided msgid 00000000 vs 00000000
| v1 state object #2 found, in STATE_XAUTH_R0
| processing connection td-L2TP[2] 89.XXX.XXX.89
"td-L2TP"[2] 89.XXX.XXX.89 #2: discarding duplicate packet; already STATE_XAUTH_R0
| * processed 0 messages from cryptographic helpers
| next event EVENT_RETRANSMIT in 9 seconds for #2
| next event EVENT_RETRANSMIT in 9 seconds for #2
MARK STOP IPHONE VPN CONNECT ATTEMPT
MARK STOP IPHONE VPN CONNECT ATTEMPT
MARK STOP IPHONE VPN CONNECT ATTEMPT
(ipsec.conf)
version 2.0 # conforms to second version of ipsec.conf specification
config setup
plutodebug="control"
dumpdir=/var/run/pluto/
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:192.168.2.0/24
oe=off
protostack=klips
plutostderrlog=/var/log/ipsec.log
interfaces="ipsec0=ppp0"
conn block
auto=ignore
conn private
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
conn packetdefault
auto=ignore
conn td-L2TP
authby=rsasig
pfs=no
auto=add
rekey=no
type=transport
left=%ppp0
leftcert=/etc/ipsec.d/certs/teamfirewall.crt
leftid=%myid
leftxauthserver=yes
leftxauthusername=mrightmi
dpdaction=clear
right=%any
rightsubnet=vhost:%priv,%no
(ipsec.secrets)
%any %any : PSK "xxxxxxxx"
%any %any : RSA /etc/ipsec.d/private/teamfirewall.key "xxxxxx"
%any %any : RSA /etc/ipsec.d/private/iphone.key "xxxxxxxxxx"
@mrightmi : XAUTH "xxxxxxxxxx"
(/etc/ipsec.d/htpasswd AND /etc/ipsec.d/passwd...I have seen posts saying to use both...???)
(both files created with command "htpasswd -c -m /etc/ipsec.d/<filename> mrightmi")
mrightmi:$aprxxxxxxxxxxxxxxxxxxxxxxxxxxxxxbv/:*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20111013/f883a0f6/attachment-0001.html
More information about the Users
mailing list