search

libreswan / libreswan

libreswan
https://libreswan.org/
Other
857 stars 225 forks source link

RFE: Assign specific IP to specific client for ikev2 #487

Closed gspannu closed 1 year ago

gspannu commented 3 years ago

How can I assign specific IP addresses to specific clients while using ikev2?

My ikev2.conf file looks like below... I have the address pool 10.10.10.10 - 10.10.10.100 allocated for ikev2 clients; but I want to assign specific IPs to specific clients; so that I can manage those better.

conn ikev2-cp
  left=%defaultroute
  leftcert=x.y.z.a
  leftsendcert=always
  leftsubnet=0.0.0.0/0
  leftrsasigkey=%cert
  right=%any
  rightid=%fromcert
  rightaddresspool=10.10.10.10-10.10.10.100
  rightca=%same
  rightrsasigkey=%cert
  narrowing=yes
  dpddelay=30
  dpdtimeout=120
  dpdaction=clear
  auto=add
  ikev2=insist
  rekey=no
  pfs=no
  ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1
  phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes128-sha2,aes256-sha2
  ikelifetime=24h
  salifetime=24h
  encapsulation=yes
  leftid=x.y.z.a
  modecfgdns="k.l.m.n"
  mobike=yes

I am running an Adblocker & Unbound on the VPN server; and wish to control individual clients that connect to the ikev2 VPN server; hence need the specific IP addresses of these clients. With the above configuration, each client just gets the next available IP when it connects; so I cannot distinguish which client has which IP address.

Thank you...

letoams commented 3 years ago

That feature is not available yet. It wouldn’t be too hard to add based on me file with simple : <ip’s> format to overrule the “first free ip” code.

Sent using a virtual keyboard on a phone

On Aug 9, 2021, at 06:39, gspannu @.***> wrote:

 How can I assign specific IP addresses to specific clients while using ikev2?

My ikev2.conf file looks like below... I have the address pool 10.10.10.10 - 10.10.10.100 allocated for ikev2 clients; but I want to assign specific IPs to specific clients; so that I can manage those better.

conn ikev2-cp left=%defaultroute leftcert=x.y.z.a leftsendcert=always leftsubnet=0.0.0.0/0 leftrsasigkey=%cert right=%any rightid=%fromcert rightaddresspool=10.10.10.10-10.10.10.100 rightca=%same rightrsasigkey=%cert narrowing=yes dpddelay=30 dpdtimeout=120 dpdaction=clear auto=add ikev2=insist rekey=no pfs=no ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1 phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes128-sha2,aes256-sha2 ikelifetime=24h salifetime=24h encapsulation=yes leftid=x.y.z.a modecfgdns="k.l.m.n" mobike=yes

I am running an Adblocker & Unbound on the VPN server; and wish to control individual clients that connect to the ikev2 VPN server; hence need the specific IP addresses of these clients. With the above configuration, each client just gets the next available IP when it connects; so I cannot distinguish which client has which IP address.

Thank you...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

bleve commented 3 years ago

There is nice work-around by using either OU= in certificates or per person connection (for static ip setup). You just need to have proper certificate structure.

You could do another connection where you match certain OU in certificate only.

rightid="C=CC, O=Your ourganization, OU=Wanted organization unit, CN=*" rightaddresspool=10.10.10.101-10.10.10.200

Or you can do several conns per person:

rightid="CN=oneperson" rightaddresspool=10.10.101-10.10.10.200

and rightid="CN=otherperson" rightaddresspool=10.10.101.10.10.100.200

That all depends on your certificate structure. Good planning before deployment helps you big time here. Just remember rightid= with subject labels in it must match all subject label fields there are in certificate, and order must be same.

gspannu commented 3 years ago

There is nice work-around by using either OU= in certificates or per person connection (for static ip setup). You just need to have proper certificate structure.

You could do another connection where you match certain OU in certificate only.

rightid="C=CC, O=Your ourganization, OU=Wanted organization unit, CN=*" rightaddresspool=10.10.10.101-10.10.10.200

Or you can do several conns per person:

rightid="CN=oneperson" rightaddresspool=10.10.101-10.10.10.200

and rightid="CN=otherperson" rightaddresspool=10.10.101.10.10.100.200

That all depends on your certificate structure. Good planning before deployment helps you big time here. Just remember rightid= with subject labels in it must match all subject label fields there are in certificate, and order must be same.

Wow! I think this approach may just work for me !

I am currently using certificates generated per machine (so they are unique for each user for each machine). Every client is provided a unique certificate.

As an example, my client generation command looks like this...

certutil -z <(head -c 1024 /dev/urandom) \
    -S -c "Guru VPNCA" -n "Machine001" \
    -s "O=Secure Systems,CN=Machine001" \
    -k rsa -g 3072 -v 12 \
    -d sql:/etc/ipsec.d -t ",," \
    --keyUsage digitalSignature,keyEncipherment \
    --extKeyUsage serverAuth,clientAuth -8 "Machine001"

certutil -z <(head -c 1024 /dev/urandom) \
    -S -c "Guru VPNCA" -n "Machine002" \
    -s "O=Secure Systems,CN=Machine002" \
    -k rsa -g 3072 -v 12 \
    -d sql:/etc/ipsec.d -t ",," \
    --keyUsage digitalSignature,keyEncipherment \
    --extKeyUsage serverAuth,clientAuth -8 "Machine002"

As per your suggestion, my ikev2.conf file should look like this below...

conn ikev2-cp
  left=%defaultroute
  leftcert=x.y.z.a
  leftsendcert=always
  leftsubnet=0.0.0.0/0
  leftrsasigkey=%cert
  right=%any

  rightid="CN=Machine001"
  rightaddresspool=10.10.10.11-10.10.10.11
  rightid="CN=Machine002"
  rightaddresspool=10.10.10.12-10.10.10.12

 rightca=%same
  rightrsasigkey=%cert
  narrowing=yes
  dpddelay=30
  dpdtimeout=120
  dpdaction=clear
  auto=add
  ikev2=insist
  rekey=no
  pfs=no
  ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1
  phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes128-sha2,aes256-sha2
  ikelifetime=24h
  salifetime=24h
  encapsulation=yes
  leftid=x.y.z.a
  modecfgdns="k.l.m.n"
  mobike=yes

Q1) Would the above work or have I misunderstood what you are suggesting? I was not aware that the ikev2.conf file could contain multiple rightid and rightaddresspool lines. How does the system match the id with the pool, purely in sequence. .... or am I completely off target?

Q2) Would the above ensure that I always get 10.10.10.11 assigned to certificate Machine001 and 10.10.10.12 assigned to Machine002?

Your assistance in this is much appreciated... Many thanks.

gspannu commented 3 years ago

That feature is not available yet. It wouldn’t be too hard to add based on me file with simple : <ip’s> format to overrule the “first free ip” code. Sent using a virtual keyboard on a phone …

Any idea if this would be implemented? And when? This feature would make the ikev2 implementation so complete (as one can already do static ips per client in ikev1).

letoams commented 3 years ago

On Mon, 9 Aug 2021, gspannu wrote:

  That feature is not available yet. It wouldn’t be too hard to add based on me file with simple :
  <ip’s> format to overrule the “first free ip” code. Sent using a virtual keyboard on a phone
  …

Any idea if this would be implemented? And when? This feature would make the ikev2 implementation so complete (as one can already do static ips per client in ikev1).

We are currently busy working on other things, but we always welcome patches and actively help those who are trying to write patches.

I marked the issue as RFE, so hopefully one of the developers, a student or someone else will pick this up as a nice short term project.

Paul

bleve commented 3 years ago

You need multiple connections. And your rightid= must match exactly certificate subject.

letoams commented 3 years ago

On Mon, 9 Aug 2021, bleve wrote:

You need multiple connections. And your rightid= must match exactly certificate subject.

I would recommend that you give proper Subject Alt Name (SAN) entries to the certificates use that you use that as IKE ID for matching. This also avoids matching IDs with the long DN.

gspannu commented 3 years ago

@letoams @bleve

I followed (or tried to) your instructions and created this ikev2.conf file...

conn ikev2-shared
 left=%defaultroute
 leftcert=x.y.z.a
 leftsendcert=always
 leftsubnet=0.0.0.0/0
 leftrsasigkey=%cert
 right=%any
 rightca=%same
 rightrsasigkey=%cert
 narrowing=yes
 dpddelay=30
 dpdtimeout=120
 dpdaction=clear
 auto=add
 ikev2=insist
 rekey=no
 pfs=no
 ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1
 phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes128-sha2,aes256-sha2
 ikelifetime=24h
 salifetime=24h
 encapsulation=yes
 leftid=x.yx.z.a
 modecfgdns="k.l.m.n"

conn test001
 rightid="SAN=test001"
 rightaddresspool=10.10.10.11-10.10.10.15
 also=ikev2-shared

conn test002
 rightid="CN=test002"
 rightaddresspool=10.10.10.21-10.10.10.25
 also=ikev2-shared

I also changed my client generation command to include the SAN

certutil -z <(head -c 1024 /dev/urandom) \
    -S -c "Guru VPNCA" -n "test001" \
    -s "O=Secure Systems,CN=test001" \
    -k rsa -g 3072 -v 12 \
    -d sql:/etc/ipsec.d -t ",," \
    --keyUsage digitalSignature,keyEncipherment \
    --extSAN "dns:test001" \
    --extKeyUsage serverAuth,clientAuth -8 "test001"

certutil -z <(head -c 1024 /dev/urandom) \
    -S -c "Guru VPNCA" -n "test002" \
    -s "O=Secure Systems,CN=test002" \
    -k rsa -g 3072 -v 12 \
    -d sql:/etc/ipsec.d -t ",," \
    --keyUsage digitalSignature,keyEncipherment \
    --extSAN "dns:test002" \
    --extKeyUsage serverAuth,clientAuth -8 "test002"

However, I am not able to connect either test001 or test002.

Just to check that my connection is all working, if I replace the conn test001 and test002 with the below, it all works and assigns dynamic IP addresses (as expected)

conn ikev2
 rightid=%fromcert
 rightaddresspool=10.10.10.200-10.10.10.254
 also=ikev2-shared

Can you please help what I am doing wrong? a) Am I specifying the SAN the incorrect way while generating the client certificate or b) is there something wrong with the way I am checking rightid value or c) something else that I am missing?

Any help would be much appreciated?

Thanks...

letoams commented 3 years ago

Use @.*** for your SAN

Sent using a virtual keyboard on a phone

On Aug 9, 2021, at 19:37, gspannu @.***> wrote:

 @letoams @bleve

I followed (or tried to) your instructions and created this ikev2.conf file...

conn ikev2-shared left=%defaultroute leftcert=x.y.z.a leftsendcert=always leftsubnet=0.0.0.0/0 leftrsasigkey=%cert right=%any rightca=%same rightrsasigkey=%cert narrowing=yes dpddelay=30 dpdtimeout=120 dpdaction=clear auto=add ikev2=insist rekey=no pfs=no ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1 phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes128-sha2,aes256-sha2 ikelifetime=24h salifetime=24h encapsulation=yes leftid=x.yx.z.a modecfgdns="k.l.m.n"

conn test001 rightid="SAN=test001" rightaddresspool=10.10.10.11-10.10.10.15 also=ikev2-shared

conn test002 rightid="CN=test002" rightaddresspool=10.10.10.21-10.10.10.25 also=ikev2-shared I also changed my client generation command to include the SAN

certutil -z <(head -c 1024 /dev/urandom) \ -S -c "Guru VPNCA" -n "test001" \ -s "O=Secure Systems,CN=test001" \ -k rsa -g 3072 -v 12 \ -d sql:/etc/ipsec.d -t ",," \ --keyUsage digitalSignature,keyEncipherment \ --extSAN "dns:test001" \ --extKeyUsage serverAuth,clientAuth -8 "test001"

certutil -z <(head -c 1024 /dev/urandom) \ -S -c "Guru VPNCA" -n "test002" \ -s "O=Secure Systems,CN=test002" \ -k rsa -g 3072 -v 12 \ -d sql:/etc/ipsec.d -t ",," \ --keyUsage digitalSignature,keyEncipherment \ --extSAN "dns:test002" \ --extKeyUsage serverAuth,clientAuth -8 "test002" However, I am not able to connect either test001 or test002.

Just to check that my connection is all working, if I replace the conn test001 and test002 with the below, it all works and assigns dynamic IP addresses (as expected)

conn ikev2 rightid=%fromcert rightaddresspool=10.10.10.200-10.10.10.254 also=ikev2-shared Can you please help what I am doing wrong? a) Am I specifying the SAN the incorrect way while generating the client certificate or b) is there something wrong with the way I am checking rightid value or c) something else that I am missing?

Any help would be much appreciated?

Thanks...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

gspannu commented 3 years ago

Use @.*** for your SAN Sent using a virtual keyboard on a phone …

Sorry, man. Did not understand. It is 1:00am here and maybe my brain isn't working - but I couldn't fathom what to put in the SAN. Can you please be more specific? Thanks.

What do I change in my command here?

certutil -z <(head -c 1024 /dev/urandom) \ -S -c "Guru VPNCA" -n "test001" \ -s "O=Secure Systems,CN=test001" \ -k rsa -g 3072 -v 12 \ -d sql:/etc/ipsec.d -t ",," \ --keyUsage digitalSignature,keyEncipherment \ --extSAN "dns:test001" \ --extKeyUsage serverAuth,clientAuth -8 "test001"

And what do I change in my ikev2.conf file?

conn test001 rightid="SAN=test001" rightaddresspool=10.10.10.11-10.10.10.15 also=ikev2-shared

Apologies... if my questions are too basic?

letoams commented 3 years ago

If your SAN is DNS:somename Use: @.***

The “@“ symbol is used to prevent an actual DNS lookup and using the IP address found in DNS and to use the following string literally.

Sent using a virtual keyboard on a phone

On Aug 9, 2021, at 20:01, gspannu @.***> wrote:

 Use @.*** for your SAN Sent using a virtual keyboard on a phone …

Sorry, man. Did not understand. It is 1:00am here and maybe my brain isn't working - but I couldn't fathom what to put in the SAN. Can you please be more specific? Thanks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

gspannu commented 3 years ago

If your SAN is DNS:somename Use: @.*** The “@“ symbol is used to prevent an actual DNS lookup and using the IP address found in DNS and to use the following string literally. Sent using a virtual keyboard on a phone …

Thank you for your time... but could not get this to work....

I have tried the following Added the SAN as advised by you in my certificate. See command below.

certutil -z <(head -c 1024 /dev/urandom) 
-S -c "Guru VPNCA" -n "test001" 
-s "O=Secure Systems,CN=test001" 
-k rsa -g 3072 -v 12 
-d sql:/etc/ipsec.d -t ",," 
--keyUsage digitalSignature,keyEncipherment 
--extSAN "dns:***@***.***" 
--extKeyUsage serverAuth,clientAuth -8 "test001"

My ikev2.conf file looks like

conn test001
rightid="SAN=test001"
rightaddresspool=10.10.10.11-10.10.10.15
also=ikev2-shared

conn test002
rightid="SAN=test002"
rightaddresspool=10.10.10.21-10.10.10.25
also=ikev2-shared

When I connect test002 - it connects but it still gets the ip of test001. And when I try to connect test0001, it fails the connection. I have tried with both CN=test001 and SAN=test001 in the ikev2.conf file.

I am sure I am doing something wrong...

letoams commented 3 years ago

If you use: --extSAN "dns:@.***"

Then use rightid=@.***

Do not embed the string SAN in rightid

Sent using a virtual keyboard on a phone

On Aug 10, 2021, at 05:27, gspannu @.***> wrote:

 If your SAN is DNS:somename Use: @.*** The “@“ symbol is used to prevent an actual DNS lookup and using the IP address found in DNS and to use the following string literally. Sent using a virtual keyboard on a phone …

Thank you for your time... but could not get this to work....

I have tried the following Added the SAN as advised by you in my certificate. See command below.

certutil -z <(head -c 1024 /dev/urandom) -S -c "Guru VPNCA" -n "test001" -s "O=Secure Systems,CN=test001" -k rsa -g 3072 -v 12 -d sql:/etc/ipsec.d -t ",," --keyUsage digitalSignature,keyEncipherment --extSAN "dns:@.***" --extKeyUsage serverAuth,clientAuth -8 "test001" My ikev2.conf file looks like

conn test001 rightid="SAN=test001" rightaddresspool=10.10.10.11-10.10.10.15 also=ikev2-shared

conn test002 rightid="SAN=test002" rightaddresspool=10.10.10.21-10.10.10.25 also=ikev2-shared

When I connect test002 - it connects but it still gets the ip of test001. And when I try to connect test0001, it fails the connection. I have tried with both CN=test001 and SAN=test001 in the ikev2.conf file.

I am sure I am doing something wrong...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

gspannu commented 3 years ago

If you use: --extSAN "dns:@." Then use rightid=@. Do not embed the string SAN in rightid Sent using a virtual keyboard on a phone …

I still do not get it; how would the server know then which client 'test001' or 'test002' is trying to connect? The conf file sections would read the same for rightid value !

Am I going about this the wrong way?

Can you post a small example of a valid .conf file with 2 connections for 2 clients?

letoams commented 3 years ago

On Tue, 10 Aug 2021, gspannu wrote:

  If you use: --extSAN ***@***.***" Then use ***@***.*** Do not embed the string SAN in rightid Sent using a virtual keyboard on a phone
  …

I still do not get it; how would the server know then which client 'test001' or 'test002' is trying to connect? The conf file sections would read the same for rightid value !

I don't understand how you are talking about "test001" and "--extSAN @.***".

I assume your CN is test001 and your SAN is @.***

then your rightid= for that cert is specified by ONLY mentioning the SAN entry. the CN= value is irrelevant, so @. for certificate with CN=test0001 and --extSAN @.

then you have a regular conn that has all the shared values:

conn client-base left=1.2.3.4 right=%any

no rightid= specified here

other options

conn client001 also=client-base

will match CN=test0001 cert that has SAN entry with @.***

***@***.***
gspannu commented 3 years ago

On Tue, 10 Aug 2021, gspannu wrote: If you use: --extSAN @." Then use @. Do not embed the string SAN in rightid Sent using a virtual keyboard on a phone … I still do not get it; how would the server know then which client 'test001' or 'test002' is trying to connect? The conf file sections would read the same for rightid value ! I don't understand how you are talking about "test001" and "--extSAN @.". I assume your CN is test001 and your SAN is @. then your rightid= for that cert is specified by ONLY mentioning the SAN entry. the CN= value is irrelevant, so @. for certificate with CN=test0001 and --extSAN @. then you have a regular conn that has all the shared values: conn client-base left=1.2.3.4 right=%any # no rightid= specified here other options conn client001 also=client-base # will match CN=test0001 cert that has SAN entry with @. @.

Apologies, If I confused you.... I only started to use SAN=@.*** after you suggested this in one of your posts above.

If you look at this post above, it contains what I am trying to do.

Copied below for reference.

My cert generation looks like this.

certutil -z <(head -c 1024 /dev/urandom) \
    -S -c "Guru VPNCA" -n "test001" \
    -s "O=Secure Systems,CN=test001" \
    -k rsa -g 3072 -v 12 \
    -d sql:/etc/ipsec.d -t ",," \
    --keyUsage digitalSignature,keyEncipherment \
    --extSAN "dns:test001" \
    --extKeyUsage serverAuth,clientAuth -8 "test001"

certutil -z <(head -c 1024 /dev/urandom) \
    -S -c "Guru VPNCA" -n "test002" \
    -s "O=Secure Systems,CN=test002" \
    -k rsa -g 3072 -v 12 \
    -d sql:/etc/ipsec.d -t ",," \
    --keyUsage digitalSignature,keyEncipherment \
    --extSAN "dns:test002" \
    --extKeyUsage serverAuth,clientAuth -8 "test002"
conn ikev2-shared
 left=%defaultroute
 leftcert=x.y.z.a
 leftsendcert=always
 leftsubnet=0.0.0.0/0
 leftrsasigkey=%cert
 right=%any
 rightca=%same
 rightrsasigkey=%cert
 narrowing=yes
 dpddelay=30
 dpdtimeout=120
 dpdaction=clear
 auto=add
 ikev2=insist
 rekey=no
 pfs=no
 ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1
 phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes128-sha2,aes256-sha2
 ikelifetime=24h
 salifetime=24h
 encapsulation=yes
 leftid=x.yx.z.a
 modecfgdns="k.l.m.n"

conn test001
 rightid="SAN=test001"
 rightaddresspool=10.10.10.11-10.10.10.15
 also=ikev2-shared

conn test002
 rightid="CN=test002"
 rightaddresspool=10.10.10.21-10.10.10.25
 also=ikev2-shared

I do not have any specific requirements for SAN name or client name. I can define whatever SAN or Client name or both that you suggest will work. What I am really after is 2 specific client certs to have unique specific IP addresses assigned.

Would you be kind enough to edit and correct the above code sections. Both for cert generation and the conf file. - Please. Your assistance is much appreciated. Thanks for spending the time & effort on this.

letoams commented 3 years ago

On Tue, 10 Aug 2021, gspannu wrote:

Apologies, If I confused you.... I only started to use @.** after you suggested this in one of your posts above.

[ my last message in this thread ]

My cert generation looks like this.

certutil -z <(head -c 1024 /dev/urandom) \ -S -c "Guru VPNCA" -n "test001" \ -s "O=Secure Systems,CN=test001" \ -k rsa -g 3072 -v 12 \ -d sql:/etc/ipsec.d -t ",," \ --keyUsage digitalSignature,keyEncipherment \ --extSAN "dns:test001" \

You can match this using @.***

conn ikev2-shared left=%defaultroute leftcert=x.y.z.a leftsendcert=always leftsubnet=0.0.0.0/0 leftrsasigkey=%cert right=%any rightca=%same rightrsasigkey=%cert narrowing=yes dpddelay=30 dpdtimeout=120 dpdaction=clear auto=add ikev2=insist rekey=no pfs=no ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1 phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes128-sha2,aes256-sha2 ikelifetime=24h salifetime=24h encapsulation=yes leftid=x.yx.z.a modecfgdns="k.l.m.n"

conn test001 rightid="SAN=test001"

Use @.***

rightaddresspool=10.10.10.11-10.10.10.15 also=ikev2-shared

conn test002 rightid="CN=test002" rightaddresspool=10.10.10.21-10.10.10.25 also=ikev2-shared

Use @.***

gspannu commented 3 years ago

Hi @letoams @bleve

Firstly, big thankyou for preserving with me to assist in this.

I have finally managed to get the certificates and clients sorted. The issue was with the use of certutil command and extSAN parameter, I eventually had to use certutil with the -8 parameter (instead of extSAN) to get the altSubjectName defined properly.

However, multiple connections do not work.

My ikev2.conf now looks like below...

conn gsp-MAC
  also=ikev2-shared
  rightid=lon1-gspMAC@vpn.guru
  rightaddresspool=10.10.10.101-10.10.10.101

conn gsp-iPAD
  also=ikev2-shared
  rightid=lon1-gspiPAD@vpn.guru
  rightaddresspool=10.10.10.102-10.10.10.102

conn gsp-iPhone
  also=ikev2-shared
  rightid=lon1-gspiPhone@vpn.guru
  rightaddresspool=10.10.10.103-10.10.10.103

conn ikev2-shared
      left=%defaultroute
      leftcert=xxx.xxx.xxx.xxx
      leftsendcert=always
      leftsubnet=0.0.0.0/0
      leftrsasigkey=%cert
      right=%any
      rightca=%same
      rightrsasigkey=%cert
      narrowing=yes
      dpddelay=30
      dpdtimeout=120
      dpdaction=clear
      auto=add
      ikev2=insist
      rekey=no
      pfs=no
      ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1
      phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes128-sha2,aes256-sha2
      ikelifetime=24h
      salifetime=24h
      encapsulation=yes
      leftid=xxx.xxx.xxx.xxx
      modecfgdns="8.8.8.8"
      mobike=yes

Problem statement:

With the conf file as above 1) gsp-MAC connects without any issue and also gets the correct ip address assigned. 2) Now tried to connect gsp-iPAD, but it does not connect and throws an instant error.

Findings:

If I edit the ikev2.conf file and place the conn gsp-iPAD section at the top, and restart ipsec service. 1) Then gsp-iPAD connects without any issue and also gets its assigned IP address. 2) However, then gsp-MAC fails to connect.

It appears that only the first conn section is matched whenever a connection is initiated.

Any ideas how to fix this?

For reference

- Certificate contains lon1-gspMAC as Subject Name
- lon1-gspMAC and lon1-gspMAC@vpn.guru as subjectAlternateNames

See attachment below:

1 2

Cert generation command

certutil -z <(head -c 1024 /dev/urandom) \
    -S -c "Guru VPNCA" -n "lon1-gspMAC" \
    -s "O=Secure Systems,CN=lon1-gspMAC" \
    -k rsa -g 3072 -v "24" \
    -d sql:/etc/ipsec.d -t ",," \
    --keyUsage digitalSignature,keyEncipherment \
    --extKeyUsage serverAuth,clientAuth -8 "lon1-gspMAC, lon1-gspMAC@vpn.guru"
gspannu commented 3 years ago

Apologies for chasing this... @letoams @bleve @floehopper @bartman

Any help on the above post?

floehopper commented 3 years ago

@gspannu I think you've mentioned the wrong user - I have no connection with this project!

letoams commented 3 years ago

On Fri, 13 Aug 2021, gspannu wrote:

Any help on the above post?

If you are seeing issues that depend on the load order of the connections, please ensure you are using libreswan 4.4. If you are using that, there might be a pending fix in 4.5 which we expect to release over the next couple of days.

gspannu commented 3 years ago

On Fri, 13 Aug 2021, gspannu wrote: Any help on the above post? If you are seeing issues that depend on the load order of the connections, please ensure you are using libreswan 4.4. If you are using that, there might be a pending fix in 4.5 which we expect to release over the next couple of days.

I am definitely using v4.4; how can I find out if this bug is definitely being fixed in 4.5 release? Any links or bug id I can check and track? Thanks…

letoams commented 3 years ago

On Fri, 13 Aug 2021, gspannu wrote:

I am definitely using v4.4; how can I find out if this bug is definitely being fixed in 4.5 release? Any links or bug id I can check and track?

It was a number of bugs, not all tracked in the bug tracker. You could try and use the current git main version and see if that addresses your issue (either make install in /usr/local after you remove the binary package, or replace binary package with a "make deb" or "make rpm" version built.

gspannu commented 3 years ago

On Fri, 13 Aug 2021, gspannu wrote: I am definitely using v4.4; how can I find out if this bug is definitely being fixed in 4.5 release? Any links or bug id I can check and track? It was a number of bugs, not all tracked in the bug tracker. You could try and use the current git main version and see if that addresses your issue (either make install in /usr/local after you remove the binary package, or replace binary package with a "make deb" or "make rpm" version built.

@letoams I have tried the unreleased v4.5 (by building from the main branch) and was able to compile a successful build; however am unable to get the assigned IP address. The new version seems to have the same issue..

@bleve How do I make your earlier suggestion work? 

Or you can do several conns per person:

rightid="CN=oneperson"
rightaddresspool=10.10.101-10.10.10.200

and
rightid="CN=otherperson"
rightaddresspool=10.10.101.10.10.100.200

That all depends on your certificate structure. Good planning before deployment helps you big time here. Just remember rightid= with subject labels in it must match all subject label fields there are in certificate, and order must be same.

I seem to have tried everything; see posts above - but cannot get a specific IP to a specific client assigned.

gspannu commented 3 years ago

I have finally managed to solve the issue !!!

This link helped.

The client name itself can be used to distinguish between the various clients and assigned specific IP addresses.

The ikev2.conf file needs to look like this... example:

conn c1
  also=ikev2-shared
  rightid=@client1
  rightaddresspool=10.10.10.101-10.10.10.101

conn c2
  also=ikev2-shared
  rightid=@client2
  rightaddresspool=10.10.10.102-10.10.10.102

conn c3
  also=ikev2-shared
  rightid=@client3
  rightaddresspool=10.10.10.103-10.10.10.103

conn ikev2-shared
 ....
 ....
 ....

Notice the line rightid=@client1

The @ before the client name is very important - that is what correctly identifies the connection. So specify your clientnames with whatever names; and make sure that the rightid= starts with @ and then the client name.

Hopefully, this helps others....

Issue may be closed now.

May I request you to put this bit somewhere in the Readme so anyone else trying to get specific IP addresses per client on ikev2 can use this method.

cagney commented 1 year ago

Issue may be closed now

thanks!