cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
830
Views
0
Helpful
3
Replies

Ipsec Pix---Checkpoint NG with AES

minoc
Level 1
Level 1

Hello all,

I am trying to setup a vpn tunnel between a Pix 525 VAC (6.3(3)) and a Firewall-1 NG with AES-256 encryption.

After configuring both devices as per Cisco documentation. Traffic flowing from inside Pix to Firewall internal resource does not pass trough.

Here is a snippet of the running config in the Pix:

-- Interesting traffic for VPN

access-list 101 permit ip host 192.168.100.12 host 192.168.51.8

-- Perfom no NAT in vpn tunnel

access-list omb-vpn permit ip host 192.168.100.12 host 192.168.51.8

-- Servers is a DMZ interface on the pix

nat (Servers) 0 access-list omb-vpn

crypto ipsec transform-set opcv esp-aes-256 esp-sha-hmac

crypto dynamic-map dynmap 10 set transform-set opcv

crypto map opcvmap 10 ipsec-isakmp

crypto map opcvmap 10 match address 101

crypto map opcvmap 10 set pfs group2

crypto map opcvmap 10 set peer 64.185.193.97

crypto map opcvmap 10 set transform-set opcv

crypto map opcvmap 20 ipsec-isakmp dynamic dynmap

crypto map opcvmap client authentication cliauth

crypto map opcvmap interface outside

crypto map opcvmap interface Interagencial

isakmp enable outside

isakmp enable Interagencial

isakmp key ******** address 64.185.193.97 netmask 255.255.255.255 no-xauth no-co

nfig-mode

isakmp identity address

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption aes-256

isakmp policy 10 hash sha

isakmp policy 10 group 2

isakmp policy 10 lifetime 86400

Here is the show cryp isakmp sa command:

Total : 6

Embryonic : 0

dst src state pending created

64.185.228.2 64.185.193.97 QM_IDLE 0 2

64.185.228.2 64.185.193.97 QM_IDLE 0 1

64.185.228.2 64.185.193.97 QM_IDLE 0 1

64.185.228.2 64.185.193.97 QM_IDLE 0 1

64.185.228.2 64.185.193.97 QM_IDLE 0 1

64.185.228.2 64.185.228.148 QM_IDLE 0 1

Show cry ipsec sa:

interface: Interagencial

Crypto map tag: opcvmap, local addr. 64.185.222.2

local ident (addr/mask/prot/port): (192.168.100.12/255.255.255.255/0/0)

remote ident (addr/mask/prot/port): (192.168.51.8/255.255.255.255/0/0)

current_peer: 64.185.193.97:0

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

local crypto endpt.: 64.185.222.2, remote crypto endpt.: 64.185.193.97

path mtu 1500, ipsec overhead 0, media mtu 1500

current outbound spi: 0

inbound esp sas:

inbound ah sas:

inbound pcp sas:

As you can see the vpn tunnel never came up. But the isakmp process worked as expected.

When perfoming debug cryp ipsec and isakmp and doing test from host 192.168.100.12 to host 192.168.51.8 the console showed the following message:

crypto_isakmp_process_block:src:64.185.193.97, dest:64.185.228.2 spt:500 dpt:500

ISAKMP: sa not found for ike msg

Which I think means the tunnel has no been synchronized between both devices.

On the Checkpoint side everything seems to be ok. Packets from inside resource appeared encrypted while doing test and looking at the SmartView Tracker.

Anyone can help me sort this out?

Regards,

Carlos Roque

3 Replies 3

Patrick Iseli
Level 7
Level 7

Looks as the same problem that I had once, the IPSEC phase two is unable to get the SA initiated. In my case it was a problem with the access-list in the PIX that did not entirely correspond to the encryption domain on the checkpoint firewall.

Check if they are really identical.

PIX(config)# access-list VPN permit ip Internalnet ISubnet Externalnet ESubnet

crypto map REMOTE 10 match address VPN

2.) Check the IKE timeouts on both sites

3.) I had some troubles with PFS and DH group 2 to get it working. Finally group 1 worked. Might it be that AES works just with group 5?

sincerely

Patrick

I found the problem was, basically the crypto map was applied to two interfaces (Outside, and the other interface pointing to our WAN cloud) so the pix was sending packets from the internal host to the outside interface instead of the other.

I worked this with a Cisco engineer and what he did was to add a static route pointing to the checkpoint external interface for traffic going to the host behind it.

Since I needed to have VPN to a peer and to vpn clients I created two crypto maps, one was applied to our wan side for site to site vpn and the other to the outside interface for vpn clients.

So far everything is working as expected.

Thanks for tour response...

Carlos Roque

ozgur.guler
Level 1
Level 1

as patrick says usually the problem is non matching proxy definitions.

initiate the tunnel from cp side and do a

debug crypto ipsec on the pix,

thn configure your pix acl accordingly.

are you sure you have aes enabled on your pix interoperable device object? that might also cause such a problem.