VPN between PIX 535 and Checkpoint NGX

Unanswered Question
Apr 16th, 2008

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?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
cisco24x7 Wed, 04/16/2008 - 09:11

'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

carlos.baez Wed, 04/16/2008 - 09:47

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

carlos.baez Thu, 04/17/2008 - 07:07

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

cisco24x7 Thu, 04/17/2008 - 09:13

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

carlos.baez Thu, 04/17/2008 - 10:10

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

cisco24x7 Thu, 04/17/2008 - 12:26

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

carlos.baez Thu, 04/17/2008 - 13:55

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.

Attachment: 
cisco24x7 Thu, 04/17/2008 - 17:03

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!!!!

Attachment: 

Actions

This Discussion