when will IKEv2 come for remote access?

IKEv2 is an Item on our Backlog as of today.

We do not have a target version for it (yet). 

thanks for this clear statement

There is a strong recommendation from NSA and CISA to use IKEv2 for IPsec-VPN Remote Access:

https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/2791320/nsa-cisa-release-guidance-on-selecting-and-hardening-remote-access-vpns/

https://media.defense.gov/2021/Sep/28/2002863184/-1/-1/0/CSI_SELECTING-HARDENING-REMOTE-ACCESS-VPNS-20210928.PDF

https://datatracker.ietf.org/doc/html/draft-corcoran-cnsa-ipsec-profile

For me this is not "nice to have" but "should be available soon".

Do you mind to show me in those links, where the IKEv2 recommendation is?
Because the both links are not clearly referencing to IKEv2 - and the RFC is a draft and not complied (yet) 

You can read it either way: there is only IKE v2, when they talk through hardening and secure remote VPN access.

----- cited from that document --------------------------------------

Configure the VPN to use IKE/IPsec and disable SSL/TLS VPN functionality and
fallback options if feasible.
 For IKE/IPsec VPNs, CNSSP 15-compliant cryptographic algorithms are
required for IKE and Internet Security Association and Key Management
Protocol (ISAKMP) for NSS [9], [10]. CNSSP 15 requirements are
explained in the draft IETF document Commercial National Security
Algorithm (CNSA) Suite Cryptography for Internet Protocol Security
(IPsec) and NIST requirements for other U.S. Government systems are in
SP 800-77rev1 [11], [12]

--------------------------------------------------------------------------

The link to the CCSSP-15-compliant crypto algs has only IKEv2 in it, IKEv1 is not even mentioned.

I think we can agree that IKEv2 is well established and safer than it's predecessor.

So we should be able to use it right away.

With Cisco firewalls this is no problem since years.

Just to be sure, i am not arguing whether IKEv2 would be helpful or useful, i am always mindful about statements like "It is required by institutes".

The Above part is linking to an RFC Draft. It also indirectly state, you should use IKEv2 instead of IKEv1, but from what i see, this is a federal US enforcement, it does not directly prohibit IKEv1 from being used - Same for NIST certification, which would recommend using IKEv2 - But not breaking your certification, if you use IKEv1. 

Again i am not based in US and cannot go through all documents - Stating only IKEv2 is not a prohibit of IKEv1. 

It is always about: Do you break some kind of certification or compliance checks, by using IKEv1 - And even on most installations, i am seeing today, customers use Site to Site with IKEv1 - As peers only support IKEv1. (Even as SFOS support IKEv2 on Site-to-Site).

Personally i think, IKEv1 as a technology will follow us all some more time - Especially as it is not considered as breached nor insecure. 

Just to be sure, i am not arguing whether IKEv2 would be helpful or useful, i am always mindful about statements like "It is required by institutes".

The Above part is linking to an RFC Draft. It also indirectly state, you should use IKEv2 instead of IKEv1, but from what i see, this is a federal US enforcement, it does not directly prohibit IKEv1 from being used - Same for NIST certification, which would recommend using IKEv2 - But not breaking your certification, if you use IKEv1. 

Again i am not based in US and cannot go through all documents - Stating only IKEv2 is not a prohibit of IKEv1. 

It is always about: Do you break some kind of certification or compliance checks, by using IKEv1 - And even on most installations, i am seeing today, customers use Site to Site with IKEv1 - As peers only support IKEv1. (Even as SFOS support IKEv2 on Site-to-Site).

Personally i think, IKEv1 as a technology will follow us all some more time - Especially as it is not considered as breached nor insecure.