Clarification on sk108600 - VPN with 3rd parties

[Alex-]

We have a VPN where the remote party expects a PSK and an FQDN.

We never had to do this before so we'd be grateful for experience feedback from those who have.

I've checked sk108600  VPN Site-to-Site with 3rd Party and would like some clarification:

- On VSX, do we need to edit the CPProfile files under the specific VS? I would assume yes but it's not explicitly mentioned

- Renewing the IPSEC Certificate and adding the FQDN as SAN will not matter in the case of PSK

- There is a procedure to export the values directly to system variables but it doesn't enforce the change, so a reboot is mandatory to make them active

Thanks for any insights.

EDIT: Point 2 is actually covered in the notes of the SK.

[PhoneBoy]

I assume you would do this at the VS level, yes.
Because these environment variables affect multiple processes, it requires a restart of the gateway/VS, which cpstop/cpstart should do when in the relevant VS context.

[Alex-]

It seems to work. We can see the FQDN being added in the IKEv2 negotiation when debugging VPN.

<Payloads>
			<Payload Type="IDi" Next="Auth" Length="26" Critical="No">
				<Type>FQDN</Type>
				<Data>MyFQDN</Data>
			</Payload>
			<Payload Type="Auth" Next="Notify" Length="72" Critical="No">
				<Method>Shared Secret</Method>

We will test with the relevant partner asking for this feature.

[PhoneBoy]

Sounds promising, keep us posted 😉

[Alex-]

It worked, the IKEv2 negotiation completed successfully with validation of the FQDN along the PSK.

Worth noting this is global parameter on Check Point as far as we can see so not scalable, maybe R82 will change that.

[Alex-]

We have submitted an RFE. While the solution to send the FQDN works, it is done for every IKEv2 tunnel.

We had some VPN that broke down due to peer validation on the partner side. They either had to specifically change their configuration for the Check Point tunnels or accept the FQDN we send, which in either case isn't pretty.

[the_rock]

I meant to reply this morning, but got tied up with something else, but Phoneboy gave the right method. Its definitely on VS level. I had client who had this issue and thats what TAC ended up suggesting as well.

Andy

[JozkoMrkvicka]

Out of curiosity, what is vendor of 3rd party peer ?

[Alex-]

@JozkoMrkvicka Fortinet, configuring PSK + FQDN per VPN tunnel.

As I understand it, on Check Point this is a global parameter.

[JozkoMrkvicka]

I recently configured IKEv2 VPN between VS and FortiGate, but it went very smooth without any problem/additional modifications. Maybe it is some specific setting done for specific Fortinet product in your case ?

[Alex-]

Yes, they actively require the FQDN on top of the PSK.

I would have preferred a certificate-based approach if we are verifying FQDN and the likes so we just exchange CA and don't edit system files, but we're not making the rules for that connection.

One more thing to check after each jumbo/version upgrade.

[the_rock]

I have fully licensed Fortigate in the lab running 7.6.0 (latest version), so if you need anything tested, let me know.

Andy

[Alex-]

Nice offer. 😀

Basically it's the option 2 of the SK, editing $CPDIR/tmp/$CPprofile.sh and CPprofile.csh with the mentioned information, reboot, then make an IKEv2 tunnel with PSK to the Fortinet. In the VPN debug, the Fortinet should see the FQDN in the IKE negotiation.

[the_rock]

I lied when I said fully licensed...well, its partially true, but only for another week lol

Anyway, let me know if anything is needed, not an issue.

Andy