How to convert traditional mode VPN policy to simplified mode VPN policy

[slowfood27]

We have a policy (R77.20) which uses traditional mode VPNs. We want to convert it to a policy using simplified mode VPN.
The current policy defines roughly 80 Site-2-Site VPNs. The converted, new policy should have a dedicated VPN Domain for each Site-2-Site VPN.
The VPNs use shared secrets. What is the simplest way do achieve that?

[mcnallym]

In order to convert the policy then you have to remove all existing vpn configuration, convert the policy then add the VPN configuration back in. Is a manual process. Make sure that document all of the VPN as will need to remove it.

I presume when you say a Dedicated VPN Domain for each S2S VPN that meant community. You can still only have 1 VPN Domain on a Gateway.

[slowfood27]

The LAB experience shows that i can convert the policy from traditional mode to simplified mode WITHOUT removing all VPN definitions. But the conversion wizard can put all the gateways only in a single VPN Community. As far as I could see you loose the Phase 2 IPSec Parameters, which were defined in the Encrypt properties of the rule base.
Apart from that, all Phase 1 parameters and the shared secrets are still available, since they are defined on the gateway object.

For my case, I need to create a new VPN Community for each existing Site-2-Site and adjust the params accordingly.

Question 1: When using the simplified mode policy, do the parameters values of the VPN community take precedence over the traditional mode parameters, which are still present on the gateway object?

Question 2: Can we create a bunch of VPN Communitis using dbedit?

[jdmoore0883]

Question 1: When using the simplified mode policy, do the parameters values of the VPN community take precedence over the traditional mode parameters, which are still present on the gateway object?

Question 2: Can we create a bunch of VPN Communitis using dbedit?

Answer 1: You cannot have Simplified and Traditional Mode VPNs in the same policy. So this is a moot point.

Answer 2: Yes, you should be able to. I do not know the commands to do so though...

[slowfood27]

I sucessfully created a dbedit script in order to create a VPN Community. All of the required parameters are there, except the shared secret for that community.
How can I enter the shared secret of that community with a dbedit command?

[slowfood27]

While testing the new, converted policy we had some side effects we can't explain.
We have all site to site VPN rules at the top of the policy.
Somewhere further down, we have the following rule:

Source: 172.16.186.0 (which is part of the encryption domain of our local gateway)
Destination: any
Service: any

With the traditional mode VPN Setup, the rule above gets fired unencrypted, as expected.
With the simplified mode policy, the firewall tries to encrypt connections within its own encryption domain, which of course fails, since there is no valid SA

Example:
Source: 172.16.186.55 (part of the local encryption domain)
Destination: 192.168.99.33 (part of the local encryption domain)
service: nbsession

Any ideas why that connection is treated "encrypt"?

[varera]

the process of conversion is thoroughly described in Check Point VPN admin guide: https://sc1.checkpoint.com/documents...uide/13941.htm

[ShadowPeak.com]

Also just FYI the tool used to convert Traditional Mode VPNs to Simplified Mode VPNs no longer exists in R80 management and later, so the time to make the conversion from Traditional to Simplified Mode VPN is *before* upgrading management to R80+.

[slowfood27]

Thanks folks for your input
The policy is now converted and clean, it will go live soon
The problems we had were caused by 2 elements:

1. A partners encryption domain overlapped with internal networks
2. Each community needs encryption exclusion for the IPSec Protocols

[laf_c]

Thanks folks for your input[*]Each community needs encryption exclusion for the IPSec Protocols[/LIST]

What do you mean by that?

[slowfood27]

What do you mean by that?

It means that you cannot encrypt everything within your community. Before the VPN Tunnel is established (or needs to be re-established) the 2 gateways need to exchange the relavent parameters using the IKE protocol. And this Protocol (udp port 500) must be defined in the advanced section --> Excluded Services

[slowfood27]

After converting the policy from traditional to simplified mode, we run into a weird problem we didn't have before.

We have a site to site VPN with HPE, and its encryption domain consists of a single public IP adress 131.124.93.147.
Additionally, internal users access the Internet HP Portal (via our DMZ Proxy) , which has the same public address 131.124.93.147

With traditional mode, this constellation worked. With traditional mode, the gateway tries to encrypt everything with the destination address 131.124.93.147, regardless of the Services defined in the policy.
As a result, the un-encrypted access to the public portal doesn't work anymore.

Any ideas?

[slowfood27]

Solved

this is one of th nasty "features" of simplified mode, that VPN is always preferred over any other rule, where source and destination match.
The get the stuff running, we had to add an exclusion for the https protocol