Hi, with certificate-based authentication the peer identity must be contained in the certificate either in the form of the subject distinguished name (C=.., O=..., CN=) or a subjectAltName. This seems to be the case with the hostname @vdut2.vyatta.com' but not with the IP address 172.16.139.160.
Best regards Andreas Mohit Mehta wrote: > Hi All, > > I'm popping this up in a new thread (probably shud've done that before - > apologies for the redundancy) as this is a problem different from the thread > I started earlier about creating raw RSA keys using strongswan. > > Anyways, cut to the issue - I'm trying to replicate the scenario demonstrated > here http://www.strongswan.org/uml/testresults43/ikev1/net2net-rsa/ On the > one side I have Stronswan and on the other side I have Openswan. The problem > that I'm encountering is that on the strongswan side if I do not define an > explicit rightid for the other end it complains about not finding the public > key of the peer - > > vDUT-1# sudo ipsec up peer-172.16.139.160-tunnel-1 > 002 "peer-172.16.139.160-tunnel-1" #5: initiating Main Mode > 104 "peer-172.16.139.160-tunnel-1" #5: STATE_MAIN_I1: initiate > 003 "peer-172.16.139.160-tunnel-1" #5: ignoring Vendor ID payload > [4f45606c50487c5662707575] > 003 "peer-172.16.139.160-tunnel-1" #5: received Vendor ID payload [Dead Peer > Detection] > 106 "peer-172.16.139.160-tunnel-1" #5: STATE_MAIN_I2: sent MI2, expecting MR2 > 002 "peer-172.16.139.160-tunnel-1" #5: we don't have a cert > 108 "peer-172.16.139.160-tunnel-1" #5: STATE_MAIN_I3: sent MI3, expecting MR3 > 002 "peer-172.16.139.160-tunnel-1" #5: Peer ID is ID_IPV4_ADDR: > '172.16.139.160' > 003 "peer-172.16.139.160-tunnel-1" #5: no public key known for > '172.16.139.160' > 217 "peer-172.16.139.160-tunnel-1" #5: STATE_MAIN_I3: INVALID_KEY_INFORMATION > 002 "peer-172.16.139.160-tunnel-1" #5: sending encrypted notification > INVALID_KEY_INFORMATION to 172.16.139.160:500 > 010 "peer-172.16.139.160-tunnel-1" #5: STATE_MAIN_I3: retransmission; will > wait 20s for response > 002 "peer-172.16.139.160-tunnel-1" #5: Peer ID is ID_IPV4_ADDR: > '172.16.139.160' > 003 "peer-172.16.139.160-tunnel-1" #5: no public key known for > '172.16.139.160' > 217 "peer-172.16.139.160-tunnel-1" #5: STATE_MAIN_I3: INVALID_KEY_INFORMATION > 002 "peer-172.16.139.160-tunnel-1" #5: sending encrypted notification > INVALID_KEY_INFORMATION to 172.16.139.160:500 > 010 "peer-172.16.139.160-tunnel-1" #5: STATE_MAIN_I3: retransmission; will > wait 40s for response > 002 "peer-172.16.139.160-tunnel-1" #5: Peer ID is ID_IPV4_ADDR: > '172.16.139.160' > 003 "peer-172.16.139.160-tunnel-1" #5: no public key known for > '172.16.139.160' > 217 "peer-172.16.139.160-tunnel-1" #5: STATE_MAIN_I3: INVALID_KEY_INFORMATION > 002 "peer-172.16.139.160-tunnel-1" #5: sending encrypted notification > INVALID_KEY_INFORMATION to 172.16.139.160:500 > 031 "peer-172.16.139.160-tunnel-1" #5: max number of retransmissions (2) > reached STATE_MAIN_I3. Possible authentication failure: no acceptable > response to our first encrypted message > 000 "peer-172.16.139.160-tunnel-1" #5: starting keying attempt 2 of at most > 3, but releasing whack > > > On the other hand, if I use rightid on strongswan's side and the same as > leftid on Openswan's side, then the connections comes up fine - > > vDUT-1# sudo ipsec up peer-172.16.139.160-tunnel-1 > 002 "peer-172.16.139.160-tunnel-1" #1: initiating Main Mode > 104 "peer-172.16.139.160-tunnel-1" #1: STATE_MAIN_I1: initiate > 003 "peer-172.16.139.160-tunnel-1" #1: ignoring Vendor ID payload > [4f45606c50487c5662707575] > 003 "peer-172.16.139.160-tunnel-1" #1: received Vendor ID payload [Dead Peer > Detection] > 106 "peer-172.16.139.160-tunnel-1" #1: STATE_MAIN_I2: sent MI2, expecting MR2 > 002 "peer-172.16.139.160-tunnel-1" #1: we don't have a cert > 108 "peer-172.16.139.160-tunnel-1" #1: STATE_MAIN_I3: sent MI3, expecting MR3 > 002 "peer-172.16.139.160-tunnel-1" #1: Peer ID is ID_FQDN: '@vdut2.vyatta.com' > 002 "peer-172.16.139.160-tunnel-1" #1: ISAKMP SA established > 004 "peer-172.16.139.160-tunnel-1" #1: STATE_MAIN_I4: ISAKMP SA established > 002 "peer-172.16.139.160-tunnel-1" #2: initiating Quick Mode > PUBKEY+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1} > 112 "peer-172.16.139.160-tunnel-1" #2: STATE_QUICK_I1: initiate > 002 "peer-172.16.139.160-tunnel-1" #2: sent QI2, IPsec SA established > {ESP=>0x9fa1fd8e <0xbc288ee6} > 004 "peer-172.16.139.160-tunnel-1" #2: STATE_QUICK_I2: sent QI2, IPsec SA > established {ESP=>0x9fa1fd8e <0xbc288ee6} > > > It would be great if anyone could point out whether this is an [ expected > behavior | known issue | bug ]? I haven't taken a look at the code yet to see > what's going on but wanted to get some input from the developers on this > first. > > Thanks in advance for any help on this. Let me know if more information is > needed to diagnose the issue. Apologies again for message duplication! ====================================================================== Andreas Steffen [email protected] strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
