[Openswan Users] Linux IPsec client

[wangxx at jmu.edu]

---- Original message ----
>Date: Tue, 26 Sep 2006 23:59:40 +0200
>From: Jacco de Leeuw <jacco2 at dds.nl>  
>Subject: Re: [Openswan Users] Linux IPsec client  
>To: users at openswan.org
>
>
>Xunhua Wang wrote:
>
>> 68.235.168.219:4500 #344: cannot respond to IPsec SA
request because no
>> connection is known for 134.126.20.79:4500[C=US, ST=Virginia,
>> L=Harrisonburg, O=JMU, OU=CS, CN=IPsec VPN Server
>> 02]:17/1701...68.235.168.219:4500[C=US, ST=Virginia,
L=Harrisonburg, O=JMU,
>> OU=CS, CN=Steve Wang]:17/1701===192.168.1.3/32
>
>Do the certificates check out OK? I.e. has the client cert
been issued
>by the same CA as the server cert? Etc. etc.

Yes, both the client cert and the server cert are issued by
the same CA.

>You should now get some more info in your client log as well.

Below is from the client side /var/log/secure:

---------- CLIENT LOG BEGINS ----------
Sep 26 18:19:12 localhost pluto[5772]: "l2tpclient" #1:
initiating Main Mode
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1:
received Vendor ID payload [Dead Peer Detection]
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
method set to=108
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1:
enabling possible NAT-traversal with method RFC 3947
(NAT-Traversal)
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1:
transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1:
STATE_MAIN_I2: sent MI2, expecting MR2
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03:
i am NATed
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1: I am
sending my cert
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1: I am
sending a certificate request
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1:
transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1:
STATE_MAIN_I3: sent MI3, expecting MR3
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1: Main
mode peer ID is ID_DER_ASN1_DN: 'C=US, ST=Virginia,
L=Harrisonburg, O=JMU, OU=CS, CN=IPsec VPN Server 02'
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1: crl
update for "C=US, ST=Virginia, L=Harrisonburg, O=JMU, OU=CS,
CN=Crypto CA" is overdue since Jun 04 01:53:24 UTC 2006
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1:
transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1:
STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG
cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #2:
initiating Quick Mode RSASIG+ENCRYPT+COMPRESS+DONTREKEY+UP
{using isakmp#1}
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1:
ignoring informational payload, type INVALID_ID_INFORMATION
Sep 26 18:19:13 localhost pluto[5772]: "l2tpclient" #1:
received and ignored informational message
Sep 26 18:19:23 localhost pluto[5772]: "l2tpclient" #1:
ignoring informational payload, type INVALID_MESSAGE_ID
Sep 26 18:19:23 localhost pluto[5772]: "l2tpclient" #1:
received and ignored informational message
Sep 26 18:19:43 localhost pluto[5772]: "l2tpclient" #1:
ignoring informational payload, type INVALID_MESSAGE_ID
Sep 26 18:19:43 localhost pluto[5772]: "l2tpclient" #1:
received and ignored informational message

---------- CLIENT LOG ENDS ----------

Not very useful, I guess.

>Can the client connect when it is not behind NAT? You
probably want
>to avoid this, but what if you try this briefly, just for testing
>purposes?

Good idea. I will try it tomorrow.

>Jacco
>-- 
>Jacco de Leeuw                         mailto:jacco2 at dds.nl
>Zaandam, The Netherlands           http://www.jacco2.dds.nl

Steve