[Swan] Options for Windows clients

[Manfred]

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