The selection is not based on "best", but rather on the order of
algorithms at the initiator side first and the responder side second.
AFAIK, strongSwan accepts the first proposed algorithm that is also
configured configured locally. The first algorithm proposed by windows
and also accepted
version: strongSwan 5.6.2
When I connect from Windows 10, strongSwan replies with a different policy than
requested, causing a policy mismatch
```connections { default { version = 2 send_cert = always
encap = yes pools = pool1 unique = replace proposals =
aes256gc
Version: strongSwan 5.6.2 using swanctl
I am trying to re-use settings so that just the certificate is different
(vpnserver uses ECDSA, vpnsever1 uses RSA), which according to the help page
[1] should be possible:
"connections..local sectionSection for a local authentication
round. A local authe
Tobias,
Makes sense, but just to understand what is going on and know how
to read the logs, are you saying that each "ESP:" prefix signifies a
separate proposal that is parsed independently (log below)? A single
proposal might have one or more algorithms separated by slashes, correct ?
T
Hi,
> I see an error in the strongswan
> logs and I'm not sure what is going on here, and what I should do to
> correct this:
There is nothing to correct as the connection gets successfully
established. If you have a closer look at the log you see that the
client sends not one, but four ESP prop
