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

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

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

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

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

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.

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

I'll try it and let you know. Tnaks for all the help.