NGX VPN issue.

[andyclure]

I have a fairly new installation of Checkpoint NGX which is acting as both the enforcement and management module. The firewall is working fine except I am having trouble establishing a VPN between the firewall and a remote Linksys broadband router.

I don't think this is a fault as such, more likely I don't know how to set this up in NGX! The VPN settings on the remote router require a shared secret to establish a VPN, fine I thought, you just enter this in the VPN community. Problem is, it won't let me enter a remote gateway into the VPN community unless it is a Checkpoint product, NG FP1 to be precise.

I am running a simplified rule base and have got standard remote access VPN's with Secure Remote/SecureClient working OK. Just not a Site to site VPn using the Linksys box. Does anyone have any idea (or a link to a guide) how to establish a site to site VPN to a 3rd party product in NGX?

Cheers.

[ddarby1]

Hi,

You need to add an 'interoperable device' - Manage > Network Objects > New > Interoperable Device then define it's topology etc.

Once defined, you'll be able to add it in the 'Participating Gateways' section of the VPN Community. In the 'Advanced Settings' you can add a shared secret.

Regards,

ddarby1

[Sergej]

Try to compile from this two:
Cisco PIX to NG
http://www.cisco.com/en/US/tech/tk58...800ef796.shtml
Linksys to Cisco IOS
http://linksys.custhelp.com/cgi-bin/...hp?p_faqid=362

[andyclure]

Sorted the Checkpoint side now thanks very much. Just didn't see the interoperable device bit.

Tunnel is now up but not working, I think this is a problem with the Linksys router though. it doesn't seem to know where to send packets for the remote subnet. A few Linksys forums have peole reporting the same problem.

[stancounty]

Anyone else figure this out (Site to Site VPN between NGX and Linksys or other third party IPSEC device)? I'm looking to do the same, but with NG R55 and a Linksys BEFVP41 VPN router. Sure would be nice if anyone had a guide for this.

Originally Posted by andyclure

I have a fairly new installation of Checkpoint NGX which is acting as both the enforcement and management module. The firewall is working fine except I am having trouble establishing a VPN between the firewall and a remote Linksys broadband router.

I don't think this is a fault as such, more likely I don't know how to set this up in NGX! The VPN settings on the remote router require a shared secret to establish a VPN, fine I thought, you just enter this in the VPN community. Problem is, it won't let me enter a remote gateway into the VPN community unless it is a Checkpoint product, NG FP1 to be precise.

I am running a simplified rule base and have got standard remote access VPN's with Secure Remote/SecureClient working OK. Just not a Site to site VPn using the Linksys box. Does anyone have any idea (or a link to a guide) how to establish a site to site VPN to a 3rd party product in NGX?

Cheers.

[ozzy27]

I have a similar issue. Phase 2 communications fail between an RV042 and NGX R60. The logs on the Linksys device show successful communications but Checkpoint displays failed Phase 2 communications.We've tried just about every possible encryption/hash option available; If anyone has any ideas please share, I'll do the same if I'm successful.

Thanks

[Danielpb]

You could try this fix used with a cisco concentrator....

To resolve this supernetting issue, configure the max_subnet_for_range table in $FWDIR/lib/user.def on the Management Server (SmartCenter).

Please note the user.def file might also be called user.def.NGCMP if you using provider.

Modifying user.def file to manually define networks to encrypt traffic to/from
Backup $FWDIR\conf\user.def file.

Edit $FWDIR\conf\user.def file:

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

#ifndef __user_def__
#define __user_def__

//
// User defined INSPECT code
//

max_subnet_for_range = {
<0.0.0.0, 194.29.39.255; 255.255.255.0>,
<194.29.40.0, 194.29.50.255; 255.255.255.255>,
<194.29.51.0, 255.255.255.255; 255.255.0.0>
};

#endif
Ex

--------------------------------------------------------------------------------
In Example 1, the configuration would work in the following way:
- For the host IP 194.29.23.1 the network IP would be 194.29.23.0/24
- For the host IP 194.29.46.45 the network IP would be 194.29.46.45 (just one IP)
- For the host IP 194.29.102.1 the network IP would be 194.29.0.0/16

[MarioL]

I would check the exact VPN settings on the Linksys, it may be required to change some on the VPN community.

Check if the tunnel comes up correctly on both devices.

[ozzy27]

Thanks Danielpb,

That's the proposed solution we received from Checkpoint support. It just seems that it would become an administrative nightmare going forward. We would now have to maintain the user.def file going forward and we have limited access to the shell on the firewalls which is already frustrating enough. If there was a way to automate the process it may be a possibility.

Thanks again

[RayPesek]

Fire up GUIdbedit and take a look in Firewall Properties. I don't remember exactly where it is but there is a property named something like IKE_Use_Largest_Possible_Subnet. It's the only thing named like that and it is what causes the supernetting. If it's set to True, reset it to False, save the change when you exit GUIdbedit and push the policy.

This is an ancient default value that was still being set in R61 and it causes a big problem with Cisco VPNs. It may save you from the manual .def change. Changing it obviously affects all VPNs on the firewall, but I've never seen any adverse results from setiing it to false.

Ray

[cciesec2006]

NGx fixed this problem. There are very rare cases that you have to
modify with dbedit and user.def file when dealing with VPN between
Checkpoint and Cisco. The solution is in the VPN community,
tunnel management, you just need to set it to "one vpn tunnel
per each pair of host". That will fix the problem. I've done it many
times and it works in NGx between Cisco IOS router, Pix, and
VPN concentrator and I can say that it works. Both sides need
to run stable codes. There are always two-sides to every story.


The downside of this is that the resource on the firewall will surfer
because of this.

Guess there is no such thing as a free lunch. You pay one way or
the other.