Applied Patch. Works Great! Thanks a lot Andreas. ----- Andreas Steffen <[email protected]> wrote: > Sorry, > > I didn't realize that you are using raw RSA keys. Here is a > bug fix which assigns the IP address of the end point to a > raw RSA key if the ID is not specified explicitly: > > http://wiki.strongswan.org/repositories/diff/strongswan?rev=ee2679ec25a571ea5e4ba28e0fb87828f0a31432 > > Thanks > > Andreas > > Andreas Steffen wrote: > > 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]== > > > -- > ====================================================================== > 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
