Closed gspannu closed 1 year ago
That feature is not available yet. It wouldn’t be too hard to add based on me file with simple
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.
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.
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.
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).
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
You need multiple connections. And your rightid= must match exactly certificate subject.
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.
@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...
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.
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?
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.
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...
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.
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?
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
other options
conn client001 also=client-base
***@***.***
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.
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 @.***
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.
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
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.
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.
- Certificate contains lon1-gspMAC as Subject Name
- lon1-gspMAC and lon1-gspMAC@vpn.guru as subjectAlternateNames
See attachment below:
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"
Apologies for chasing this... @letoams @bleve @floehopper @bartman
Any help on the above post?
@gspannu I think you've mentioned the wrong user - I have no connection with this project!
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.
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…
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.
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.
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.
Issue may be closed now
thanks!
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.
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...