Got it

IPSec/DSVPN - migration to PKI

Created: Feb 5, 2019 20:24:11Latest reply: Apr 14, 2019 18:21:56 967 6 0 0 0
  Rewarded HiCoins: 0 (problem resolved)

Hi,

Can anyone has experience in seamless migrating from IPSec/DSVPN with IKE authentication-method pre-share to rsa-signature based using PKI ?


Assuming that you have everything as the doc sais : tunnel interfaces with ipsec profile, ipsec profile with ike peer using ike proposal with authentication-method pre-share. And you do not want to change ipsec profile on the Hub at one moment to other (using PKI)  which can couse service outage on many spokes nor create other temporary tunnel with additional ip address.

I think you cannot simply allow 2 ike peer definitions to exist for migration period used by ipsec profile : one with ike proposal and authentication-method pre-share  and preshared key and the other with authentication-method rsa-sig and pki realm

You also cannot allow to define more than one node (rule) of ipsec profile for use on the tunnel (as you can do with ipsec policy)


So is there a simple solution or using a temporary tunnel int with new ipsec profile is a necessity (until all ike pre-share spokes are migrated)  ?


Regards, Piotr

  • x
  • convention:

Featured Answers
emontiel
Created Feb 5, 2019 21:19:19

Hello Piotr, the PKI entity applies for a local certificate from the CA and the applicant device authenticates the certificate, which makes it different to the authentication with the pre-shared key. So, as you stated, to avoid impact I suggest you to go on creating the temporary tunnel in a different subnet and send that way the traffic while you complete the migration of the tunnels. Making the migration while tunnel is up and has traffic, can drive to an erratic behaviour because the tunnel will have two different authentication methods and IKE parameters will not match:


Initial Exchanges process 
fig_dc_fd_ipsec_003101.png

PKI working process
fig_dc_fd_pki_000901.png

You can also make some tests in the temporary tunnel, before it has any live service.
View more
  • x
  • convention:

All Answers
emontiel
emontiel Created Feb 5, 2019 21:19:19

Hello Piotr, the PKI entity applies for a local certificate from the CA and the applicant device authenticates the certificate, which makes it different to the authentication with the pre-shared key. So, as you stated, to avoid impact I suggest you to go on creating the temporary tunnel in a different subnet and send that way the traffic while you complete the migration of the tunnels. Making the migration while tunnel is up and has traffic, can drive to an erratic behaviour because the tunnel will have two different authentication methods and IKE parameters will not match:


Initial Exchanges process 
fig_dc_fd_ipsec_003101.png

PKI working process
fig_dc_fd_pki_000901.png

You can also make some tests in the temporary tunnel, before it has any live service.
View more
  • x
  • convention:

PiotrekRGC
PiotrekRGC Created Feb 5, 2019 21:41:48

I thould that a temporary tunnel would be the only sensible solution. Nevertheless, it's always worth asking
Thanks!
View more
  • x
  • convention:

chenhui
chenhui Admin Created Feb 7, 2019 07:30:01

Posted by PiotrekRGC at 2019-02-05 21:41 I thould that a temporary tunnel would be the only sensible solution. Nevertheless, it's always wort ...
since you have additional conditions, it seems that a temporary tunnel would be the best accessible solution,
View more
  • x
  • convention:

chenhui
chenhui Admin Created Feb 7, 2019 07:31:28

Posted by PiotrekRGC at 2019-02-05 21:41 I thould that a temporary tunnel would be the only sensible solution. Nevertheless, it's always wort ...
maybe there are other solutions, but it'll take time to verify them.
View more
  • x
  • convention:

PiotrekRGC
PiotrekRGC Created Feb 7, 2019 17:36:23

Posted by chenhui at 2019-02-07 01:31 maybe there are other solutions, but it'll take time to verify them.
I think you’re right the safest solution is the best one. Extra tunnel will help with a smooth migration to pki-based ipsec/ike.
Thanks for all responses.
View more
  • x
  • convention:

PiotrekRGC
PiotrekRGC Created Apr 14, 2019 18:21:56

Update...
I did some research and implementation tests and I'm sure it is perfectly feasable to migrate DSVPN/IPSEC from pre shared key authentication to rsa-signature (PKI) without connection loses or new tunnel creation.
All comes down to a few points.
1. On the HUB and next gradually on all of the SPOKES
- you need to have different ike proposals : for pre-shared (it has existed to that point) and for rsa-sig (the one with pre-shared should have a lower number eg. 1 - higher priority, for rsa-sig eg. 10)
- in ike peer configuration (originally for pre-shared) you need to delete any ike-proposals (in oreder to allow the system to choose from configured ike proposals freely according to priority)
- in the same ike peer configuration you add pki realm reference to the pki realm used for your certificates
- ...and you leave reference to pre-shared key for the time of migration
This way ike proposal is used for both pre-shared and rsa-sig auth modes (IKE negotiation should be default main mode)
Now you can connect to any DSVPN/IPSec hub and spoke and default mode is selected pre-shared
2.
After 1 step is made on all of spokes you simply set ike-proposal 10 (rsa-sig) in ike peer configuration on spokes one by one
3.
After all of the spokes have ike peer configuration changed to ike-proposal 10 (no choise then) you set it on the hub (new fixed ike-proposal )
Next you can remove pre-shared key from ike peer and ike proposal 1 definition (the one for pre-shared authentication)

In short, that's it and it works (verified on AR1220E and AR161 with V200R009)
View more
  • x
  • convention:

Comment

You need to log in to comment to the post Login | Register
Comment

Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."

My Followers

Login and enjoy all the member benefits

Login

Block
Are you sure to block this user?
Users on your blacklist cannot comment on your post,cannot mention you, cannot send you private messages.
Reminder
Please bind your phone number to obtain invitation bonus.