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

IPSEC VPN from PIX 6.2 to Firewall-1 V 4.1 SP5

s.hebel
Level 1
Level 1

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...

3 Replies 3

afakhan
Level 4
Level 4

Hello,

Please re-enter the pre-shared key line on the PIX with the key spelt correctly.

Thanks,

Afaq

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.

abibby
Level 1
Level 1

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