04-16-2008 08:31 AM - edited 03-11-2019 05:32 AM
Hello all I'm trying to establish a VPN with a Checkpoint NGX from my PIX and the IKE phase one works but apparently when trying phase 2 the connection cannot be established. Here is a debug message:
crypto_isakmp_process_block:src:w.x.y.z, dest:z.y.x.w spt:500 dpt:500
OAK_QM exchange
oakley_process_quick_mode:
OAK_QM_IDLE
ISAKMP (0): processing SA payload. message ID = 3036632205
ISAKMP : Checking IPSec proposal 1
ISAKMP: transform 1, ESP_3DES
ISAKMP: attributes in transform:
ISAKMP: encaps is 1
ISAKMP: SA life type in seconds
ISAKMP: SA life duration (basic) of 28800
ISAKMP: SA life type in kilobytes
ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0
ISAKMP: authenticator is HMAC-MD5
ISAKMP (0): atts are acceptable.
ISAKMP: IPSec policy invalidated proposal
ISAKMP (0): SA not acceptable!
ISAKMP (0): sending NOTIFY message 14 protocol 3
return status is IKMP_ERR_NO_RETRANS
Any Ideas?
I saw on the forums that this might be a bug on the NGX. And I saw on a Cisco troubleshooting document that it could be: "The access lists on each peer needs to mirror each other (all entries need to be reversible)."
So which one you think is it?
04-16-2008 09:11 AM
'I saw on the forums that this might be a bug on the NGX. And I saw on a Cisco troubleshooting document that it could be: "The access lists on each peer needs to mirror each other (all entries need to be reversible)."'
That is entirely in-accurate. First, I need to know what your setup look likes. Please provide
the following info on the Checkpoint NGx side:
1- uname -a,
2- fw ver,
3- what is the encryption domain on the NGx side?
4- are you using traditional mode or simplified mode?
5- If you're using simplified mode VPN, are you using exchange key per subnet pair?
This could be your problem. Use exchange key per hosts instead.
6- Are you natting inside the VPN tunnel? If not, check the "disable NAT inside VPN communities"
I suggested that you use debug tool on the checkpoint to find out what wrong with the VPN. Run
debug on the firewall "vpn debug ikeon" and look at the ike.elg file. The debug in Checkpoint
is way better than cryptic cisco.
If I have to guess, I think checkpoint is "suppernetting the network" on the pix side. That's why
phase I works but phase II failed.
CCIE Security
04-16-2008 09:47 AM
I don't control de Checkpoint side, so I just requested the information to them. Hopefully I will get that information soon and I'll post it here.
Thanks
04-17-2008 07:07 AM
Here are the responses from the checkpoint guy:
1- uname -a,
A - ?
2- fw ver
A - NGX R65
3- what is the encryption domain on the NGx side?
A - Our internal nodes that require communications via IPSEC are included
4- are you using traditional mode or simplified mode?
A - Simplified Mode
5- If you're using simplified mode VPN, are you using exchange key per subnet pair?
A - We are configured to exchange per hosts pair
This could be your problem. Use exchange key per hosts instead.
6- Are you natting inside the VPN tunnel? If not, check the "disable NAT inside VPN communities"
A - We are natting inside the tunnel.
I suggested that you use debug tool on the checkpoint to find out what wrong with the VPN. Run
debug on the firewall "vpn debug ikeon" and look at the ike.elg file. The debug in Checkpoint
is way better than cryptic cisco.
A - I've requested this from my FW-Architecture team they will send results as soon as possible.
If I have to guess, I think checkpoint is "suppernetting the network" on the pix side. That's why
phase I works but phase II failed.
A - We've experienced issues with supernetting before but this case is a little different since the networks are disimilar.
CCIE Security
04-17-2008 09:13 AM
1- Is this a Nokia or Secureplatform or Solaris? "uname -a" will work with all of them.
2- Can you tell me the networks/hosts on the NGx local encryption domain?
3- Can you tell me the networks/hosts on the ASA local encryption domain?
4- If you're Natting inside the tunnel, what are you natting it to?
5- If you're natting inside the tunnel, do you have the NAT translation defined
under the NAT translation tab, like what traditional mode used to do.
Without being specific, I can not help much beyond this point. Please be specific
and I can help you with. Please include a diagram with all the pertinent
information so that I can tell you what wrong.
ike.elg file is a binary file and you can only view it with IKEView.exe program.
CCIE Security
04-17-2008 10:10 AM
Please remember that this is a public forum and I can't disclose internal information from me(pix) or my client/supplier(checkpoint).
Here is what I can say:
1- Is this a Nokia or Secureplatform or Solaris? "uname -a" will work with all of them.
A - I asked him again.
2- Can you tell me the networks/hosts on the NGx local encryption domain?
A - Its a public ip address(class C), but not in an everybody should know it sense, the client doesn't want it disclosed.
3- Can you tell me the networks/hosts on the ASA local encryption domain?
A - Private class A address /22.
4- If you're Natting inside the tunnel, what are you natting it to?
A - The pixes outside interface.
5- If you're natting inside the tunnel, do you have the NAT translation defined
under the NAT translation tab, like what traditional mode used to do.
A - Yes
04-17-2008 12:26 PM
Are you natting your Private A class /22 to Pix "outside" interface
to get to networks/hosts behind the NGx Firewall? Is that the correct
assumption?
In that case, you need to include the pix "outside" interface as part
of the interesting traffics on your end. There is nothing to be done
on the NGx side because NGx, in simplified mode, takes into account the
Pix "outside" interface as part of the encryption domain.
The ike.elg file will confirm what I've state above, according to the
information you provided.
Can you just make up ip addresses on both of your end and the NGx side
and post it here so I have a better understanding of what you're trying
to do. I do not need the exact IP addresses, but the netmaks needs to be
consistent.
CCIE security
04-17-2008 01:55 PM
OK, here's what I did. I included the outside address to the interesting traffic access list and nothing. I only left the outside address in the access list and still nothing. The access lists basically states that if traffic comes from an internal address and/or the pix outside address to the other sites address to port 80 then permit. Here are both debugs (I had to attach them because of word space).
Hopes this helps.
BTW they are running SecurePlatform.
04-17-2008 05:03 PM
1- VPN between ASA and NGx,
2- VPN between NGx and Juniper,
net_A needs to access 129.174.1.0/24 via VPN and that
net_A is nat to ASA "outside" interface to access 129.174.1.0/24
over the VPN. Net_A can NOT access 192.168.0.0/24
net_X need to access Net_J and vice versa
Solution:
a- include both 192.168.0.0/24 and 129.174.1.0/24 in the NGx
local encryption domain,
b- create an Interoperable device in NGx smartDashboard for ASA.
In the Topology, include the "outside" interface as the ASA
encryption domain,
c- create a vpn community with both the NGx and the ASA in the
community, select per host,
d- disable NAT inside the VPN community, because the NGx does not
know that the ASA is natting traffics for the 10.0.0.0/22 net,
e- create access rule, allow traffics from the ASA "outside" interface
to access resources behind the NGx,
It is important to note that if you the NGx firewall does NOT use
"disable NAT inside the vpn tunnel", he/she will have to create
a no-NAT rule and place it above any 'hide' or "static" nat in the
NAT translation.
You have to setup your Pix properly so that it will take account
into the NAT/PAT before VPN.
The scenario I provided proves that the encryption domain does not
have to match exactly on each side. If it does, NGx would have problem
communicating with Juniper over the VPN
Good Luck to you!!!!
04-18-2008 05:00 AM
I'll try it and let you know. Tnaks for all the help.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: