CheckPoint SecureClient to Cisco PIX

I have a network configured as follows:

Internal LAN PIX-535 { Internet } Customer CheckPoint FW/1

The internal LAN is NATted to the external address of the PIX and all internal hosts are PATted against this address (hence we have only one external "visible" IP address defined).

We are trying to establish a CheckPoint SecureClient connection from inside the network on the internal LAN to a customer site on the Internet running a CheckPoint firewall. The connection type we are doing is using the RSA keyfobs as security.

When attempting to connect using the SecureClient software. The connection always fails with an error from the SecureClient software "Make sure the user is properly defined on the firewall". From the logs on the customer site we only see the initial conversation but do not get any key exchange happening. It appears that the local firewall (ie: the pix) is the cause of the problem. If I take the same computer and software and plug into a home network behind a broadband router with VPN passthru, the connection establishes successfully. From the above network we do not block any outbound services and all outgoing protocols work fine (eg: web, IM, telnet, ssh, ftp, etc).

During my reading of this forum and others, it would appear that VPN traversal might be the problem, however I have enabled it (with "isakmp enable inside" and "isakmp nat-traversal 20") but this does not solve the problem. The PIX is runnnig 7.0(1).

I cannot see any local logs to see what is being dropped and do not understand what more is available to get the VPN to transgres the firewall. What special ports (if any) need to be opened to the NAT/PAT address?

Appreciate any help

Reply to
Loading thread data ...

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

formatting link
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


show crypto ipsec sa

formatting link
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



state QM_IDLE





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.

local ident (addr/mask/prot/port): (

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


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

formatting link
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

formatting link
Hope this helps.

Brad Reese BradReese.Com - Cisco Network Engineer Directory

formatting link
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:
formatting link

Reply to

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.

Reply to
Walter Roberson

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.

Reply to

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

formatting link

Brad Reese Cisco Repair

formatting link

Reply to

formatting link
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

Reply to

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


It doesn't.

formatting link

Errrr... I've posted the relevant information a number of times over in, which is the main newsgroup in which PIXen get discussed. I've also posted here in several times pointing over to . 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"... 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.

Reply to
Walter Roberson Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.