CheckPoint SecureClient to Cisco PIX

How to configure an IPSec tunnel between a PIX Firewall and a Checkpoint Firewall.

To set up the IPSec VPN tunnel, perform these steps:

Step 1: Configure the Internet Key Exchange (IKE) proposal on both devices.

Step 2: Configure the IPSec parameters on both devices.

Step 3: Specify network ranges on both devices for passing traffic across the proposed tunnel.

For assistance with the configuration settings, resolving an IPSec tunnel between a PIX Firewall and Checkpoint Firewall as well as specific debug setting information, refer to:

Configuring an IPSec Tunnel - Cisco Secure PIX Firewall to Checkpoint

4.1 Firewall

Step 4: Once the tunnel has been configured, attempt to pass traffic from a workstation on one side of the connection to a workstation on the other side of the connection.

If you are able to ping, the tunnel is functioning properly.

If you are not able to ping, determine the state of the connection by issuing the

show crypto isakmp sa

and

show crypto ipsec sa

commands on the PIX Firewall.

Step 5: If in the output of the show crypto isakmp sa command the state shows anything other than QM_IDLE, phase 1 (Internet Security Association and Key Management Protocol [ISAKMP]) has not been properly negotiated and should be examined.

The results should resemble this example:

cisco_endpoint# show crypto isakmp sa

dst

172.18.124.157

src

172.18.124.35

state QM_IDLE

pending

0

created

2

Issuing the show crypto ipsec sa command identifies information about phase 2 of the connection (IPSec).

Step 6: The proper peer and local endpoint for the tunnel should be identified.

Furthermore, if traffic has been passed across the tunnel, the counters for both pkts encaps and pkts decaps should be incrementing.

If either value is not incrementing, a determination can usually be made as to which side of the tunnel is having difficulty.

This is a portion of the command output:

cisco_endpoint#show crypto ipsec sa

interface: outside

Crypto map tag: rtpmap, local addr. 172.18.124.158

local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

current_peer: 172.18.124.157

PERMIT, flags={origin_is_acl,}

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

-------------------------------------

For information on tunnels between a PIX Firewall and Checkpoint New Generation (NG) Firewall, refer to:

Configuring an IPSec Tunnel Between a Cisco Secure PIX Firewall and a Checkpoint NG Firewall

For more information in resolving the PIX Firewall passing traffic on an established IPSec tunnel, refer to:

Troubleshooting the PIX to Pass Data Traffic on an Established IPSec Tunnel

Hope this helps.

Brad Reese BradReese.Com - Cisco Network Engineer Directory

Hendersonville Road, Suite 17 Asheville, North Carolina USA 28803 USA & Canada: 877-549-2680 International: 828-277-7272 Fax: 775-254-3558 AIM: R2MGrant Website:

Unfortunately, the task at hand is to configure a VPN tunnel that passes *through* the PIX, with a local software client on a host connecting to a remote CheckPoint device.

Hi Brad

Thanks for your posting. I think the problem I have is even more simple than this. We are running the SecureClient software on a PC and attempting the connection from the PC on the inside network to the CheckPoint on the Internet. We are not attempting to make a connection between the PIX and the FW/1, but rather between PC's and the FW/1.

The problem appears to be something to do with the PIX blocking the IKE. The same PCs (laptops) when connecting from behind a vanilla broadband router with VPN passthru work perfectly, but I cannot get the same PCs to connect from behind the PIX. We are doing NAT/PAT on the PIX and I have enabled VPN traversal. The PIX for whatever reason does not want to allow the traffic through to the client PC.

Any thoughts? Is there any specific ports that should be open to allow the ESP/IKE to work? What access-lists/features should be enabled on the PIX to permit VPN passthru to occur?

Appreciate any help.

You may wish to investigate Cisco's IPSec NAT Transparency:

Sincerely,

Brad Reese Cisco Repair

Hi Brad

I checked out the link that you advertised but unfortunately this is more focused on routers and not pixies. All is not lost however as I did manage to fix the problem.

At first I upgraded from 7.0(1) to 7.2(1) which in itself did not solve the issue. After that however I decided to review the method of PAT we were using. I decided to try changing this to NAT by providing a pool of IP addresses (we are lucky to be blessed with a C class rather than a single IP address). After creating the pool I tried to again re-instate the correct rules to allow ah/esp/udp through (basically tunnel traffic) and enabled the new "inspect ipsec-pass-thru" policy and that fixed the problem.

It would appear that if you PAT against the external interface of the pix this prevents you from passing traffic through to systems behind the firewall. I suspect that if I was to PAT against an external address that was NOT the firewall, this might work as well. I will be trying this later today to confirm my suspicions that the pix interface address prevents pass through of IPSEC traffic.

I certainly hope this helps some one else out as it took considerable effort to find this out (I still haven't seen any other links that seemed to indicate that this was a problem).

Thank you for taking the time to go through the problem. It is always useful having new things to look at which give hints to the solution.

Cheers and regards

In article , wrote: [Cisco PIX 7.0(1), 7.2(1)]

No.

It doesn't.

Errrr... I've posted the relevant information a number of times over in comp.dcom.sys.cisco, which is the main newsgroup in which PIXen get discussed. I've also posted here in comp.security.firewalls several times pointing over to comp.dcom.sys.cisco . I read your posting the first day, and knew my previous postings covered the answer, and I chose not to respond.

Sorry about that, but I don't work with PIXen anymore, and I'm trying to "fall back" and let other people take over, particularily for questions I've pretty much answered before I'm experimenting with that "There's life outside of Usenet!" hypothesis; the last few days my spare time has been spent doing a lot of digging for the garden.

I would say, "If you have a PIX problem, read my past postings in comp.dcom.sys.cisco"... but as it turns out that I've made somewhere between 3000 and 5000 PIX related postings there, it has perhaps become the proverbial needle-in-haystack problem.