Re: [Swan] Options for Windows clients

[Manfred]

Hi Paul,

As far as I can see the following are the things that should be updated:

1) Drop the instruction about changing the Windows registry, and add an 
instruction to use and administrative PowerShell and 
Set-VpnConnectionIPsecConfiguration to solve the issue of the Windows 
default weak ciphers.
I see in Alex's log that Windows is still sending multiple proposals for 
phase 1 and a proposal for phase 2 (with INTEG=HMAC_SHA1_96) that 
doesn't match the Set-VpnConnectionIPsecConfiguration arguments, while I 
see that after this command a clean Windows box sends a single proposal 
for each of phase 1 and 2, which /do/ match the PS command args. It 
looks like this is due to interference with the registry tweak 
(according to the strongswan mail thread posted earlier).
The PS command is officially documented and is more complete, while in 
turn the registry tweak seems to affect phase 1 only, so I think the 
former should be preferred over the latter - your call of course.


2) In the page with instructions about certutil for Windows clients:
https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2

The instruction to generate the server certificate uses options -1 and 
-6 with no arguments, resulting in an interactive input loop for 
keyUsage and extKeyUsage. I would suggest explicit arguments instead:

--keyUsage "digitalSignature,keyEncipherment"
--extKeyUsage "serverAuth,ipsecIKEIntermediate"

The instruction to generate the client certificate might be misleading, 
instructing the user to set the same extKeyUsage as the server's, which 
is wrong. In place of -1 and -6 I'd suggest:

--keyUsage "digitalSignature,keyEncipherment"
--extKeyUsage "clientAuth"

3) This is not really about instructions, however it might be worth 
consideration:
In the latest version of this thread the windows certificate still 
contains a SAN entry "ip:68.195.111.42" i.e. the IP address of the 
server, which is wrong.
The libreswan log detects this mismatch, complains about "connection 
failed due to unmatched IKE ID in certificate SAN", but still 
establishes a connection. Maybe this is something worth a look into.



On 12/31/2020 8:37 PM, Paul Wouters wrote:

On Dec 31, 2020, at 14:14, Alex  wrote:



Can we add some of this to the wiki so someone else doesn't have to go
through all of this? There's no way the wiki entry would work as it is
currently.

I also want to experiment a bit more with the add/set-vpnconnection
commands - it seems unreasonable for end-users to have to enter those
commands.


I’ll update / integrate the documentation over the next few days.

Thanks for reporting back to us !

Paul


___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] Options for Windows clients

[Manfred]

Hi Alex,

I see you managed to get a connection up.
I think I still see some issues in the log though, but I won't repeat 
myself since it is all in my previous posts.


Good luck!

On 12/31/2020 8:14 PM, Alex wrote:

Hi Manfred,

I got it to work subsequent to your email. I'll explain how I got it
to work, but my next issue is with DHCP.


OK, so phase 1 passes.
However, it still looks like Windows is sending multiple proposals,
while when using Set-VpnConnectionIPsecConfiguration I think only one
should be sent.
Moreover:
The relevant parameters of Set-VpnConnectionIPsecConfiguration at this
stage (phase 1) are:
-EncryptionMethod AES256
-IntegrityCheckMethod SHA384
-DHGroup Group14
(The relevant part in the libreswan config is the ike=... line or its
default value if not present.)

-IntegrityCheckMethod SHA384 (as in you command below) does not match
INTEG=HMAC_SHA2_256_128 which appears to be sent by Windows and logged
as the accepted proposal by libreswan.


Here is a working example of using add/set-vpnconnection:
Add-VpnConnection -Name "ikev2-cp" -ServerAddress orion.example.com
-TunnelType "Ikev2" -PassThru -Force -EncryptionLevel "Required"
-AllUserConnection -AuthenticationMethod MachineCertificate
Set-VpnConnectionIPsecConfiguration
-ConnectionName "ikev2-cp"
-EncryptionMethod AES256
-DHGroup Group14
-IntegrityCheckMethod SHA384
-PfsGroup PFS2048
-AuthenticationTransformConstants SHA256128
-CipherTransformConstants AES256

The following also works, using these two changes:
-AuthenticationTransformConstants GCMAES256
-CipherTransformConstants GCMAES256


Dec 30 22:06:47.702497: "ikev2-cp"[2] 172.58.238.215 #3: processing
decrypted IKE_AUTH request: SK{IDi,CERT,CERTREQ,AUTH,CP,SA,TSi,TSr}
Dec 30 22:06:47.704044: "ikev2-cp"[2] 172.58.238.215 #3: certificate
verified OK: O=Example,CN=win10client.example.com
Dec 30 22:06:47.704103: "ikev2-cp"[2] 172.58.238.215 #3: IKEv2 mode
peer ID is ID_DER_ASN1_DN: 'CN=win10client.example.com, O=Example'
Dec 30 22:06:47.704669: "ikev2-cp"[2] 172.58.238.215 #3: authenticated
using RSA with SHA1

Client authentication passes too. It says "RSA with SHA1", which should
map to authby=rsasig in your conf file.


Turns out authby= isn't even necessary in order to work.


The log shows that the (failing) proposal sent by Windows is
1:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA1_96;ESN=DISABLED

This does not match the parameters of Set-VpnConnectionIPsecConfiguration.

It appears that Windows is not sending the proposals as required by
Set-VpnConnectionIPsecConfiguration.
  From the strongswan thread you posted earlier I remember the last
comment about the manually tweaked registry entry overriding some
parametres of Set-VpnConnectionIPsecConfiguration. Do you still have
that registry entry in place?


I've tested it both with and without and it works either way. Looks
like it's not necessary (anymore?).


On the libreswan side do you have an esp=... line in your config? If so
compare that with the proposal sent by Windows. It looks like the phase
2 proposal sent by Windows has weak ciphers, though - meaning you may
really want to change the registry rather than the esp=... line. Paul
might be more specific on this.


Yes, just before your email I added the following:

esp=aes_gcm256-null,aes_gcm128-null,aes256-sha2_512,aes128-sha2_512,aes256-sha1,aes128-sha1,aes_gcm256-null

This was pulled from an Oct 2019 post to this list that included
modp1024 at the end that I stripped off here.


Here are the certutil commands I am now using:

# generate CA certificate
echo "Generating CA certificate"
certutil -z <(head -c 1024 /dev/urandom) \
  -S -x -n "Example CA" -s "O=Example,CN=Example CA" -k rsa \
  -g 4096 -v 36 -t "CT,," -2 -d /var/lib/ipsec/nss

# generate orion client certificate
echo "Generating orion client certificate..."
certutil -z <(head -c 1024 /dev/urandom) \
  -S -c "Example CA" -n "orion.example.com" -s
"O=Example,CN=orion.example.com" \
  -k rsa -g 4096 -v 120 -t ",," -1 -6 -8 "orion.example.com" -d
/var/lib/ipsec/nss \
  --extSAN "ip:68.195.111.42" --keyUsage
"digitalSignature,keyEncipherment" \
  --extKeyUsage "serverAuth,ipsecIKEIntermediate"

Option -1 is an alias for --keyUsage, since you are using --keyUsage
with an explicit argument I would drop -1
Same for option -6 and --extKeyUsage


it turns out --extKeyUsage is necessary - I went through the process
of recreating the entire thing then transferring the Windows cert
again, but it then produces the following error:

certificate O=Example,CN=Example CA failed IPsec verification
NSS ERROR: Peer's certificate has an invalid signature.

This is with "orion.example.com" set in the Windows connection issue.


By adding -8 "orion.example.com" and --extSAN "ip:68.195.111.42" I
believe you are adding two entries to the subjectAltName extension,
resulting in something like:
subjectAltName = "dns:orion.example.com,ip:68.195.111.42"
This is technically correct, /if/ 

Re: [Swan] Options for Windows clients

[Alex]

Hi,

> Dec 31 13:53:06.342990: "ikev2-cp"[1] 172.58.239.44 #1: certificate
> verified OK: O=Example,CN=win10client.example.com
> Dec 31 13:53:06.343028: "ikev2-cp"[1] 172.58.239.44 #1: certificate
> subjectAltName extension does not match ID_IPV4_ADDR '172.58.239.44'
> Dec 31 13:53:06.343035: "ikev2-cp"[1] 172.58.239.44 #1: Peer CERT
> payload SubjectAltName does not match peer ID for this connection
> Dec 31 13:53:06.343038: "ikev2-cp"[1] 172.58.239.44 #1: X509:
> connection failed due to unmatched IKE ID in certificate SAN
> Dec 31 13:53:06.347987: "ikev2-cp"[1] 172.58.239.44 #1: reloaded
> private key matching left certificate 'orion.example.com'
> Dec 31 13:53:06.348005: "ikev2-cp"[1] 172.58.239.44 #1: switched from
> "ikev2-cp"[1] 172.58.239.44 to "ikev2-cp"
> Dec 31 13:53:06.348021: "ikev2-cp"[1] 172.58.239.44: deleting
> connection instance with peer 172.58.239.44 {isakmp=#0/ipsec=#0}

I just noticed this where it says the connection failed, but it
appears later to connect properly.

Removing the --extSAN for the win10client doesn't make a difference.
How do I set that properly?

Also, it's worth noting that the Windows cert must be installed in
both the Personal and "Trusted Root Certification Authority" store.
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] Options for Windows clients

[Paul Wouters]

On Dec 31, 2020, at 14:14, Alex  wrote:
> 
> 
> Can we add some of this to the wiki so someone else doesn't have to go
> through all of this? There's no way the wiki entry would work as it is
> currently.
> 
> I also want to experiment a bit more with the add/set-vpnconnection
> commands - it seems unreasonable for end-users to have to enter those
> commands.

I’ll update / integrate the documentation over the next few days.

Thanks for reporting back to us !

Paul
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] Options for Windows clients

[Alex]

Hi Manfred,

I got it to work subsequent to your email. I'll explain how I got it
to work, but my next issue is with DHCP.

> OK, so phase 1 passes.
> However, it still looks like Windows is sending multiple proposals,
> while when using Set-VpnConnectionIPsecConfiguration I think only one
> should be sent.
> Moreover:
> The relevant parameters of Set-VpnConnectionIPsecConfiguration at this
> stage (phase 1) are:
> -EncryptionMethod AES256
> -IntegrityCheckMethod SHA384
> -DHGroup Group14
> (The relevant part in the libreswan config is the ike=... line or its
> default value if not present.)
>
> -IntegrityCheckMethod SHA384 (as in you command below) does not match
> INTEG=HMAC_SHA2_256_128 which appears to be sent by Windows and logged
> as the accepted proposal by libreswan.

Here is a working example of using add/set-vpnconnection:
Add-VpnConnection -Name "ikev2-cp" -ServerAddress orion.example.com
-TunnelType "Ikev2" -PassThru -Force -EncryptionLevel "Required"
-AllUserConnection -AuthenticationMethod MachineCertificate
Set-VpnConnectionIPsecConfiguration
-ConnectionName "ikev2-cp"
-EncryptionMethod AES256
-DHGroup Group14
-IntegrityCheckMethod SHA384
-PfsGroup PFS2048
-AuthenticationTransformConstants SHA256128
-CipherTransformConstants AES256

The following also works, using these two changes:
-AuthenticationTransformConstants GCMAES256
-CipherTransformConstants GCMAES256

> > Dec 30 22:06:47.702497: "ikev2-cp"[2] 172.58.238.215 #3: processing
> > decrypted IKE_AUTH request: SK{IDi,CERT,CERTREQ,AUTH,CP,SA,TSi,TSr}
> > Dec 30 22:06:47.704044: "ikev2-cp"[2] 172.58.238.215 #3: certificate
> > verified OK: O=Example,CN=win10client.example.com
> > Dec 30 22:06:47.704103: "ikev2-cp"[2] 172.58.238.215 #3: IKEv2 mode
> > peer ID is ID_DER_ASN1_DN: 'CN=win10client.example.com, O=Example'
> > Dec 30 22:06:47.704669: "ikev2-cp"[2] 172.58.238.215 #3: authenticated
> > using RSA with SHA1
> Client authentication passes too. It says "RSA with SHA1", which should
> map to authby=rsasig in your conf file.

Turns out authby= isn't even necessary in order to work.

> The log shows that the (failing) proposal sent by Windows is
> 1:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA1_96;ESN=DISABLED
>
> This does not match the parameters of Set-VpnConnectionIPsecConfiguration.
>
> It appears that Windows is not sending the proposals as required by
> Set-VpnConnectionIPsecConfiguration.
>  From the strongswan thread you posted earlier I remember the last
> comment about the manually tweaked registry entry overriding some
> parametres of Set-VpnConnectionIPsecConfiguration. Do you still have
> that registry entry in place?

I've tested it both with and without and it works either way. Looks
like it's not necessary (anymore?).

> On the libreswan side do you have an esp=... line in your config? If so
> compare that with the proposal sent by Windows. It looks like the phase
> 2 proposal sent by Windows has weak ciphers, though - meaning you may
> really want to change the registry rather than the esp=... line. Paul
> might be more specific on this.

Yes, just before your email I added the following:

esp=aes_gcm256-null,aes_gcm128-null,aes256-sha2_512,aes128-sha2_512,aes256-sha1,aes128-sha1,aes_gcm256-null

This was pulled from an Oct 2019 post to this list that included
modp1024 at the end that I stripped off here.

> > Here are the certutil commands I am now using:
> >
> > # generate CA certificate
> > echo "Generating CA certificate"
> > certutil -z <(head -c 1024 /dev/urandom) \
> >  -S -x -n "Example CA" -s "O=Example,CN=Example CA" -k rsa \
> >  -g 4096 -v 36 -t "CT,," -2 -d /var/lib/ipsec/nss
> >
> > # generate orion client certificate
> > echo "Generating orion client certificate..."
> > certutil -z <(head -c 1024 /dev/urandom) \
> >  -S -c "Example CA" -n "orion.example.com" -s
> > "O=Example,CN=orion.example.com" \
> >  -k rsa -g 4096 -v 120 -t ",," -1 -6 -8 "orion.example.com" -d
> > /var/lib/ipsec/nss \
> >  --extSAN "ip:68.195.111.42" --keyUsage
> > "digitalSignature,keyEncipherment" \
> >  --extKeyUsage "serverAuth,ipsecIKEIntermediate"
> Option -1 is an alias for --keyUsage, since you are using --keyUsage
> with an explicit argument I would drop -1
> Same for option -6 and --extKeyUsage

it turns out --extKeyUsage is necessary - I went through the process
of recreating the entire thing then transferring the Windows cert
again, but it then produces the following error:

certificate O=Example,CN=Example CA failed IPsec verification
NSS ERROR: Peer's certificate has an invalid signature.

This is with "orion.example.com" set in the Windows connection issue.

> By adding -8 "orion.example.com" and --extSAN "ip:68.195.111.42" I
> believe you are adding two entries to the subjectAltName extension,
> resulting in something like:
> subjectAltName = "dns:orion.example.com,ip:68.195.111.42"
> This is technically correct, /if/ 68.195.111.42 is the IP address of the
> VPN gatweay as 

Re: [Swan] Options for Windows clients

[Manfred]

Hi,

On 12/31/2020 4:14 AM, Alex wrote:

Hi,


certutil -S -c "Example CA" -n "win10client.example.com" \
  -s "O=Example,CN=win10client.example.com" -k rsa \
  -g 4096 -v 36 -d sql:/etc/ipsec.d -t ",," -1 -6 -8
"win10client.example.com"


I see that the options -1 and -6 have no argument. Apparently this
triggers an interactive loop to specify the respective properties.
I think the client options should be:
-1 "digitalSignature,keyEncipherment"
-6 "clientAuth"

For the server:
-1 "digitalSignature,keyEncipherment"
-6 "serverAuth,ipsecIKEIntermediate"


I believe it was either the first or second message on this thread I
asked if it was a problem that I was testing on the same network I was
located on, but perhaps that got overlooked :-)
That's possible, I was not sure about that either, and eventually ended 
up giving the wrong answer! Sorry about that.


 I recalled it being a

problem when I did this like fifteen years ago, lol. I've since
connected through my phone.

Anyway, it was either that or a combination of changes I made to the
certutil command that got me a bit further.

Probably both.
After seeing your commands I'd say --extKeyUsage for the client cert had 
a role too.




Dec 30 22:06:47.568952: "ikev2-cp"[2] 172.58.238.215: local IKE
proposals (IKE SA responder matching remote proposals):
Dec 30 22:06:47.569014: "ikev2-cp"[2] 172.58.238.215:
1:IKE=AES_GCM_C_256-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 30 22:06:47.569029: "ikev2-cp"[2] 172.58.238.215:
2:IKE=AES_GCM_C_128-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 30 22:06:47.569041: "ikev2-cp"[2] 172.58.238.215:
3:IKE=AES_CBC_256-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 30 22:06:47.569052: "ikev2-cp"[2] 172.58.238.215:
4:IKE=AES_CBC_128-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 30 22:06:47.569083: "ikev2-cp"[2] 172.58.238.215 #3: proposal
2:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048 chosen from
r
emote proposals
1:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP2048
2:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP2048[first-match]
3:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP2048
Dec 30 22:06:47.573387: "ikev2-cp"[2] 172.58.238.215 #3: sent
IKE_SA_INIT reply {auth=IKEv2 cipher=AES_CBC_256
integ=HMAC_SHA2_256_128 prf
=HMAC_SHA2_256 group=MODP2048}

OK, so phase 1 passes.
However, it still looks like Windows is sending multiple proposals, 
while when using Set-VpnConnectionIPsecConfiguration I think only one 
should be sent.

Moreover:
The relevant parameters of Set-VpnConnectionIPsecConfiguration at this 
stage (phase 1) are:

-EncryptionMethod AES256
-IntegrityCheckMethod SHA384
-DHGroup Group14
(The relevant part in the libreswan config is the ike=... line or its 
default value if not present.)


-IntegrityCheckMethod SHA384 (as in you command below) does not match 
INTEG=HMAC_SHA2_256_128 which appears to be sent by Windows and logged 
as the accepted proposal by libreswan.



Dec 30 22:06:47.702497: "ikev2-cp"[2] 172.58.238.215 #3: processing
decrypted IKE_AUTH request: SK{IDi,CERT,CERTREQ,AUTH,CP,SA,TSi,TSr}
Dec 30 22:06:47.704044: "ikev2-cp"[2] 172.58.238.215 #3: certificate
verified OK: O=Example,CN=win10client.example.com
Dec 30 22:06:47.704103: "ikev2-cp"[2] 172.58.238.215 #3: IKEv2 mode
peer ID is ID_DER_ASN1_DN: 'CN=win10client.example.com, O=Example'
Dec 30 22:06:47.704669: "ikev2-cp"[2] 172.58.238.215 #3: authenticated
using RSA with SHA1
Client authentication passes too. It says "RSA with SHA1", which should 
map to authby=rsasig in your conf file.



Dec 30 22:06:47.718096: "ikev2-cp"[2] 172.58.238.215 #4: no local
proposal matches remote proposals
1:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA1_96;ESN=DISABLED
Dec 30 22:06:47.718122: "ikev2-cp"[2] 172.58.238.215 #4: IKE_AUTH
responder matching remote ESP/AH proposals failed, responder SA
processing returned STF_FAIL+v2N_NO_PROPOSAL_CHOSEN

This is phase 2 which fails.
The relevant parameters of Set-VpnConnectionIPsecConfiguration at this 
stage are:

-AuthenticationTransformConstants SHA256128
-CipherTransformConstants AES256
(The relevant part in the libreswan config is the esp=... line or its 
default value if not present.)


The log shows that the (failing) proposal sent by Windows is
1:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA1_96;ESN=DISABLED

This does not match the parameters of Set-VpnConnectionIPsecConfiguration.

It appears that Windows is not sending the proposals as required by 
Set-VpnConnectionIPsecConfiguration.
From the strongswan thread you posted earlier I remember the last 
comment about the manually tweaked registry entry overriding some 
parametres of 

Re: [Swan] Options for Windows clients

[Alex]

Hi,

> > certutil -S -c "Example CA" -n "win10client.example.com" \
> >  -s "O=Example,CN=win10client.example.com" -k rsa \
> >  -g 4096 -v 36 -d sql:/etc/ipsec.d -t ",," -1 -6 -8
> > "win10client.example.com"
>
> I see that the options -1 and -6 have no argument. Apparently this
> triggers an interactive loop to specify the respective properties.
> I think the client options should be:
> -1 "digitalSignature,keyEncipherment"
> -6 "clientAuth"
>
> For the server:
> -1 "digitalSignature,keyEncipherment"
> -6 "serverAuth,ipsecIKEIntermediate"

I believe it was either the first or second message on this thread I
asked if it was a problem that I was testing on the same network I was
located on, but perhaps that got overlooked :-) I recalled it being a
problem when I did this like fifteen years ago, lol. I've since
connected through my phone.

Anyway, it was either that or a combination of changes I made to the
certutil command that got me a bit further.

Dec 30 22:06:47.568952: "ikev2-cp"[2] 172.58.238.215: local IKE
proposals (IKE SA responder matching remote proposals):
Dec 30 22:06:47.569014: "ikev2-cp"[2] 172.58.238.215:
1:IKE=AES_GCM_C_256-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 30 22:06:47.569029: "ikev2-cp"[2] 172.58.238.215:
2:IKE=AES_GCM_C_128-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 30 22:06:47.569041: "ikev2-cp"[2] 172.58.238.215:
3:IKE=AES_CBC_256-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 30 22:06:47.569052: "ikev2-cp"[2] 172.58.238.215:
4:IKE=AES_CBC_128-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 30 22:06:47.569083: "ikev2-cp"[2] 172.58.238.215 #3: proposal
2:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048 chosen from
r
emote proposals
1:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP2048
2:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP2048[first-match]
3:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP2048
Dec 30 22:06:47.573387: "ikev2-cp"[2] 172.58.238.215 #3: sent
IKE_SA_INIT reply {auth=IKEv2 cipher=AES_CBC_256
integ=HMAC_SHA2_256_128 prf
=HMAC_SHA2_256 group=MODP2048}
Dec 30 22:06:47.702497: "ikev2-cp"[2] 172.58.238.215 #3: processing
decrypted IKE_AUTH request: SK{IDi,CERT,CERTREQ,AUTH,CP,SA,TSi,TSr}
Dec 30 22:06:47.704044: "ikev2-cp"[2] 172.58.238.215 #3: certificate
verified OK: O=Example,CN=win10client.example.com
Dec 30 22:06:47.704103: "ikev2-cp"[2] 172.58.238.215 #3: IKEv2 mode
peer ID is ID_DER_ASN1_DN: 'CN=win10client.example.com, O=Example'
Dec 30 22:06:47.704669: "ikev2-cp"[2] 172.58.238.215 #3: authenticated
using RSA with SHA1
Dec 30 22:06:47.718096: "ikev2-cp"[2] 172.58.238.215 #4: no local
proposal matches remote proposals
1:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA1_96;ESN=DISABLED
Dec 30 22:06:47.718122: "ikev2-cp"[2] 172.58.238.215 #4: IKE_AUTH
responder matching remote ESP/AH proposals failed, responder SA
processing returned STF_FAIL+v2N_NO_PROPOSAL_CHOSEN
Dec 30 22:06:47.718134: "ikev2-cp"[2] 172.58.238.215 #4: responding to
IKE_AUTH message (ID 1) from 172.58.238.215:43186 with encrypted
notification NO_PROPOSAL_CHOSEN
Dec 30 22:06:47.718209: "ikev2-cp"[2] 172.58.238.215 #4: state
transition 'Responder: process IKE_AUTH request' failed
Dec 30 22:06:47.718250: "ikev2-cp"[2] 172.58.238.215 #4: deleting
state (STATE_V2_IKE_AUTH_CHILD_R0) aged 0.00017s and NOT sending
notification

Windows reports the same "policy match error".

Here are the certutil commands I am now using:

# generate CA certificate
echo "Generating CA certificate"
certutil -z <(head -c 1024 /dev/urandom) \
-S -x -n "Example CA" -s "O=Example,CN=Example CA" -k rsa \
-g 4096 -v 36 -t "CT,," -2 -d /var/lib/ipsec/nss

# generate orion client certificate
echo "Generating orion client certificate..."
certutil -z <(head -c 1024 /dev/urandom) \
-S -c "Example CA" -n "orion.example.com" -s
"O=Example,CN=orion.example.com" \
-k rsa -g 4096 -v 120 -t ",," -1 -6 -8 "orion.example.com" -d
/var/lib/ipsec/nss \
--extSAN "ip:68.195.111.42" --keyUsage
"digitalSignature,keyEncipherment" \
--extKeyUsage "serverAuth,ipsecIKEIntermediate"

# generate Windows certificate
echo "Generating Windows certificate..."
certutil -z <(head -c 1024 /dev/urandom) \
-S -c "Example CA" -n "win10client.example.com" \
-s "O=Example,CN=win10client.example.com" -k rsa \
-g 4096 -v 120 -t ",," -8 "win10client.example.com" -d
/var/lib/ipsec/nss \
--extSAN "ip:68.195.111.42" --keyUsage
digitalSignature,keyEncipherment \
--extKeyUsage "clientAuth"

certutil -L -d /var/lib/ipsec/nss

pk12util -o win10client.example.com.p12 -n "win10client.example.com"
-d 

Re: [Swan] Options for Windows clients

[Manfred]

On 12/31/2020 2:52 AM, Manfred wrote:

Hi,


[...]

Do you mean the internal 192.168.1.1 address, so it's on the same
network as the Windows PC at 192.168.1.35? Eventually I'll need to do
this over the Internet, of course...



If 192.168.1.1 is the local IP address of the libreswan host[*], I'd say 
yes, assuming it is behind the router's NAT. This is to tell libreswan 
to identify itself as the "left" peer (because it will match that 
address against the interface that is receiving the initiator's request 
(from the win10 laptop)).
While you have both peers on the same network I think you may use the 
same local address on the win10 laptop as well and see if it connects - 
i.e. the connection configuration is OK and certs are OK too.
Correction: you may not (as Paul spotted). You have to bring the laptop 
outside in the cold (virtually)

___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] Options for Windows clients

[Manfred]

Hi,

On 12/31/2020 1:18 AM, Alex wrote:

Hi,


Referring to that example:

  leftcert=vpn.example.com
Here "vpn.example.com" must match the nickname of the server certificate
in the NSS database, which you created with certutil. This is how
libreswan knows which certificate to send to the client for server
authentication.

  leftid=@vpn.example.com
Here "vpn.example.com" is the VPN server ID that is advertised by
libreswan. "If preceded by @, the value is used as a literal string and
will not be resolved" (man ipsec.conf), however I don't know how Windows
uses this value or if tries to match it to the server name.
What is actually documented is that the server name that is configured
in the Windows connection properties must match the CN and
subjectAltName of the server certificate. Windows will verify that they
match, or refuse to connect (there appears to be some details about
whether to use CN, SAN or both - since you are creating the certificate
yourself, just set both matching for best compliance).
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/dd941612(v=ws.10)
http://www.carbonwind.net/blog/post/VPN-Reconnect-in-Windows-7-RC-redux.aspx


So I want to do something like this with certutil?

--extSAN type:name[,type:name]...
Create a Subject Alt Name extension with one or multiple names.

-type: directory, dn, dns, edi, ediparty, email, ip,
ipaddr, other, registerid, rfc822, uri, x400, x400addr


I always use openssl to generate my certs, so I'm not that familiar with 
certutil for this, however, checking the certutil manpage, I'd say yes, 
this is the more general option than -8 that you show below: --extSAN 
lets you specify any type of subjectAltName, -8 is specific to set a DNS 
subjectAltName.
Since you use a hostname, you need to specify type as DNS and the two 
are equivalent.




Also, I believe it was mentioned that /var/lib/ipsec/nss was the new
default location, but certutil still requires -d to explicitly define
that location. ipsec does not.


As Paul said, certutil has no default you need to specify the database 
location in every command.
ipsec uses the default location unless instructed otherwise (it used to 
be /etc/ipsec.d/, recent versions use /var/lib/ipsec/nss).





As I wrote in one of my previous replies, either you provide Windows
access to a proper DNS record, or you may configure the corresponding IP
address in C:\Windows\system32\drivers\etc\hosts


The process of creating the win10 cert on the libreswan page doesn't
specify anything about the server in the certutil process. Here is my
certutil:

certutil -S -c "Example CA" -n "win10client.example.com" \
 -s "O=Example,CN=win10client.example.com" -k rsa \
 -g 4096 -v 36 -d sql:/etc/ipsec.d -t ",," -1 -6 -8
"win10client.example.com"


I see that the options -1 and -6 have no argument. Apparently this 
triggers an interactive loop to specify the respective properties.

I think the client options should be:
-1 "digitalSignature,keyEncipherment"
-6 "clientAuth"

For the server:
-1 "digitalSignature,keyEncipherment"
-6 "serverAuth,ipsecIKEIntermediate"



That hostname doesn't resolve to anything. There's no way of knowing
what its IP will be at the time it connects, of course. Should I
instead be using the VPN server hostname for CN there instead?



"The process of creating the win10 cert" creates the client certificate, 
so it doesn't use server info. It should set CN as the client hostname, 
as it is correctly in the example.
"win10client.example.com" is not resolved, it doesn't need to have an 
actual DNS entry. You will find it in the log as part of the client 
identity.



As an alternative, it is also possible to use the server public IP
address as leftid, cert CN and SAN, and servername in the Windows
connection properties (with some caveats on how to specifically set the
IP address in SAN).


I think this was my problem previously when I received the
NO_PROPOSAL_GIVEN messages. I've since recreated the certs using the
orion.example.com which maps to the 68.192.111.42.


# ipsec auto --up ikev2-cp
029 "ikev2-cp": cannot initiate connection without knowing peer IP
address (kind=CK_TEMPLATE narrowing=yes)
036 "ikev2-cp": failed to initiate connection


Looking at your conn configuration below I think libreswan can't match
the local peer with left=68.195.111.42, and then complains that matching
it with right=%any is not allowed (if you want to specify a dynamic
address for the local peer you need to use %defaultroute)
Unless you intend your local peer to be "right", I still don't
understand why you don't use
  left=your.local.ip


Do you mean the internal 192.168.1.1 address, so it's on the same
network as the Windows PC at 192.168.1.35? Eventually I'll need to do
this over the Internet, of course...



If 192.168.1.1 is the local IP address of the libreswan host[*], I'd say 
yes, assuming it is behind the 

Re: [Swan] Options for Windows clients

[Paul Wouters]

On Dec 30, 2020, at 19:18, Alex  wrote:
> 
> 
> 
> So I want to do something like this with certutil?
> 
>   --extSAN type:name[,type:name]...
>   Create a Subject Alt Name extension with one or multiple names.
> 
>   -type: directory, dn, dns, edi, ediparty, email, ip,
> ipaddr, other, registerid, rfc822, uri, x400, 

In general yes.


> Also, I believe it was mentioned that /var/lib/ipsec/nss was the new
> default location, but certutil still requires -d to explicitly define
> that location. ipsec does not.

it’s the new libreswan location yes. Certutil is a tool from the nss package 
and it has no “default” (maybe current directory)


> 
>> As I wrote in one of my previous replies, either you provide Windows
>> access to a proper DNS record, or you may configure the corresponding IP
>> address in C:\Windows\system32\drivers\etc\hosts
> 
> The process of creating the win10 cert on the libreswan page doesn't
> specify anything about the server in the certutil process. Here is my
> certutil:
> 
> certutil -S -c "Example CA" -n "win10client.example.com" \
>-s "O=Example,CN=win10client.example.com" -k rsa \
>-g 4096 -v 36 -d sql:/etc/ipsec.d -t ",," -1 -6 -8
> "win10client.example.com"

Why use /etc/ipsec.d if your libreswan uses /vat/lib/ipsec/nss ?


> That hostname doesn't resolve to anything. There's no way of knowing
> what its IP will be at the time it connects, of course. Should I
> instead be using the VPN server hostname for CN there instead?

It’s fine for the clients to have a non-resolvable hostname.

> Do you mean the internal 192.168.1.1 address, so it's on the same
> network as the Windows PC at 192.168.1.35? Eventually I'll need to do
> this over the Internet, of course...

You CANNOT connect to the VPN server from the same subnet as the VPN server is 
in. Use your phone on LTE as hotspot for testing your Windows client if you 
need to.

> 
> Got it. I've updated it to reflect that now.
> Set-VpnConnectionIPsecConfiguration -ConnectionName ikev2-cp
> -EncryptionMethod AES256 -DHGroup Group14 -IntegrityCheckMethod SHA384
> -PfsGroup PFS2048 -AuthenticationTransformConstants SHA256128
> -CipherTransformConstants AES256

That seems good.

> 
>> Windows probably stops because of the issue above, or because it doesn't
>> recognize the reply from libreswan because of the issue below.
> 
> Is there any chance it produced some kind of error that more precisely
> defined the problem that maybe I missed?

The main issue was likely connecting from the same LAN. It would implode the 
tunnel so it seems Windows refuses it.

Paul
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] Options for Windows clients

[Alex]

Hi,

> Referring to that example:
>
>  leftcert=vpn.example.com
> Here "vpn.example.com" must match the nickname of the server certificate
> in the NSS database, which you created with certutil. This is how
> libreswan knows which certificate to send to the client for server
> authentication.
>
>  leftid=@vpn.example.com
> Here "vpn.example.com" is the VPN server ID that is advertised by
> libreswan. "If preceded by @, the value is used as a literal string and
> will not be resolved" (man ipsec.conf), however I don't know how Windows
> uses this value or if tries to match it to the server name.
> What is actually documented is that the server name that is configured
> in the Windows connection properties must match the CN and
> subjectAltName of the server certificate. Windows will verify that they
> match, or refuse to connect (there appears to be some details about
> whether to use CN, SAN or both - since you are creating the certificate
> yourself, just set both matching for best compliance).
> https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/dd941612(v=ws.10)
> http://www.carbonwind.net/blog/post/VPN-Reconnect-in-Windows-7-RC-redux.aspx

So I want to do something like this with certutil?

   --extSAN type:name[,type:name]...
   Create a Subject Alt Name extension with one or multiple names.

   -type: directory, dn, dns, edi, ediparty, email, ip,
ipaddr, other, registerid, rfc822, uri, x400, x400addr

Also, I believe it was mentioned that /var/lib/ipsec/nss was the new
default location, but certutil still requires -d to explicitly define
that location. ipsec does not.

> As I wrote in one of my previous replies, either you provide Windows
> access to a proper DNS record, or you may configure the corresponding IP
> address in C:\Windows\system32\drivers\etc\hosts

The process of creating the win10 cert on the libreswan page doesn't
specify anything about the server in the certutil process. Here is my
certutil:

certutil -S -c "Example CA" -n "win10client.example.com" \
-s "O=Example,CN=win10client.example.com" -k rsa \
-g 4096 -v 36 -d sql:/etc/ipsec.d -t ",," -1 -6 -8
"win10client.example.com"

That hostname doesn't resolve to anything. There's no way of knowing
what its IP will be at the time it connects, of course. Should I
instead be using the VPN server hostname for CN there instead?

> As an alternative, it is also possible to use the server public IP
> address as leftid, cert CN and SAN, and servername in the Windows
> connection properties (with some caveats on how to specifically set the
> IP address in SAN).

I think this was my problem previously when I received the
NO_PROPOSAL_GIVEN messages. I've since recreated the certs using the
orion.example.com which maps to the 68.192.111.42.

> > # ipsec auto --up ikev2-cp
> > 029 "ikev2-cp": cannot initiate connection without knowing peer IP
> > address (kind=CK_TEMPLATE narrowing=yes)
> > 036 "ikev2-cp": failed to initiate connection
>
> Looking at your conn configuration below I think libreswan can't match
> the local peer with left=68.195.111.42, and then complains that matching
> it with right=%any is not allowed (if you want to specify a dynamic
> address for the local peer you need to use %defaultroute)
> Unless you intend your local peer to be "right", I still don't
> understand why you don't use
>  left=your.local.ip

Do you mean the internal 192.168.1.1 address, so it's on the same
network as the Windows PC at 192.168.1.35? Eventually I'll need to do
this over the Internet, of course...

> As Paul mentioned, -Pfsgroup ECP384 defines an EC cipher, which would
> instruct Windows to look for an ECDSA certificate (and fail)
> -Pfsgroup and -DHGroup define ciphers that belong to the same family.
> They should both accept values from the DH group:
> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8
>
> For some reason Set-VpnConnectionipsecconfiguration uses different value
> identifiers for -Pfsgroup and -DHGroup.
> "-Pfsgroup PFS2048" and "-DHGroup Group14" both mean MODP2048

Got it. I've updated it to reflect that now.
Set-VpnConnectionIPsecConfiguration -ConnectionName ikev2-cp
-EncryptionMethod AES256 -DHGroup Group14 -IntegrityCheckMethod SHA384
-PfsGroup PFS2048 -AuthenticationTransformConstants SHA256128
-CipherTransformConstants AES256

> Windows probably stops because of the issue above, or because it doesn't
> recognize the reply from libreswan because of the issue below.

Is there any chance it produced some kind of error that more precisely
defined the problem that maybe I missed?

> >>> authby=ecdsa
> >>
> >> Avoid ecdsa with Windows as they seem to only support the old method that 
> >> libreswan doesn’t implement. Also if you use this, you cannot have RSA 
> >> based certificates as those cannot produce ECDSA signatures.
> >
> > I was experimenting based on your previous comment. Did I 

Re: [Swan] Options for Windows clients

[Manfred]

Hi,

On 12/30/2020 3:25 AM, Alex wrote:

Hi,


[...]


I've gotten past that NO_PROPOSAL_CHOSEN error, or at least it's not
producing it anymore.

Are the references to 'vpn.example.com' just labels, or is it a host
that has to resolve to an IP?
https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2


Referring to that example:

leftcert=vpn.example.com
Here "vpn.example.com" must match the nickname of the server certificate 
in the NSS database, which you created with certutil. This is how 
libreswan knows which certificate to send to the client for server 
authentication.


leftid=@vpn.example.com
Here "vpn.example.com" is the VPN server ID that is advertised by 
libreswan. "If preceded by @, the value is used as a literal string and 
will not be resolved" (man ipsec.conf), however I don't know how Windows 
uses this value or if tries to match it to the server name.
What is actually documented is that the server name that is configured 
in the Windows connection properties must match the CN and 
subjectAltName of the server certificate. Windows will verify that they 
match, or refuse to connect (there appears to be some details about 
whether to use CN, SAN or both - since you are creating the certificate 
yourself, just set both matching for best compliance).

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/dd941612(v=ws.10)
http://www.carbonwind.net/blog/post/VPN-Reconnect-in-Windows-7-RC-redux.aspx

As I wrote in one of my previous replies, either you provide Windows 
access to a proper DNS record, or you may configure the corresponding IP 
address in C:\Windows\system32\drivers\etc\hosts


As an alternative, it is also possible to use the server public IP 
address as leftid, cert CN and SAN, and servername in the Windows 
connection properties (with some caveats on how to specifically set the 
IP address in SAN).




I think I screwed up the leftid setting in the config. It couldn't
even find the config when I ran the following. Now it just reports it
can't connect (presumably because it's a mobile worker with a dynamic
IP).

# ipsec auto --up ikev2-cp
029 "ikev2-cp": cannot initiate connection without knowing peer IP
address (kind=CK_TEMPLATE narrowing=yes)
036 "ikev2-cp": failed to initiate connection


Looking at your conn configuration below I think libreswan can't match 
the local peer with left=68.195.111.42, and then complains that matching 
it with right=%any is not allowed (if you want to specify a dynamic 
address for the local peer you need to use %defaultroute)
Unless you intend your local peer to be "right", I still don't 
understand why you don't use

left=your.local.ip



Now Windows is saying "IKE failed to find valid machine certificate.
 install a valid certificate" but I've rebuilt the entire thing,
deleted the old certs and inserted a new pk12 cert as I've done
before. This strongswan post appears to indicate that "Maybe Windows
wants to do ECDSA and searches for such a certificate". Could that be
the case here?
https://wiki.strongswan.org/issues/3021 >
I've used the following two commands on the Windows side to build the
connection:

Add-VpnConnection -Name "ikev2-cp" -ServerAddress orion.example.com
-TunnelType "Ikev2" -PassThru -Force -EncryptionLevel "Required"
-AllUserConnection -AuthenticationMethod MachineCertificate

Set-VpnConnectionipsecconfiguration -connectionname "ikev2-cp"
-authenticationtransformconstants SHA256128 -ciphertransformconstants
AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA384 -Pfsgroup
ECP384 -DHGroup Group14 -PassThru -Force


As Paul mentioned, -Pfsgroup ECP384 defines an EC cipher, which would 
instruct Windows to look for an ECDSA certificate (and fail)
-Pfsgroup and -DHGroup define ciphers that belong to the same family. 
They should both accept values from the DH group:

https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8

For some reason Set-VpnConnectionipsecconfiguration uses different value 
identifiers for -Pfsgroup and -DHGroup.

"-Pfsgroup PFS2048" and "-DHGroup Group14" both mean MODP2048




Using ECP384 might cause it to not accept RSA certificates


Is that just for PFSGroup or all settings? The great thing about
standards is that there's so many to choose from 


This is for -Pfsgroup and -DHGroup


How can I be sure I'm generating the proper cert with certutil in the
first place?


When you generate a certificate the command defines the type of key, or 
uses a default that is documented in "man certutil".
After the fact you can inspect the certificate with the command I posted 
earlier (using the right path ofc). The output will tell a.o. the type 
of key used.




How much of the strongswan docs are applicable to libreswan? Was
libreswan formed from strongswan or openswan?


They are both forks of a common ancestor project, but they diverge along 
different paths.




Now trying to connect produces the 

Re: [Swan] Options for Windows clients

[Alex]

Hi,

> > Now Windows is saying "IKE failed to find valid machine certificate.
> >  install a valid certificate" but I've rebuilt the entire thing,
> > deleted the old certs and inserted a new pk12 cert as I've done
> > before. This strongswan post appears to indicate that "Maybe Windows
> > wants to do ECDSA and searches for such a certificate". Could that be
> > the case here?
> > https://wiki.strongswan.org/issues/3021
>
> Possible, I heard if you configure ECDH it won’t allow RSA based certs.

How can I be sure I'm generating the proper cert with certutil in the
first place?

How much of the strongswan docs are applicable to libreswan? Was
libreswan formed from strongswan or openswan?

> > I've used the following two commands on the Windows side to build the
> > connection:
> >
> > Add-VpnConnection -Name "ikev2-cp" -ServerAddress orion.example.com
> > -TunnelType "Ikev2" -PassThru -Force -EncryptionLevel "Required"
> > -AllUserConnection -AuthenticationMethod MachineCertificate
> >
> > Set-VpnConnectionipsecconfiguration -connectionname "ikev2-cp"
> > -authenticationtransformconstants SHA256128 -ciphertransformconstants
> > AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA384 -Pfsgroup
> > ECP384 -DHGroup Group14 -PassThru -Force
>
> Can you set both pfs group and DH group to group14 ?

The only choices are
https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=win10-ps
None
PFS1
PFS2
PFS2048
ECP256
ECP384
PFSMM
PFS24

> Using ECP384 might cause it to not accept RSA certificates

Is that just for PFSGroup or all settings? The great thing about
standards is that there's so many to choose from :-(

> >   authby=ecdsa
>
> Avoid ecdsa with Windows as they seem to only support the old method that 
> libreswan doesn’t implement. Also if you use this, you cannot have RSA based 
> certificates as those cannot produce ECDSA signatures.

I was experimenting based on your previous comment. Did I misinterpret it?

> - 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)

Shouldn't I be able to choose the algorithms and key sizes during the
certutil cert creation process that we know will work with Windows in
the first place?
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] Options for Windows clients

[Paul Wouters]

On Dec 29, 2020, at 21:25, Alex  wrote:
> 
> 
> This is fedora32. It appears the NSS database is physically in
> /var/lib/ipsec/nss while the certificates I've been creating are
> stored in /etc/ipsec.d/*.db. What's the difference?

The /etc one is the old location. Libreswan on fedora is compiled with the new 
location. You can configure nssdir= in ipsec.conf to point to your old location 
if you want.

> Why does ipsec
> appear to use /var/lib/ipsec/nss while certutil uses /etc/ipsec.d?

Certutil has no default. It is what you specify as options to it.


> It's also not necessary to preface it with sql:

Yes, the default was changed in nss to be sql: finally.




> 
> I've gotten past that NO_PROPOSAL_CHOSEN error, or at least it's not
> producing it anymore.
> 
> Are the references to 'vpn.example.com' just labels, or is it a host
> that has to resolve to an IP?
> https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2

For the right= on the client it needs to resolve in DNS or be an IP. The conn 
name is an arbitrary string.


> I think I screwed up the leftid setting in the config. It couldn't
> even find the config when I ran the following. Now it just reports it
> can't connect (presumably because it's a mobile worker with a dynamic
> IP).
> 
> # ipsec auto --up ikev2-cp
> 029 "ikev2-cp": cannot initiate connection without knowing peer IP
> address (kind=CK_TEMPLATE narrowing=yes)
> 036 "ikev2-cp": failed to initiate connection

Yes you cannot have initiate to %any

> Now Windows is saying "IKE failed to find valid machine certificate.
>  install a valid certificate" but I've rebuilt the entire thing,
> deleted the old certs and inserted a new pk12 cert as I've done
> before. This strongswan post appears to indicate that "Maybe Windows
> wants to do ECDSA and searches for such a certificate". Could that be
> the case here?
> https://wiki.strongswan.org/issues/3021

Possible, I heard if you configure ECDH it won’t allow RSA based certs.
> 
> I've used the following two commands on the Windows side to build the
> connection:
> 
> Add-VpnConnection -Name "ikev2-cp" -ServerAddress orion.example.com
> -TunnelType "Ikev2" -PassThru -Force -EncryptionLevel "Required"
> -AllUserConnection -AuthenticationMethod MachineCertificate
> 
> Set-VpnConnectionipsecconfiguration -connectionname "ikev2-cp"
> -authenticationtransformconstants SHA256128 -ciphertransformconstants
> AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA384 -Pfsgroup
> ECP384 -DHGroup Group14 -PassThru -Force

Can you set both pfs group and DH group to group14 ?

Using ECP384 might cause it to not accept RSA certificates


> Now trying to connect produces the following:
> 
> Dec 29 21:08:37.408754: | found policy =
> ECDSA+ENCRYPT+TUNNEL+PFS+DONT_REKEY+IKEV2_ALLOW+IKEV2_ALLOW_NARROWING+IKE_FRAG_ALLOW+ESN_NO
> (ikev2-cp)
> Dec 29 21:08:37.409050: | found connection: "ikev2-cp"[1] 192.168.1.35
> with policy ECDSA+IKEV2_ALLOW
> Dec 29 21:12:44.610613: "ikev2-cp"[5] 192.168.1.35 #16: proposal
> 2:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048 chosen from
> remote proposals
> 1:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP2048
> 2:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP2048[first-match]
> 3:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP2048
> 
> Dec 29 21:12:44.613300: "ikev2-cp"[5] 192.168.1.35 #16: sent
> IKE_SA_INIT reply {auth=IKEv2 cipher=AES_CBC_256
> integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
> 
> Then that's it.

Windows receives the answer and rejects the algorithms I guess. Or rejects the 
cert it now needs to use to create the next packet.


>   authby=ecdsa

Avoid ecdsa with Windows as they seem to only support the old method that 
libreswan doesn’t implement. Also if you use this, you cannot have RSA based 
certificates as those cannot produce ECDSA signatures.

Paul
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] Options for Windows clients

[Alex]

Hi,

> >> 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

This is fedora32. It appears the NSS database is physically in
/var/lib/ipsec/nss while the certificates I've been creating are
stored in /etc/ipsec.d/*.db. What's the difference? Why does ipsec
appear to use /var/lib/ipsec/nss while certutil uses /etc/ipsec.d?
It's also not necessary to preface it with sql:.

> >> 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).

I've gotten past that NO_PROPOSAL_CHOSEN error, or at least it's not
producing it anymore.

Are the references to 'vpn.example.com' just labels, or is it a host
that has to resolve to an IP?
https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2

I think I screwed up the leftid setting in the config. It couldn't
even find the config when I ran the following. Now it just reports it
can't connect (presumably because it's a mobile worker with a dynamic
IP).

# ipsec auto --up ikev2-cp
029 "ikev2-cp": cannot initiate connection without knowing peer IP
address (kind=CK_TEMPLATE narrowing=yes)
036 "ikev2-cp": failed to initiate connection

Now Windows is saying "IKE failed to find valid machine certificate.
 install a valid certificate" but I've rebuilt the entire thing,
deleted the old certs and inserted a new pk12 cert as I've done
before. This strongswan post appears to indicate that "Maybe Windows
wants to do ECDSA and searches for such a certificate". Could that be
the case here?
https://wiki.strongswan.org/issues/3021

I've used the following two commands on the Windows side to build the
connection:

Add-VpnConnection -Name "ikev2-cp" -ServerAddress orion.example.com
-TunnelType "Ikev2" -PassThru -Force -EncryptionLevel "Required"
-AllUserConnection -AuthenticationMethod MachineCertificate

Set-VpnConnectionipsecconfiguration -connectionname "ikev2-cp"
-authenticationtransformconstants SHA256128 -ciphertransformconstants
AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA384 -Pfsgroup
ECP384 -DHGroup Group14 -PassThru -Force

Now trying to connect produces the following:

Dec 29 21:08:37.408754: | found policy =
ECDSA+ENCRYPT+TUNNEL+PFS+DONT_REKEY+IKEV2_ALLOW+IKEV2_ALLOW_NARROWING+IKE_FRAG_ALLOW+ESN_NO
(ikev2-cp)
Dec 29 21:08:37.409050: | found connection: "ikev2-cp"[1] 192.168.1.35
with policy ECDSA+IKEV2_ALLOW
Dec 29 21:12:44.610613: "ikev2-cp"[5] 192.168.1.35 #16: proposal
2:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048 chosen from
remote proposals
1:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP2048
2:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP2048[first-match]
3:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP2048

Dec 29 21:12:44.613300: "ikev2-cp"[5] 192.168.1.35 #16: sent
IKE_SA_INIT reply {auth=IKEv2 cipher=AES_CBC_256
integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}

Then that's it.

> > - 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)

I've tried combinations of all of those. Here's what I have now. Left
is my libreswan server and right is my Win10 laptop.

conn ikev2-cp
left=68.195.111.42
leftcert=orion.example.com
leftid=@orion.example.com
leftsendcert=always
leftsubnet=0.0.0.0/0
leftrsasigkey=%cert
right=%any
rightaddresspool=192.168.6.2-192.168.6.254
rightca=%same
rightrsasigkey=%cert
modecfgdns=8.8.8.8,193.100.157.123
narrowing=yes
dpddelay=30
dpdtimeout=120
dpdaction=clear
auto=add
ikev2=insist
rekey=no
authby=ecdsa
fragmentation=yes
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [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

___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] Options for Windows clients

[Paul Wouters]

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


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


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:

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]
- 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

Re: [Swan] Options for Windows clients

[Alex]

Hi,

> >>> I've also added the "NegotiateDH2048_AES256" DWORD as per this doc:
> >>> https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2
> >>
> >> Instead of tweaking the registry, you might rather use the Windows
> >> Powershell, and specifically Set-VpnConnectionIPsecConfiguration:
> >> https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=win10-ps
> >>
> >> Fair warning: do not use ECP curves for DH group and PfsGroup, because
> >> you won't be able to connect from Win10 to libreswan with those.
> >> Also, do not use elliptic curves (ECDSA) certificates, because you won't
> >> be able to connect from Win10 to libreswan either.
> >> As a side note, Windows will reject its own certificate if it uses ECDSA

I followed the instructions to create a cert from this libreswan page:
https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2

How can I tell what type of cert I'm using?

> >> and the DH group does /not/ use EC ciphers, raising the (possibly
> >> confusing) error 13806.
> >
> > I've read over your comments multiple times and I'm really not sure I
> > understand.
> That is probably because my comment assumes some familiarity with IKE
> encryption and authentication methods.
>
>   This is the command I've now tried to use, unsuccessfully:
> >
> > Set-VpnConnectionIPsecConfiguration -ConnectionName "ikev2-cp"
> > -AuthenticationTransformConstants SHA256128 -CipherTransformConstants
> > AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA384 -PfsGroup
> > ECP384 -DHGroup ECP384 -PassThru -Force
>
> This command uses ECP curves for DH group and PfsGroup, which is what I
> said libreswan is *not* able to accept in this scenario.
>
> 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.

There doesn't appear to be any further references to modp1024, but I
have no idea what to do next.

> I also changed -IntegrityCheckMethod SHA384 to SHA256 because SHA384 is
> not part of the libreswan default set shown below. You may use ike=...
> and esp=... to configure that. See the ipsec.conf manpage for details
> about how to configure those. You may want to start with the default set
> though.

Based on the strongswan page, I've added the following:

  ike=aes256-sha384-prfsha384-modp2048
  esp=aes256gcm16-modp2048

> Here's some instruction on how to configure the windows connection to
> use machine certificates.
> https://wiki.strongswan.org/projects/strongswan/wiki/Win7Config
>
> Is it possible you have some "auto" property setting somewhere?

I have followed those instructions explicitly and multiple times.

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:

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

Thanks so much,
Alex
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] Options for Windows clients

[Paul Wouters]

On Dec 26, 2020, at 14:28, Manfred  wrote:
> 
> 
> This is the command I've now tried to use, unsuccessfully:
>> Set-VpnConnectionIPsecConfiguration -ConnectionName "ikev2-cp"
>> -AuthenticationTransformConstants SHA256128 -CipherTransformConstants
>> AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA384 -PfsGroup
>> ECP384 -DHGroup ECP384 -PassThru -Force
> 
> This command uses ECP curves for DH group and PfsGroup, which is what I said 
> libreswan is *not* able to accept in this scenario.

It seems Windows only uses the old style ECDSA authentication and libreswan 
only supports the new style RFC 7924 ECDSA authentication. It seems Windows 
switches to this based on ECDH vs DH Groups. 


> I assume you mean Windows is asking for username and password.
> My guess (beware, just a guess): you configured DHGroup=ECP384, and you don't 
> have an ECDSA certificate, therefore Windows is discarding the machine 
> certificate and falling back to some other authentication method.

That is possible, yes.

Paul


> Here's some instruction on how to configure the windows connection to use 
> machine certificates.
> https://wiki.strongswan.org/projects/strongswan/wiki/Win7Config
> 
> Is it possible you have some "auto" property setting somewhere?
> 
>> I'm at a complete loss now, and don't understand why there isn't
>> well-documented win10 instructions by this point.
> That's not a big surprise. Microsoft has a tradition of doing things their 
> own way, while *nix systems tend to follow the official standards.
> Specifically for VPN implementations, though, Microsoft made the choice to 
> implement IKEv2 according to IETF standards (which is a good thing), but to 
> me it seems that the details of such implementation have changed in the 
> evolution from initial Win7 release candidates to latest Win10 systems.
> 
>> What specifically is wrong with the instructions outlined for win10 in
>> the wiki? What more must be done there to make it work?
> I don't know if there is anything wrong with the instructions; as far as I am 
> concerned I discarded MODP1024 immediately because it is known to be unsafe, 
> and in order to use a safer cipher in Windows, I didn't touch the registry, I 
> used Set-VpnConnectionIPsecConfiguration instead.
> As far as I can see from your logs it looks like your change of the registry 
> to use MODP2048 is ineffective.
> 
 I'm also seeing the following in pluto.log:
 Dec 23 22:31:29.242048: "ikev2-cp"[4] 192.168.1.35 #7: no local
 proposal matches remote proposals
 1:IKE:ENCR=3DES;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
 2:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
 3:IKE:ENCR=3DES;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
 4:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
 5:IKE:ENCR=3DES;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024
 6:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024
 
 Dec 23 22:31:29.242065: "ikev2-cp"[4] 192.168.1.35 #7: responding to
 IKE_SA_INIT message (ID 0) from 192.168.1.35:500 with unencrypted
 notification NO_PROPOSAL_CHOSEN
>>> Indeed this is the denial that results in "Policy match error" on Windows.
>>> If these are the proposals offered by the Windows peer, they all use
>>> MODP1024, which is not allowed by libreswan.
>>> Somewhere around this log the local proposals should be listed; compare
>>> them with the Windows proposals and adjust accordingly.
>>> I'd say Set-VpnConnectionIPsecConfiguration is the more complete tool to
>>> configure the Windows side.
>>> On the libreswan side you may use ike=... and esp=...
>> I think this might be it:
>> Dec 24 10:22:38.203378: "ikev2-cp"[2] 192.168.1.35: local IKE
>> proposals (IKE SA responder matching remote proposals):
>> Dec 24 10:22:38.203412: "ikev2-cp"[2] 192.168.1.35:
>> 1:IKE=AES_GCM_C_256-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
>> Dec 24 10:22:38.203428: "ikev2-cp"[2] 192.168.1.35:
>> 2:IKE=AES_GCM_C_128-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
>> Dec 24 10:22:38.203433: "ikev2-cp"[2] 192.168.1.35:
>> 3:IKE=AES_CBC_256-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
>> Dec 24 10:22:38.203442: "ikev2-cp"[2] 192.168.1.35:
>> 4:IKE=AES_CBC_128-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
>> Dec 24 10:22:38.203457: "ikev2-cp"[2] 192.168.1.35 #7: no local
>> proposal matches remote proposals
>> 1:IKE:ENCR=3DES;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
>> 2:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
>> 3:IKE:ENCR=3DES;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
>> 

Re: [Swan] Options for Windows clients

[Manfred]

Hi,

On 12/26/2020 3:51 AM, Alex wrote:

Hi,


I've also added the "NegotiateDH2048_AES256" DWORD as per this doc:
https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2


Instead of tweaking the registry, you might rather use the Windows
Powershell, and specifically Set-VpnConnectionIPsecConfiguration:
https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=win10-ps

Fair warning: do not use ECP curves for DH group and PfsGroup, because
you won't be able to connect from Win10 to libreswan with those.
Also, do not use elliptic curves (ECDSA) certificates, because you won't
be able to connect from Win10 to libreswan either.
As a side note, Windows will reject its own certificate if it uses ECDSA
and the DH group does /not/ use EC ciphers, raising the (possibly
confusing) error 13806.


I've read over your comments multiple times and I'm really not sure I
understand.
That is probably because my comment assumes some familiarity with IKE 
encryption and authentication methods.


 This is the command I've now tried to use, unsuccessfully:


Set-VpnConnectionIPsecConfiguration -ConnectionName "ikev2-cp"
-AuthenticationTransformConstants SHA256128 -CipherTransformConstants
AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA384 -PfsGroup
ECP384 -DHGroup ECP384 -PassThru -Force


This command uses ECP curves for DH group and PfsGroup, which is what I 
said libreswan is *not* able to accept in this scenario.


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 also changed -IntegrityCheckMethod SHA384 to SHA256 because SHA384 is 
not part of the libreswan default set shown below. You may use ike=... 
and esp=... to configure that. See the ipsec.conf manpage for details 
about how to configure those. You may want to start with the default set 
though.





This is clearly wrong because now it's prompting for a username and
password instead of trying to use the cert I've imported.


At least the command /is/ doing something ;)

I assume you mean Windows is asking for username and password.
My guess (beware, just a guess): you configured DHGroup=ECP384, and you 
don't have an ECDSA certificate, therefore Windows is discarding the 
machine certificate and falling back to some other authentication method.


Here's some instruction on how to configure the windows connection to 
use machine certificates.

https://wiki.strongswan.org/projects/strongswan/wiki/Win7Config

Is it possible you have some "auto" property setting somewhere?



I'm at a complete loss now, and don't understand why there isn't
well-documented win10 instructions by this point.
That's not a big surprise. Microsoft has a tradition of doing things 
their own way, while *nix systems tend to follow the official standards.
Specifically for VPN implementations, though, Microsoft made the choice 
to implement IKEv2 according to IETF standards (which is a good thing), 
but to me it seems that the details of such implementation have changed 
in the evolution from initial Win7 release candidates to latest Win10 
systems.




What specifically is wrong with the instructions outlined for win10 in
the wiki? What more must be done there to make it work?
I don't know if there is anything wrong with the instructions; as far as 
I am concerned I discarded MODP1024 immediately because it is known to 
be unsafe, and in order to use a safer cipher in Windows, I didn't touch 
the registry, I used Set-VpnConnectionIPsecConfiguration instead.
As far as I can see from your logs it looks like your change of the 
registry to use MODP2048 is ineffective.





I'm also seeing the following in pluto.log:
Dec 23 22:31:29.242048: "ikev2-cp"[4] 192.168.1.35 #7: no local
proposal matches remote proposals
1:IKE:ENCR=3DES;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
2:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
3:IKE:ENCR=3DES;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
4:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
5:IKE:ENCR=3DES;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024
6:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024

Dec 23 22:31:29.242065: "ikev2-cp"[4] 192.168.1.35 #7: responding to
IKE_SA_INIT message (ID 0) from 192.168.1.35:500 with unencrypted
notification NO_PROPOSAL_CHOSEN

Indeed this is the denial that results in "Policy match error" on Windows.
If these are the proposals offered by the Windows peer, they all use
MODP1024, which is not allowed by libreswan.
Somewhere around this log the local proposals should be listed; compare
them with the Windows proposals and adjust 

Re: [Swan] Options for Windows clients

[Alex]

Hi,

> > I've also added the "NegotiateDH2048_AES256" DWORD as per this doc:
> > https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2
>
> Instead of tweaking the registry, you might rather use the Windows
> Powershell, and specifically Set-VpnConnectionIPsecConfiguration:
> https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=win10-ps
>
> Fair warning: do not use ECP curves for DH group and PfsGroup, because
> you won't be able to connect from Win10 to libreswan with those.
> Also, do not use elliptic curves (ECDSA) certificates, because you won't
> be able to connect from Win10 to libreswan either.
> As a side note, Windows will reject its own certificate if it uses ECDSA
> and the DH group does /not/ use EC ciphers, raising the (possibly
> confusing) error 13806.

I've read over your comments multiple times and I'm really not sure I
understand. This is the command I've now tried to use, unsuccessfully:

Set-VpnConnectionIPsecConfiguration -ConnectionName "ikev2-cp"
-AuthenticationTransformConstants SHA256128 -CipherTransformConstants
AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA384 -PfsGroup
ECP384 -DHGroup ECP384 -PassThru -Force

This is clearly wrong because now it's prompting for a username and
password instead of trying to use the cert I've imported.

I'm at a complete loss now, and don't understand why there isn't
well-documented win10 instructions by this point.

What specifically is wrong with the instructions outlined for win10 in
the wiki? What more must be done there to make it work?

> > I'm also seeing the following in pluto.log:
> > Dec 23 22:31:29.242048: "ikev2-cp"[4] 192.168.1.35 #7: no local
> > proposal matches remote proposals
> > 1:IKE:ENCR=3DES;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
> > 2:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
> > 3:IKE:ENCR=3DES;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
> > 4:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
> > 5:IKE:ENCR=3DES;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024
> > 6:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024
> >
> > Dec 23 22:31:29.242065: "ikev2-cp"[4] 192.168.1.35 #7: responding to
> > IKE_SA_INIT message (ID 0) from 192.168.1.35:500 with unencrypted
> > notification NO_PROPOSAL_CHOSEN
> Indeed this is the denial that results in "Policy match error" on Windows.
> If these are the proposals offered by the Windows peer, they all use
> MODP1024, which is not allowed by libreswan.
> Somewhere around this log the local proposals should be listed; compare
> them with the Windows proposals and adjust accordingly.
> I'd say Set-VpnConnectionIPsecConfiguration is the more complete tool to
> configure the Windows side.
> On the libreswan side you may use ike=... and esp=...

I think this might be it:

Dec 24 10:22:38.203378: "ikev2-cp"[2] 192.168.1.35: local IKE
proposals (IKE SA responder matching remote proposals):
Dec 24 10:22:38.203412: "ikev2-cp"[2] 192.168.1.35:
1:IKE=AES_GCM_C_256-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 24 10:22:38.203428: "ikev2-cp"[2] 192.168.1.35:
2:IKE=AES_GCM_C_128-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 24 10:22:38.203433: "ikev2-cp"[2] 192.168.1.35:
3:IKE=AES_CBC_256-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 24 10:22:38.203442: "ikev2-cp"[2] 192.168.1.35:
4:IKE=AES_CBC_128-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 24 10:22:38.203457: "ikev2-cp"[2] 192.168.1.35 #7: no local
proposal matches remote proposals
1:IKE:ENCR=3DES;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
2:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
3:IKE:ENCR=3DES;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
4:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
5:IKE:ENCR=3DES;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024
6:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024

I don't know under what circumstances those messages were produced,
though, because I can't get it to do it again.

I've also located this mini-howto that does a great job of explaining
the steps as well as providing a registry file to enable stronger
ciphers in win10.

https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/ikev2-howto.md

I'm really hoping you have some further ideas.

Thanks,
alex

>
> >
> > The win10 laptop I am using is connected to our internal network on
> > 192.168.1.35. The libreswan server has a public IP (which I've
> > specified as the endpoint for the win10 client), but also is the
> > Internet gateway for the win10 client as 192.168.1.1. Is it possible
> 

Re: [Swan] Options for Windows clients

[Nick Howitt]

  
  


On 24/12/2020 15:34, Alex wrote:


  
Hi,


  
The win10 laptop I am using is connected to our internal network on
192.168.1.35. The libreswan server has a public IP (which I've
specified as the endpoint for the win10 client), but also is the
Internet gateway for the win10 client as 192.168.1.1. Is it possible
to connect to the libreswan server while being on the same internal
network?

Shouldn't you use an FQDN rather than IP with the FQDN matching your certificate SAN. Then, on your LAN fix the DNS server to map the FQDN to 192.168.1.1.

  
  
I'm not sure I understand. You're saying I should be using real
hostnames and DNS instead of just an IP address? Where specifically
should I be doing this?

I don't know what I am talking about as I have never tried it, but
the docs say to use an FQDN as the SAN when creating a certificate.
I think it also says the FQDN must resolve to your server IP, so, if
connecting to your LAN, the FQDN should resolve to your server LAN
IP so you need to fix your internal DNS server. If connecting to
your WAN, the FQDN should resolve to your WAN IP. This is controlled
by your external DNS set up. If you then use the FQDN in Windows for
the connection (if you can - you couldn't many, many moons ago),
then everything resolves to the correct IP. It has nothing to do
with your Libreswan settings.

In Libreswan, I don't think it cares what the FQDN resolves to as
you are using it as a text identity for leftid and the SAN.

  

In my windows.conf:

conn ikev2-cp
left=68.195.111.42
leftcert=vpn.mycompany.com
leftid=@vpn.mycompany.com

Is vpn.mycompany.com supposed to resolve to something or is it just a
label? If so, should it be the 68.195.111.42 address?

I believe the real problem is here:
Dec 24 10:26:32.076033: packet from 192.168.1.35:500:
ISAKMP_v2_IKE_SA_INIT message received on 68.195.193.42:500 but no
suitable connection found with IKEv2 policy
Dec 24 10:26:32.076091: packet from 192.168.1.35:500: responding to
IKE_SA_INIT (34) message (Message ID 0) with unencrypted notification
NO_PROPOSAL_CHOSEN

I've followed the directions described here to create a registry
entry. I've also now added the esp= and ike= lines referenced in this
doc, although it's unclear if that's what I was supposed to do, and it
still doesn't work.
https://libreswan.org/wiki/FAQ#Microsoft_Windows_connection_attempts_fail_with_NO_POROPOSAL_CHOSEN


  
FWIW an internal LAN of 192.168.1.0/24 or 192.168.0.0/24 is lousy for a roadwarrior as there is a high chance it will be the same as the local LAN he is connecting from, once he is on the road.

  
  
Yes, very true. This 192.168.1.0/24 network was created more than
twenty years ago. We're also using 192.168.6.0/24 for the mobile
workers, so hopefully that minimizes the potential for conflict.



  

___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] Options for Windows clients

[Manfred]

Hi,

Based on my recent experience:

On 12/24/2020 4:41 AM, Alex wrote:

Hi,


Is there documentation available on how to configure
it with libreswan?


Yes, see our libreswan examples on the website.


I followed the examples outlined on this page, including importing the
pkcs12 file with ipsec and building an ipsec.conf for the VPN server.
https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2

I was able to import the cert successfully on win10. When I try to
connect, I receive a "Policy match error". How do I troubleshoot this?
I have made the registry changes for "Windows Certificate
requirements" and "L2TP / IPsec with the server behind NAT" as per
this doc:
https://libreswan.org/wiki/Interoperability#Windows_Certificate_requirements

I've also added the "NegotiateDH2048_AES256" DWORD as per this doc:
https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2


Instead of tweaking the registry, you might rather use the Windows 
Powershell, and specifically Set-VpnConnectionIPsecConfiguration:

https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=win10-ps

Fair warning: do not use ECP curves for DH group and PfsGroup, because 
you won't be able to connect from Win10 to libreswan with those.
Also, do not use elliptic curves (ECDSA) certificates, because you won't 
be able to connect from Win10 to libreswan either.
As a side note, Windows will reject its own certificate if it uses ECDSA 
and the DH group does /not/ use EC ciphers, raising the (possibly 
confusing) error 13806.




I'm also seeing the following in pluto.log:
Dec 23 22:31:29.242048: "ikev2-cp"[4] 192.168.1.35 #7: no local
proposal matches remote proposals
1:IKE:ENCR=3DES;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
2:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
3:IKE:ENCR=3DES;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
4:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
5:IKE:ENCR=3DES;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024
6:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024

Dec 23 22:31:29.242065: "ikev2-cp"[4] 192.168.1.35 #7: responding to
IKE_SA_INIT message (ID 0) from 192.168.1.35:500 with unencrypted
notification NO_PROPOSAL_CHOSEN

Indeed this is the denial that results in "Policy match error" on Windows.
If these are the proposals offered by the Windows peer, they all use 
MODP1024, which is not allowed by libreswan.
Somewhere around this log the local proposals should be listed; compare 
them with the Windows proposals and adjust accordingly.
I'd say Set-VpnConnectionIPsecConfiguration is the more complete tool to 
configure the Windows side.

On the libreswan side you may use ike=... and esp=...



The win10 laptop I am using is connected to our internal network on
192.168.1.35. The libreswan server has a public IP (which I've
specified as the endpoint for the win10 client), but also is the
Internet gateway for the win10 client as 192.168.1.1. Is it possible
to connect to the libreswan server while being on the same internal
network?


I'd guess it is possible to set up the entire connection locally, using 
local IP's everywhere. Watch out for address clashes, and set up 
rightaddresspool to a separate subnet.




The network looks like this:

68.195.111.42 <--> 192.168.1.1 <--> internal network with win10 client
192.168.1.35

If not, is there another way to test this without having to go outside
the local network?

Here is my windows.conf config file:

conn ikev2-cp
 left=68.195.111.42

From the ipsec.conf manpage:
"If using IP addresses in combination with NAT, always use the actual 
local machine's (NATed) IP address, and if the remote (eg right=) is 
NATed as well, the remote's public (not NATed) IP address. Note that 
this makes the configuration no longer symmetrical on both sides, so you 
cannot use an identical configuration file on both hosts"

This means you should use:
left=your.local.ip (e.g. 192.168.xxx.xxx)
An alternative is also %defaultroute (from the manpage as well)


 leftcert=vpn.mycompany.com
 leftid=@vpn.mycompany.com

Better use example.com for examples.
If you use leftid=@fqdn then:
- your server certificate's subject should have CN=the.same.fqdn
- your server certificate should have subjectAltName=the.same.fqdn
- your Windows client should connect to the.same.fqdn; you may set up a 
proper DNS entry or use C:\windows\system32\drivers\etc\hosts to map to 
the corresponding IP address (this is the windows counterpart of 
/etc/hosts).


As an alternative, you may use leftid=your.public.ip.address, and use 
that IP address everyehere in place of the fqdn (unless you set up the 
entire connection locally and then use the local address everywhere as 
said above)
The rationale is that the Win10 peer will validate the server 
certificate name against the destination it is trying to connect to:

Re: [Swan] Options for Windows clients

[Alex]

Hi,

> The win10 laptop I am using is connected to our internal network on
> 192.168.1.35. The libreswan server has a public IP (which I've
> specified as the endpoint for the win10 client), but also is the
> Internet gateway for the win10 client as 192.168.1.1. Is it possible
> to connect to the libreswan server while being on the same internal
> network?
>
> Shouldn't you use an FQDN rather than IP with the FQDN matching your 
> certificate SAN. Then, on your LAN fix the DNS server to map the FQDN to 
> 192.168.1.1.

I'm not sure I understand. You're saying I should be using real
hostnames and DNS instead of just an IP address? Where specifically
should I be doing this?

In my windows.conf:

conn ikev2-cp
left=68.195.111.42
leftcert=vpn.mycompany.com
leftid=@vpn.mycompany.com

Is vpn.mycompany.com supposed to resolve to something or is it just a
label? If so, should it be the 68.195.111.42 address?

I believe the real problem is here:
Dec 24 10:26:32.076033: packet from 192.168.1.35:500:
ISAKMP_v2_IKE_SA_INIT message received on 68.195.193.42:500 but no
suitable connection found with IKEv2 policy
Dec 24 10:26:32.076091: packet from 192.168.1.35:500: responding to
IKE_SA_INIT (34) message (Message ID 0) with unencrypted notification
NO_PROPOSAL_CHOSEN

I've followed the directions described here to create a registry
entry. I've also now added the esp= and ike= lines referenced in this
doc, although it's unclear if that's what I was supposed to do, and it
still doesn't work.
https://libreswan.org/wiki/FAQ#Microsoft_Windows_connection_attempts_fail_with_NO_POROPOSAL_CHOSEN

> FWIW an internal LAN of 192.168.1.0/24 or 192.168.0.0/24 is lousy for a 
> roadwarrior as there is a high chance it will be the same as the local LAN he 
> is connecting from, once he is on the road.

Yes, very true. This 192.168.1.0/24 network was created more than
twenty years ago. We're also using 192.168.6.0/24 for the mobile
workers, so hopefully that minimizes the potential for conflict.
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] Options for Windows clients

[Nick Howitt]

  
  


On 24/12/2020 03:41, Alex wrote:


  
Hi,


  

  Is there documentation available on how to configure
it with libreswan?



Yes, see our libreswan examples on the website.

  
  
I followed the examples outlined on this page, including importing the
pkcs12 file with ipsec and building an ipsec.conf for the VPN server.
https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2

I was able to import the cert successfully on win10. When I try to
connect, I receive a "Policy match error". How do I troubleshoot this?
I have made the registry changes for "Windows Certificate
requirements" and "L2TP / IPsec with the server behind NAT" as per
this doc:
https://libreswan.org/wiki/Interoperability#Windows_Certificate_requirements

I've also added the "NegotiateDH2048_AES256" DWORD as per this doc:
https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2

I'm also seeing the following in pluto.log:
Dec 23 22:31:29.242048: "ikev2-cp"[4] 192.168.1.35 #7: no local
proposal matches remote proposals
1:IKE:ENCR=3DES;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
2:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
3:IKE:ENCR=3DES;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
4:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
5:IKE:ENCR=3DES;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024
6:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024

Dec 23 22:31:29.242065: "ikev2-cp"[4] 192.168.1.35 #7: responding to
IKE_SA_INIT message (ID 0) from 192.168.1.35:500 with unencrypted
notification NO_PROPOSAL_CHOSEN

The win10 laptop I am using is connected to our internal network on
192.168.1.35. The libreswan server has a public IP (which I've
specified as the endpoint for the win10 client), but also is the
Internet gateway for the win10 client as 192.168.1.1. Is it possible
to connect to the libreswan server while being on the same internal
network?


Shouldn't you use an FQDN rather than IP with the FQDN matching your
certificate SAN. Then, on your LAN fix the DNS server to map the
FQDN to 192.168.1.1.

FWIW an internal LAN of 192.168.1.0/24 or 192.168.0.0/24 is lousy
for a roadwarrior as there is a high chance it will be the same as
the local LAN he is connecting from, once he is on the road.

  The network looks like this:

68.195.111.42 <--> 192.168.1.1 <--> internal network with win10 client
192.168.1.35

If not, is there another way to test this without having to go outside
the local network?

Here is my windows.conf config file:

conn ikev2-cp
left=68.195.111.42
leftcert=vpn.mycompany.com
leftid=@vpn.mycompany.com
leftsendcert=always
leftsubnet=0.0.0.0/0
leftrsasigkey=%cert
right=%any
rightaddresspool=192.168.6.2-192.168.6.254
rightca=%same
rightrsasigkey=%cert
modecfgdns=8.8.8.8,8.8.4.4
narrowing=yes
dpddelay=30
dpdtimeout=120
dpdaction=clear
auto=add
ikev2=insist
rekey=no
fragmentation=yes
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan



  

___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] Options for Windows clients

[Alex]

Hi,

> > Is there documentation available on how to configure
> > it with libreswan?
>
> Yes, see our libreswan examples on the website.

I followed the examples outlined on this page, including importing the
pkcs12 file with ipsec and building an ipsec.conf for the VPN server.
https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2

I was able to import the cert successfully on win10. When I try to
connect, I receive a "Policy match error". How do I troubleshoot this?
I have made the registry changes for "Windows Certificate
requirements" and "L2TP / IPsec with the server behind NAT" as per
this doc:
https://libreswan.org/wiki/Interoperability#Windows_Certificate_requirements

I've also added the "NegotiateDH2048_AES256" DWORD as per this doc:
https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2

I'm also seeing the following in pluto.log:
Dec 23 22:31:29.242048: "ikev2-cp"[4] 192.168.1.35 #7: no local
proposal matches remote proposals
1:IKE:ENCR=3DES;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
2:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
3:IKE:ENCR=3DES;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
4:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
5:IKE:ENCR=3DES;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024
6:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024

Dec 23 22:31:29.242065: "ikev2-cp"[4] 192.168.1.35 #7: responding to
IKE_SA_INIT message (ID 0) from 192.168.1.35:500 with unencrypted
notification NO_PROPOSAL_CHOSEN

The win10 laptop I am using is connected to our internal network on
192.168.1.35. The libreswan server has a public IP (which I've
specified as the endpoint for the win10 client), but also is the
Internet gateway for the win10 client as 192.168.1.1. Is it possible
to connect to the libreswan server while being on the same internal
network?

The network looks like this:

68.195.111.42 <--> 192.168.1.1 <--> internal network with win10 client
192.168.1.35

If not, is there another way to test this without having to go outside
the local network?

Here is my windows.conf config file:

conn ikev2-cp
left=68.195.111.42
leftcert=vpn.mycompany.com
leftid=@vpn.mycompany.com
leftsendcert=always
leftsubnet=0.0.0.0/0
leftrsasigkey=%cert
right=%any
rightaddresspool=192.168.6.2-192.168.6.254
rightca=%same
rightrsasigkey=%cert
modecfgdns=8.8.8.8,8.8.4.4
narrowing=yes
dpddelay=30
dpdtimeout=120
dpdaction=clear
auto=add
ikev2=insist
rekey=no
fragmentation=yes
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan

Re: [Swan] Options for Windows clients

[Paul Wouters]

On Dec 22, 2020, at 10:08, Alex  wrote:
> 
> Hi,
> 
> I have a libreswan-4.1 install on fedora32 and would like to connect
> some remote road warriors with Windows clients so I may connect them
> to the corporate network to access our asterisk phone system.

Please upgrade to the latest 4.2rc1 that was pushed into fedora two days ago to 
avoid an nss bug causing libreswan to restart.

You can configure windows to use an IKEv2 VPN or use the older IKEv1 based 
IPsec/L2TP.


> Will WireGuard work?

WireGuard is not IKE/IPsec based. It requires a third party client instead of 
the build in OS IPsec client. Libreswan is also not a WireGuard implementation.


> Is there documentation available on how to configure
> it with libreswan?

Yes, see our libreswan examples on the website.


> Are there other freely available clients?

IKE/IPsec is the only native VPN client for Windows. Everything else requires 
third party clients.

Paul
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan