10-20-2004 10:33 AM - edited 02-21-2020 01:24 PM
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
10-21-2004 12:23 PM
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
10-25-2004 07:35 AM
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
10-23-2004 11:58 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide