Configuration for VPN to send 80/443 traffic to Netskope

[Anthony_Vita]

I have a need to create VPN tunnels from a R80.40 gateway to Netskope cloud gateway.  Want to only send traffic from select internal source IP's that need internet bound http/https traffic to the Netskope cloud for inspection by their SWG.  

Anyone figure out how to do this?

[PhoneBoy]

You can certainly create an encryption domain with the specific hosts in question and only those hosts.
However, it will potentially send all Internet-bound traffic from those hosts over the VPN, not just traffic on port 80/443.
Unless, of course, you deny all other traffic from those hosts to the Internet.

Whether you can make this work with Netskope is a separate question.
Also, if the Check Point gateway can perform the same functions (which it likely can), why send the traffic there at all?

[Vladimir]

Netscope performs combined functions of SWG, CASB and DLP that are a lot more granular than the CP gateway by itself can perform, so I can see a use case for this.

[Anthony_Vita]

Correct, the additional functions that Netskope performs are part of the reason, another is a unified policy management point for all clients as our endpoints are using Netskope when off net.   

The need for sending only select hosts through the tunnel is for initial testing, eventually we will look to forward all clients that do not have a Netskope client installed (think servers, IOT) through this tunnel to the Netskope SWG.  I was trying to use VTI and PBR, to select the traffic.  I have the VPN community created and the Tunnel are up, but I can't get the traffic to pass.  I have a Rule at the top of the policy to match the source IP of the test clients destined to a Negated RFC1918 network group with a Directional match on the VPN and service of 80/443.  There is also a rule in the application policy for the same.

Looking at the logs, it shows the traffic being encrypted and moved to the appropriate Tunnel interface, but matched on a lower rule for all other Internet bound traffic, not the Directional match rule at the top.  Then there is an accept that is not encrypted, with the message:  Connection terminated before detection: Insufficient data passed.  See SK113479.  What am I missing?

[Vladimir]

I'm not familiar with NetScope Cloud Gateway requirements, but am curious why the use of VTIs and PBR is required.

Depending on what version of Check Point you are on, I think the use of custom local VPN Domain with VPN Community is a better way of sending traffic from select hosts or access roles to NetScope, if they support domain-based VPNs.

[firewall1-gx]

Hi Anthony,

Sometime ago I made a configuration look you are need, I can remember that a VPN universal tunnel was configured for this.

Basically we used policy based VPN instead of route based (VTI), with "Route All Traffic Through This Site" enabled on VPN community to negociate 0.0.0.0-0.0.0.0 with remote peer.

The biggest challenge to do this configuration is because you're forwarding all traffic through this tunnel. Thus, now PBR policies can be helpful to redesign outgoing paths.

In my case I routed all traffic, wasn't necessary be a previous test before production, because were a new enviroment. 

I hope that my short words can help you.

Alisson Lima

[CheckPointerXL]

Hello,

did you solve the problem? Same situation here, RouteBased+PBR but i get "Failed to enforce VPN Policy (11)"

[Anthony_Vita]

I did not solve this problem and ended up using a different device to terminate the tunnels for my testing.

[LazarusG]

I think thats a good fix.

I was looking at pbr and route based vpn with unnumbered vti but its a bit odd with a cluster, although I think this would be the nicest solution.

I did however just find this - so there is a solution using some tricks from 2022 with groups with exclusions/excluded services and mep it seems;

Configuring Site-to-Site VPN between a Check Point Gateway and Netskope

[Diego_dg]

Hi, was somebody able to configure this VPN with netskope following the article above (sk179920)? I have followed it but the other side is always returning "gateway to gateway authentication error", I suppose it was the usual problem with the ID and 3rd party VPNs, but I have checked that the ID is right, is the same as the public IP address...

[LazarusG]

I have seen that a customer with a large environment had used it successfully - lot of work though...

[Diego_dg]

Thanks! we were able to make it work (in a POC), we had to adjust the encryption domain until the vpn was rightly established but in the end it worked 🙂