On 12/29/2020 4:31 AM, Paul Wouters wrote:
On Mon, 28 Dec 2020, Alex wrote:
How can I tell what type of cert I'm using?
openssl x509 -noout -text -in /your/cert.pem
If you used certutil to generate the certificate directly inside the NSS
database, you may have to export first, or use something like:
certutil -L -d sql:/etc/ipsec.d -n your_cert_nickname
See man certutil for details and instructions for use.
One hint might be:
Set-VpnConnectionIPsecConfiguration -ConnectionName "ikev2-cp"
-AuthenticationTransformConstants SHA256128 -CipherTransformConstants
AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -PfsGroup
PFS2048 -DHGroup Group14 -PassThru -Force
DH Group14 means MODP2048:
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8
I've done this, and it appears to make no difference.
No difference means you get back to policy mismatch error or a dialog
box asking for username and password? "it still doesn't work" doesn't
say much.
There doesn't appear to be any further references to modp1024, but I
have no idea what to do next.
I don't see modp1024 either, which would mean something has changed.
Based on the strongswan page, I've added the following:
ike=aes256-sha384-prfsha384-modp2048
esp=aes256gcm16-modp2048
strongswan is not fullt compatible with libreswan. the ike= and esp=
line take a different format. The above two strongswan lines translate
to libreswan as:
ike=aes256-sha2_384;modp2048
esp=aes_gcm256;modp2048
I may add that these instructions define a single cipher set that is
accepted; at first you may want to stick to the default set, which
includes many different suites, and then refine to the single set that
you want at a fine-tuning stage.
Can I ask you to review this pastebin output from an attempt to connect?
https://pastebin.com/D83HRJnW
This is with "plutodebug = all crypt". In addition to the
NO_PROPOSAL_CHOSEN messages, the highlights appear to include:
I've given a quick look, and I don't have much more to add to Paul's
comment below (maybe "all crypt" is too much).
find_host_connection local=68.195.111.42:500 remote=192.168.1.35:500
policy=ECDSA+IKEV2_ALLOW but ignoring ports
find_host_connection local=68.195.111.42:500 remote=192.168.1.35:500
policy=RSASIG+IKEV2_ALLOW but ignoring ports
find_host_connection local=68.195.111.42:500 remote=192.168.1.35:500
policy=PSK+IKEV2_ALLOW but ignoring ports
This is just our debugging the loop over the existing authentication
methods and IPs.
It seems you do not have a connection loaded that satisfies all of these:
- has ikev2=yes
- uses left=68.195.111.42 (or left=%defaultroute) [provided you use left
as your local machine, and right for the remote machine options. if
you flipped that, you don't have a right= matching these]
I thought if left is the local machine it should use either
%defaultroute or the /local/ address - I have copy-pasted the paragraph
from the ipsec.conf manpage in one of my previous answers.
- uses right=192.168.1.35 or right=%any
- uses authby=ecdsa or authby=rsa or authby=secret (or a combination
thereof, or it is not set in which case the defaults would include rsa
and/or rsa+ecdsa depending on the version of libreswan)
- an ike= line that matches the remote client proposal list (or the
client uses something that is not a default ike parameter when no ike=
line is specified)
You might want to manually add the connection to see if it loads at all:
ipsec auto --add yourconnname
Paul
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
