Hi Peter,
I'm attaching the full control+controlmore logs from both versions in
case anyone's interested (IP redacted). A diff shows them effectively
identical until after the full match lines.
Actually, I think that the problem is caused by an earlier difference in
the logs:
4.4.0:
loading
Hallelujah! Predictably, this was a comedy of errors, including syntax changes
in ipsec.secrets leading to a line getting lost. Also, mysteriously, strongSwan
was unable to parse the private key even when it was trying. Not sure why, as
it was fixed by simply washing it through `openvpn rsa`
Hi Peter,
With 4.4.0, this works great; here's a relevant snippet from pluto.log (after
all the certs have checked out):
| XAUTHInitRSA check passed with keyid
08:f4:bf:b9:2d:e8:da:89:48:51:70:dc:1a:e8:a8:93:33:02:a1:3c
...
Now when I use the same config on 4.5.2, I get a slightly
Hi Tobias,
Thanks for getting back to me. I should have mentioned that the different
keyids are just an artifact of the automatic process we have for provisioning
clients. I've gone back and used the same identity on both servers just to be
sure, and see the same results. I've also been trying
Hello,
I'm attempting to upgrade from strongSwan 4.4.0 to 4.5.2 and I'm seeing a
mysterious failure that I haven't been able to puzzle out. The connection
config looks like this (DPD and cipher settings omitted for brevity):
conn ipsec
keyexchange = ikev1
auth = esp
authby =