07-31-2002 06:54 AM - edited 02-21-2020 11:58 AM
Just wondering if anyone has successfully configured a VPN tunnel from a PIX
at V 6.2 to a Nokia 440 (or similar) running Firewall-1 V 4.1 SP5.
The configuration at both ends is:
IKE Key exchange
3DES Encryption
SHA1 Hash
Pre-shared secret
Diffie Hellman Group 2
PIX config:
sysopt connection permit-ipsec
no sysopt route dnat
crypto ipsec transform-set dg esp-3des esp-sha-hmac
crypto dynamic-map dynmap 10 set transform-set dg
crypto map dgmap 5 ipsec-isakmp
crypto map dgmap 5 match address st_vpn
crypto map dgmap 5 set peer 64.x.x.x
crypto map dgmap 5 set transform-set dg
crypto map dgmap 10 ipsec-isakmp dynamic dynmap
crypto map dgmap client configuration address initiate
crypto map dgmap client configuration address respond
crypto map dgmap interface outside
isakmp enable outside
isakmp key ******** address 0.0.0.0 netmask 0.0.0.0
isakmp key ******** address 64.x.x.x netmask 255.255.255.255
isakmp identity address
isakmp client configuration address-pool local vpn_client outside
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash sha
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
We have other dynamic VPN clients using the PIX as well.
Phase 1 completes OK but phase 2 fails with an errror message
which I fail to understand.
The config on the Nokia is as per a document provided by Nokia.
Any ideas or suggestions would be much appreciated.
Simon.
PIX debug output:
(identity) local= 213.x.x.x, remote= 64.x.x.x,
local_proxy= 17.254.7.5/255.255.255.255/0/0 (type=1),
remote_proxy= 10.10.10.6/255.255.255.255/0/0 (type=1)
VPN Peer: ISAKMP: Added new peer: ip:64.x.x.x Total VPN Peers:5
VPN Peer: ISAKMP: Peer ip:64.x.x.x Ref cnt incremented to:1 Total VPN Peers:5
ISAKMP (0): beginning Main Mode exchange
crypto_isakmp_process_block: src 64.x.x.x, dest 213.x.x.x
OAK_MM exchange
ISAKMP (0): processing SA payload. message ID = 0
ISAKMP (0): Checking ISAKMP transform 1 against priority 10 policy
ISAKMP: encryption 3DES-CBC
ISAKMP: hash SHA
ISAKMP: default group 2
ISAKMP: auth pre-share
ISAKMP: life type in seconds
ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
ISAKMP (0): atts are acceptable. Next payload is 0
ISAKMP (0): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
return status is IKMP_NO_ERROR
crypto_isakmp_process_block: src 64.x.x.x, dest 213.x.x.x
OAK_MM exchange
ISAKMP (0): processing KE payload. message ID = 0
ISAKMP (0): processing NONCE payload. message ID = 0
ISAKMP (0): ID payload
next-payload : 8
type : 1
protocol : 17
port : 500
length : 8
ISAKMP (0): Total payload length: 12
return status is IKMP_NO_ERROR
crypto_isakmp_process_block: src src 64.x.x.x, dest 213.x.x.x
OAK_MM exchange
ISAKMP (0): processing ID payload. message ID = 0
ISAKMP (0): processing HASH payload. message ID = 0
ISAKMP (0): SA has been authenticated
ISAKMP (0:0): Need config/address
ISAKMP (0:0): initiating peer config to 64.x.x.x. ID = 2678742696 (0x9faa5ea8)modecfg: sa: 81031700, new mess id= 9faa5ea8
return status is IKMP_NO_ERROR
ISAKMP (0): sending INITIAL_CONTACT notify
ISAKMP (0): sending NOTIFY message 24578 protocol 1
crypto_isakmp_process_block: src src 64.x.x.x, dest 213.x.x.x
ISAKMP: reserved not zero on payload 5!
crypto_isakmp_process_block: src src 64.x.x.x, dest 213.x.x.x
ISAKMP: reserved not zero on payload 5!
ISAKMP (0): retransmitting phase 2...
08-01-2002 11:31 PM
Hello,
Please re-enter the pre-shared key line on the PIX with the key spelt correctly.
Thanks,
Afaq
08-02-2002 03:43 AM
Afaq,
thanks for the advice but the shared secret is fine on both ends.
If we configure an incorrect shared secret the negotiation fails to
get past phase 1.
However, we appear to have fixed the problem by adding the
no-config-mode directive to the isakmp key statement:
isakmp key ***** address 64.x.x.x netmask 255.255.255.255 no-config-mode
It would appear that the PIX was trying to allocate a dynamic IP to the
checkpoint firewall, when of course this is hard coded.
Simon.
12-17-2002 10:18 AM
I am having a very similar problem, only that it works fine for when I use DES, but as soon as I change to 3DES it fails at the phase 2 negotiation, claiming it keeps seeing duplicate packets. I have set up a seperate policy and all I'm changing is the transform set to use esp-3des instead of esp-des.
Was this problem solved?
Many thanks,
Aron
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