Hi, > > I've attached the logs from the last few minutes after "ipsec start; > > ipsec auto --add mytunnel; ipsec auto --up mytunnel" on both sides. > > I've also attached the "ipsec status" output from both sides. I've > > also attached the current ipsec.conf used on both sides. > > Run ipsec whack --listpubkeys on both ends and confirm you have the > proper keys configured? > > If not using identical ipsec.conf files on both ends, ensure that you > did not accidentally swap the two keys on one end? Because if you > really only have two keys and libreswan tried the wrong key, that's > the only thing that could have happened, since there would only be > one other key that could be the wrong one which is their own key.
The whole system seems very fragile. I'm confident the keys are correct. These are the steps I followed: orion is the local side and arcade is the remote side. - initnss on both sides - "ipsec newhostkey --output /etc/ipsec.secrets" on both sides - ipsec showhostkey --left --ckaid <ckaid key> on local side - ipsec showhostkey --right --ckaid <ckaid key> on remote side - create /etc/ipsec.conf using the left/rightid and left/right IPs and left/rightrsasigkey from both sides - scp /etc/ipsec.conf to other side. - ipsec setup start on both sides - ipsec auto --add <tunnel name> on both sides - ipsec auto --up <tunnel name> on both sides Yesterday I believe I had it working following these steps. The remote side shows there are two tunnels up on the remote side (one is the other tunnel to the other mail server), but the tunnel on the local side (orion) was only loaded, not active. Now when I try to bring up the tunnel, it fails with that "failed (wrong key?)" error: # ipsec auto --up oriontun 003 "oriontun" #4: Signature check (on @arcade-orion) failed (wrong key?); tried *AwEAAdDiX 133 "oriontun" #3: STATE_PARENT_I1: sent v2I1, expected v2R1 002 "oriontun" #3: local ESP/AH proposals for oriontun (IKE SA initiator emitting ESP/AH proposals): 1:ESP:ENCR=AES_GCM_C_256;INTEG=NONE;DH=NONE;ESN=DISABLED 2:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256;DH=NONE;ESN=DISABLED 3:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;DH=NONE;ESN=DISABLED 4:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA1_96;DH=NONE;ESN=DISABLED 5:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA2_256_128;DH=NONE;ESN=DISABLED 134 "oriontun" #4: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=aes_gcm_16_256 integ=n/a prf=sha2_512 group=DH19} 002 "oriontun" #4: IKEv2 mode peer ID is ID_FQDN: '@arcade-orion' 003 "oriontun" #4: Signature check (on @arcade-orion) failed (wrong key?); tried *AwEAAdDiX 002 "oriontun" #4: Digital Signature authentication failed 036 "oriontun" #4: encountered fatal error in state STATE_PARENT_I2 I've verified they are the correct keys on both sides. One thing I noticed with "ipsec status" is this line: 000 dnssec-rootkey-file=/var/lib/unbound/root.key, dnssec-trusted=<unset> The /var/lib/unbound/root.key file looks to have been created at midnight: # ls -l /var/lib/unbound/root.key -rw-r--r-- 1 unbound unbound 1251 Oct 7 00:00 /var/lib/unbound/root.key Could this be the cause? Other than the date, the file appears to be the same one as was generated the day prior. A few questions: - How do I delete keys from the NSS database? I can list them with "certutil -K -d sql:/etc/ipsec.d" or "ipsec showhostkey --list", but how can I delete them? - Are there similar easy steps for creating a host-to-host tunnels using certs? - Is it important that left/rightid are unique between tunnels? - why are the actual lengths of the keys different on one side than the other? One is 643 chars while the other is 579 chars. Why wouldn't they have been generated to be the same? Thanks, Alex > > Paul _______________________________________________ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan