07-29-2008 10:32 AM
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.
Solved! Go to Solution.
07-30-2008 01:46 PM
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,
07-29-2008 06:21 PM
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".
07-30-2008 05:32 AM
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.
07-30-2008 06:03 AM
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.
07-30-2008 07:32 AM
Verified with vendor that this setting is correct. Thanks.
07-30-2008 01:46 PM
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,
07-31-2008 08:12 AM
Thanks Cisco24x7. The Checkpoint is controller by the vendor, and while I couldn't see exactly what was done on their side, I know it was related to a supoernet issue...issue resolved. Thanks again.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide