Solved: 3K5 Concentrator L2L with Checkpoint NGR55 Issues

venom43212 · ‎07-29-2008

I am trying to create an L2L connection from a 3K5 Concentrator to a vendor with a Checkpoint NGR55. At implementation this morning, we were able to access all NATed applications on their side, they weren't able to access ours. The message we saw on both sides was:

Received non-routine Notify message: Invalid ID info (18)

Which indicates mismatched attributes between the peers. These have been verified on both sides. We have our local network list specified as all of the individual hosts that are translated in the static NAT rules. For them, we have static translations and two global PATs...the network list for them specifies their entire /24 network that was used in the global PAT. My understanding is that the more specific network will be applied and if not found, the PAT will be used and I can see this happening in the event log.

Question 1.) Could this be a possible problem with why they can't connect to anything on our side?

Question 2.) The concentrator is menu driven, even from the CLI and I can't find a way to clear the SA when troubleshooting other than disabling and re-enabling the tunnel. I know on the ASA and PIX and I can do this for phase 1 and 2 from the CLI. Does disabling the tunnel on the 3K5 have the same result?

Any other ideas on why this is happening would be appreciated.

cisco24x7 · ‎07-30-2008

This is very likely that the Checkpoint is

doing suppernetting thus causing Phase 2

Quick mode error. I would do this on the

checkpoint side:

1- log into the checkpoint gateway,

2- "vpn tu" and delete the tunnel between

checkpoint and VPNc,

2- cd $FWDIR/log,

3- vpn debug trunc,

4- vpn debug ikeoff,

5- vpn debug ikeon,

6- Now initiate the connection from checkpoint

side. It will fail,

7- collect the ike.elg file and export it

to your desktop via scp or whatever,

8- Use a checkpoint tool called IKEView.exe

utility and open the ike.elg file.

This will tell you EXACTLY why the tunnel failed and why. It is very likely that

checkpoint is suppernetting its network and

send it over to VPNc, causing phase-II to

fail.

To resolve this problem, you will have

to modify the parameter "IKE_largest_possible_subnet" from "true" to "false" and also modify the user.def file as

well.

The other solution is to upgrade to NGx so

that you have a option to negotiate "per

host" and have communication on both sides.

Sound easy right?

Now,

View solution in original post

cisco24x7 · ‎07-29-2008

I think I have an idea on how to fix this

since I have been working with NG AI R55

forever. However, before I do, please

explain again how the setup is like.

It is most likely that you will have

to modify the $FWDIR/lib/user.def and

change the "IKE_largest_possible_subnet"

parameter from "true" to "false".

venom43212 · ‎07-30-2008

Thanks for the reply. I am assuming these changes would be made on the Checkpoint? The setup again in brief: L2L VPN tunnel from 3K5 to NGR55. We have static NAT translations for our inside to vendor's outside...for example; Source: 192.168.1.2 (our inside) translated to 55.55.55.2 (our outside) with a remote 200.10.10.2 (vendor's outside). In our local network list we have 55.55.55.2/0.0.0.0. Becuase we do have a global PAT for our inside to vendor's network, in the remote network list, we have only 200.10.10.0/0.0.0.255. The order of operations should take the more specific hosts under this subnet. We can access everything on vendor's side fine, they can't access anything on our side. The addresses listed above aren't the actual ones in use, but should demonstrate the setup. If the problem looks similar to what you have seen, your response would be appreciated. Thanks in advance.

venom43212 · ‎07-30-2008

I also forgot to mention that the tunnel is presently up on an ASA to the Checkpoint and there is two way communication; we are trying to move it off of the ASA though to the concentrator. Thanks.

venom43212 · ‎07-30-2008

Verified with vendor that this setting is correct. Thanks.

cisco24x7 · ‎07-30-2008