Phase 2 tunnel is not going up between PIX 525 and Watchguard

[conceptzone]

Hi Folks,

Can you please help me in knowing where is the problem liying, currently I am trying to establish a VPN tunnel between PIX firewall and Watchguard , all the parameters of both devices are the same though Phase two tunnel is not coming up.

here is the debug :

crypto_isakmp_process_block:src:212.37.17.43, dest:212.118.128.233 spt:500 dpt:500

OAK_MM exchange

ISAKMP (0): processing KE payload. message ID = 0

ISAKMP (0): processing NONCE payload. message ID = 0

ISAKMP (0:0): Detected NAT-D payload

ISAKMP (0:0): NAT does not match MINE hash

hash received: b3 8f bb 0 93 3b 65 e8 35 6f 54 6 c4 6f 59 cc

my nat hash : dd 70 9 ac 35 58 40 da 3b 5b fc 1b 4c 87 d2 11

ISAKMP (0:0): Detected NAT-D payload

ISAKMP (0:0): NAT does not match HIS hash

hash received: ba 72 c5 e 5b fb 88 f0 1e f7 8a ba c9 c6 c1 cc

his nat hash : c 4c 89 a5 66 c1 dd 80 76 48 3f a5 b0 f0 56 ed

ISAKMP (0:0): constructed HIS NAT-D

ISAKMP (0:0): constructed MINE NAT-D

return status is IKMP_NO_ERROR

crypto_isakmp_process_block:src:212.37.17.43, dest:212.118.128.233 spt:4500 dpt:4500

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: Created a peer struct for 212.37.17.43, peer port 37905

ISAKMP: Locking UDP_ENC struct 0x3cbb634 from crypto_ikmp_udp_enc_ike_init, count 1

ISAKMP (0): ID payload

next-payload : 8

type : 2

protocol : 17

port : 0

length : 23

ISAKMP (0): Total payload length: 27

return status is IKMP_NO_ERROR

ISAKMP (0): sending INITIAL_CONTACT notify

ISAKMP (0): sending NOTIFY message 24578 protocol 1

VPN Peer: ISAKMP: Added new peer: ip:212.37.17.43/4500 Total VPN Peers:16

VPN Peer: ISAKMP: Peer ip:212.37.17.43/4500 Ref cnt incremented to:1 Total VPN Peers:16

crypto_isakmp_process_block:src:212.37.17.43, dest:212.118.128.233 spt:4500 dpt:4500

ISAKMP (0): processing NOTIFY payload 24578 protocol 1

spi 0, message ID = 3168983470

ISAKMP (0): processing notify INITIAL_CONTACT

return status is IKMP_NO_ERR_NO_TRANS

crypto_isakmp_process_block:src:212.37.17.43, dest:212.118.128.233 spt:4500 dpt:4500

OAK_QM exchange

oakley_process_quick_mode:

OAK_QM_IDLE

ISAKMP (0): processing SA payload. message ID = 484086886

ISAKMP : Checking IPSec proposal 1

ISAKMP: transform 1, ESP_3DES

ISAKMP: attributes in transform:

ISAKMP: SA life type in seconds

ISAKMP: SA life duration (basic) of 28800

ISAKMP: SA life type in kilobytes

ISAKMP: SA life duration (basic) of 32000

ISAKMP: encaps is 61433

ISAKMP: authenticator is HMAC-MD5

ISAKMP (0): atts not acceptable. Next payload is 0

ISAKMP (0): SA not acceptable!

ISAKMP (0): sending NOTIFY message 14 protocol 0

return status is IKMP_ERR_NO_RETRANS

crypto_isakmp_process_block:src:212.37.17.43, dest:212.118.128.233 spt:4500 dpt:4500

ISAKMP: phase 2 packet is a duplicate of a previous packet

ISAKMP: resending last response

ISAKMP (0:0): sending NAT-T vendor ID - rev 2 & 3

crypto_isakmp_process_block:src:212.37.17.43, dest:212.118.128.233 spt:4500 dpt:4500

ISAKMP: phase 2 packet is a duplicate of a previous packet

ISAKMP: resending last response

crypto_isakmp_process_block:src:213.210.211.82, dest:212.118.128.233 spt:500 dpt:500

ISAKMP (0): processing NOTIFY payload 36136 protocol 1

spi 0, message ID = 287560609

ISAMKP (0): received DPD_R_U_THERE from peer 213.210.211.82

ISAKMP (0): sending NOTIFY message 36137 protocol 1

return status is IKMP_NO_ERR_NO_TRANSdebug

ISAKMP (0): retransmitting phase 1 (0)...

Thanks,

Ismail

[kaachary · Accepted solution]

Hi,

From the debug it seems the parametes are not same on the devices :

ISAKMP (0): atts not acceptable. Next payload is 0

Please check Phase 2 parameters and also make sure that on Watchguard you have PFS disabled.

*Please rate if helped.

-Kanishka

[conceptzone]

Hi Kanishka,

The Phase 2 Parameters are the same also PFS is disabled !

There are some curious things in the debug msg, could you please throw some light on them

ISAKMP (0): Checking ISAKMP transform 1 against priority 1 policy

ISAKMP: encryption 3DES-CBC

ISAKMP: hash MD5

ISAKMP: auth pre-share

ISAKMP: life type in seconds

ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80

ISAKMP: default group 1

ISAKMP (0): atts are acceptable. Next payload is 0

ISAKMP (0): processing vendor id payload

ISAKMP (0:0): vendor ID is NAT-T

ISAKMP (0): processing vendor id payload

what does the vendor ID is NAT-T above mean ? Is it say that both sides are using Nat traversal.

Also in ecryption its says encryption 3DES-CBC

i am not sure if this CBC is the culprit. Because thats what watchgaurd uses only it does not have an option for only 3DES.

strange enought that Phase 1 is getting up, I am also questioning myself about the following message appearing in Phase 1:

ISAKMP (0:0): Detected NAT-D payload

ISAKMP (0:0): NAT does not match MINE hash

hash received: b3 8f bb 0 93 3b 65 e8 35 6f 54 6 c4 6f 59 cc

my nat hash : dd 70 9 ac 35 58 40 da 3b 5b fc 1b 4c 87 d2 11

ISAKMP (0:0): Detected NAT-D payload

ISAKMP (0:0): NAT does not match HIS hash

hash received: ba 72 c5 e 5b fb 88 f0 1e f7 8a ba c9 c6 c1 cc

his nat hash : c 4c 89 a5 66 c1 dd 80 76 48 3f a5 b0 f0 56 ed

ISAKMP (0:0): constructed HIS NAT-D

ISAKMP (0:0): constructed MINE NAT-D

return status is IKMP_NO_ERROR

how come Phase 1 is coming up though the PIX is claiming that his HASH is not the same as HIS HASH :(

the log messages on WATCH GUARD states that there is no proposal chosen!

why both firewalls are not friends?

I appreciate any input

[Kamal Malhotra · Accepted solution]

Hi Ismail,

As per the logs, NAT-T is not getting negotiated. You need to make sure that it is enabled on both the ends and that if there is any intermediate device then UDP 4500 should be allowed on it.

HTH,

Regards,

Please rate if it helps.

Kamal

[kaachary]

Ismail,

You might wanna disable NAT-T on both the ends, if its already enabled.

There are known issues with NAT-T version mismatch with third party vendor devices.

-Kanishka

[conceptzone]

Guys, Thanks Allot

The tunnel went up.

We disabled NAT from the Watchguard side.

:)

Thanks Again

[uakarsu]

can you send your watchguard and pix configuration to me ? because i have problems like that.

uakarsu@gmail.com

[Utair Corporation]

Sure long time passed, but for those, who find this post through search:

The problem is with Watchguard Firebox sending wrong encapsulation type 61433 instead of 61443. Probably a type in source code.

The fix is either updating Firebox firmware or avoid NAT.