[Solved] VPN negtiation timout but no errors?

[sw2090]

Hi,

I just set up a new IPSEC Tunnel from one of my FGT to a remote Site (which tends to be CISCO). We have many of such tunnel to this Site which work. This time tha tunnel gets terminated in phase1 due to negotion timeout but there are no reported errors in the log:

The connection starts:

ike 0:fil_e2-dat_e1: schedule auto-negotiate ike 0:fil_e2-dat_e1: auto-negotiate connection ike 0:fil_e2-dat_e1: created connection: 0x118b1950 8 <ip_of_fgt>-><ip_of_remote_end>:500. ike 0:fil_e2-dat_e1:370440: initiator: main mode is sending 1st message... ike 0:fil_e2-dat_e1:370440: cookie b877b4a9173e298a/0000000000000000 ike 0:fil_e2-dat_e1:370440: out B877B4A9173E298A00000000000000000110020000000000000001200D00003800000001000000010000002C010100010000002401010000800B0001800C1F4080010007800E010080030001800200028004000E0D0000144A131C81070358455C5728F20E95452F0D0000147D9419A65310CA6F2C179D9215529D560D000014CD60464335DF21F87CFDB2FC68B6A4480D00001490CB80913EBB696E086381B5EC427B1F0D00001416F6CA16E4A4066D83821A0F0AEAA8620D0000144485152D18B6BBCD0BE8A8469579DDCC0D000014AFCAD71368A1F1C96B8696FC775701000D0000144048B7D56EBCE88525E7DE7F00D6C2D30D0000184048B7D56EBCE88525E7DE7F00D6C2D3C0000000000000148299031757A36082C6A621DE00000000 ike 0:fil_e2-dat_e1:370440: sent IKE msg (ident_i1send): <ip_of_fgt>:500-><ip_of_remote_end>:500, len=288, id=b877b4a9173e298a/0000000000000000 ike 0: comes <ip_of_remote_end>:500-><ip_of_fgt>:500,ifindex=8.... ike 0: IKEv1 exchange=Identity Protection id=14961d6d3f16486a/3f553c6066e91fac len=176 ike 0: in 14961D6D3F16486A3F553C6066E91FAC0110020000000000000000B00D00003800000001000000010000002C010100010000002401010000800B0001800C1F4080010007800E010080030001800200028004000E0D000014882FE56D6FD20DBC2251613B2EBE5BEB0D00001412F5F28C457168A9702D9FE274CC01000D00000C09002689DFD6B7120D000014AFCAD71368A1F1C96B8696FC77570100000000144A131C81070358455C5728F20E95452F ike 0:fil_e2-dat_e1:370438: initiator: main mode get 1st response... ike 0:fil_e2-dat_e1:370438: VID unknown (16): ▒t▒6 ike 0:fil_e2-dat_e1:370438: VID CISCO-UNITY 12F5F28C457168A9702D9FE274CC0100 ike 0:fil_e2-dat_e1:370438: peer supports UNITY ike 0:fil_e2-dat_e1:370438: VID draft-ietf-ipsra-isakmp-xauth-06.txt 09002689DFD6B712 ike 0:fil_e2-dat_e1:370438: VID DPD AFCAD71368A1F1C96B8696FC77570100 ike 0:fil_e2-dat_e1:370438: DPD negotiated ike 0:fil_e2-dat_e1:370438: VID RFC 3947 4A131C81070358455C5728F20E95452F ike 0:fil_e2-dat_e1:370438: selected NAT-T version: RFC 3947 ike 0:fil_e2-dat_e1:370438: negotiation result ike 0:fil_e2-dat_e1:370438: proposal id = 1: ike 0:fil_e2-dat_e1:370438: protocol id = ISAKMP: ike 0:fil_e2-dat_e1:370438: trans_id = KEY_IKE. ike 0:fil_e2-dat_e1:370438: encapsulation = IKE/none ike 0:fil_e2-dat_e1:370438: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=256 ike 0:fil_e2-dat_e1:370438: type=OAKLEY_HASH_ALG, val=SHA. ike 0:fil_e2-dat_e1:370438: type=AUTH_METHOD, val=PRESHARED_KEY. ike 0:fil_e2-dat_e1:370438: type=OAKLEY_GROUP, val=MODP2048. ike 0:fil_e2-dat_e1:370438: ISAKMP SA lifetime=8000 ike 0:fil_e2-dat_e1:370438: out 14961D6D3F16486A3F553C6066E91FAC0410020000000000000001640A0001049168CA2EEB4DD61A00B1FFAC046A03546496812E8836935DB1B16F3E6750D0B9151523259118A85F6303BBEDB5DFAA796E56D80662B5009D7E01CE817F9726BFC74D9F93878A2F7DD5D4D3444740E7C551A4501C5F8D5E2397726525A336CD2270B46C7976055EFE122B307A08EB3253251529BB2AF0FBFF712DE68D794012043222D6A1D44F870BB4211888B8AB7F1BC5094578DD2EC6801FD6FB53339A4F39D278658A792284AABA4F48E7E8766F16EF75B94CBE135DC1358D75AD6C3AD6E83BDB1D7B54B6FB5613BDFD1610F72E64064761EF2937E55672A734479A665D54C06B0A324BE880A555914657755F914F1DB0A5F031D16E020005700E8168267C140000142AA61ECE85879A17E45D8BD2417AB2B614000018A0A7941045146F5B655475ADD115183E75B0CAAC000000184B58EB389B0A75DDA840E70D58A669A3A31CEB6D ike 0:fil_e2-dat_e1:370438: sent IKE msg (ident_i2send): <ip_of_fgt>:500-><ip_of_remote_end>:500, len=356, id=14961d6d3f16486a/3f553c6066e91fac ike 0: comes 80.152.206.145:4500-><ip_of_fgt>:4500,ifindex=8.... ike 0: IKEv2 exchange=INFORMATIONAL_RESPONSE id=8e2f5649e0aac574/d338e2bc4affd644:0000039e len=96 ike 0: in 8E2F5649E0AAC574D338E2BC4AFFD6442E2025200000039E00000060000000448B147A1C8A0AD8D0325DC16E378C29E81297D25234C57EB0B2C5A09C0A84238D23178DC0AFA8CBB7AAB92F3EB35F1443C9B69C8DAD9A348BA6B4C1D537D96F9F

ike 0: comes <ip_of_remote_end>:500-><ip_of_fgt>:500,ifindex=8.... ike 0: IKEv1 exchange=Identity Protection id=14961d6d3f16486a/3f553c6066e91fac len=356 ike 0: in 14961D6D3F16486A3F553C6066E91FAC0410020000000000000001640A000104C4AE601ED536BFD36D7F0FC20050F66F7F825497A3A9ACDD2AE0D13F234B5512A678F59612004C4370AD3DE3406A8D637BCCF82C7B6FB2F2EEEB70C06C05A38F81F1ABE7C16F34829EEABCB367BDCB4AE214D4B55732601A261194F8BC54E8AC02B612142076B537670D50C96322405209D80E62E2D8F2E443055B7C562940BC8C14AA98C707E59669E4BD67D006C67750DDABE0F6D1D9A70B6ACC2D254B9FFCACC067B1C50F5A6690B4DCFDB8116949E8638011CD3916C30197B2769853B23806D75CCB3360D9A0465D900CF4AE1E074FF5CA4DEF7D9BB5A9DB3D530EB7292ED68E0F04D544BD93E8F66931A3F1029CD10FFA2EE04AA0F3576A5664A6CB27E014000014B081762540D8023F9556CC04E059E9CA14000018FEECB2CDC409CCDCAA079665D9016C63DF66460800000018A0A7941045146F5B655475ADD115183E75B0CAAC ike 0:fil_e2-dat_e1:370438: initiator: main mode get 2nd response... ike 0:fil_e2-dat_e1:370438: NAT detected: ME ike 0:fil_e2-dat_e1:370438: NAT-T float port 4500 ike 0:fil_e2-dat_e1:370438: ISAKMP SA 14961d6d3f16486a/3f553c6066e91fac key 32:1F446BB40AA58BA41F176BCDCE15391F769AE524C6103792A378EAA151647037 ike 0:fil_e2-dat_e1:370438: add INITIAL-CONTACT ike 0:fil_e2-dat_e1:370438: enc 14961D6D3F16486A3F553C6066E91FAC05100201000000000000005C0800000C010000000A1CFE0A0B00001823FEBB242C5E461703392889DA6F22FF05E500580000001C000000010110600214961D6D3F16486A3F553C6066E91FAC ike 0:fil_e2-dat_e1:370438: out 14961D6D3F16486A3F553C6066E91FAC05100201000000000000006CCFAC83876F2B57E046A93E45A915E5A00E8E32C8CEEFA34EDD159628C3E02F1E686819A30A49C61A6C8875BB63D272F8311FA2BCAD3F0881270A562CADFE34C716C8E7A0B43E03355C7E9E6F97AD211D ike 0:fil_e2-dat_e1:370438: sent IKE msg (ident_i3send): <ip_of_fgt>:4500-><ip_of_remote_end>:4500, len=108, id=14961d6d3f16486a/3f553c6066e91fac ike 0: comes <ip_of_remote_end>:500-><ip_of_fgt>:500,ifindex=8.... ike 0: IKEv1 exchange=Informational id=14961d6d3f16486a/3f553c6066e91fac:51da3eaa len=76 ike 0: in 14961D6D3F16486A3F553C6066E91FAC0810050151DA3EAA0000004C25E6CBBC380CCB26039353B6C960C8F3EB3A39226208E8317DF8F8C6C0E44CF01E0A2850C991F25A53A182CAEC13A495 ike 0:fil_e2-dat_e1:370438: dec 14961D6D3F16486A3F553C6066E91FAC0810050151DA3EAA0000004C1CF5C5E69CF0D37883BCF8835E869E3B0C3FB82632241ADD6C943C1CE824C0373485524F1E63EA0CFFC1BB092D0F7B7D

Afterwards I see several P1_RETRANSMIT attempts like this:

ike 0:fil_e2-dat_e1:370440: out B877B4A9173E298A8596BD5F7895EDA305100201000000000000006C5FF7595E87F64F43BC2E1B3226F1FF46E5A793DE83FE29C4EF696F0FD90120A2A9E11498A64D845CC9BBC48ED3ADB1D8C0C06353DA176278D9799DF5D61595AF2CEB5F7737257DD293A20409E92BE49F ike 0:fil_e2-dat_e1:370440: sent IKE msg (P1_RETRANSMIT): <ip_of_fgt>:4500-><ip_of_remote_end>:4500, len=108, id=b877b4a9173e298a/8596bd5f7895eda3 ike 0: comes <ip_of_remote_end>:500-><ip_of_fgt>:500,ifindex=8.... ike 0: IKEv1 exchange=Informational id=b877b4a9173e298a/8596bd5f7895eda3:b2ceacff len=76 ike 0: in B877B4A9173E298A8596BD5F7895EDA308100501B2CEACFF0000004CCB36F2BBBBA0B1EB465A94AD5B3C347CF5719D40CD84EDC1F89F2B8A518FF5753DBF071BAEBF7E8C7AA64DDFA7B68C28 ike 0:fil_e2-dat_e1:370440: dec B877B4A9173E298A8596BD5F7895EDA308100501B2CEACFF0000004C690B44395B1CCA084B8C0A9E0DBF58D40264AF8777D14A8A9B738D985820CB60E70445BA106B2CE01E97F069B559A7A0

after several attempts the FGT seems to give up:

ike 0:fil_e2-dat_e1:370439: negotiation timeout, deleting ike 0:fil_e2-dat_e1: connection expiring due to phase1 down ike 0:fil_e2-dat_e1: deleting ike 0:fil_e2-dat_e1: deleted

There is nothing about not matching psk (double checked this already). Proposals in P1 are chosen. NAT-T and DPD are met accoarding to log.

There also is no error msgs in here. 

Any advice what could be the problem is welcome!

cheers

Sebastian

[ede_pfau]

I see that your side is using NAT. Does the remote side have NAT traversal enabled?

[sw2090]

yes NAT-T is enabled here indeed. This is needed because wothout the runnel would run into udp aging timeouts because of too long idle times ;)

I am currently not sure if the remote side has enabled it since they gave me new remote gw. 

This is the first one with remote cisco afair. The ones before had lancom on remote end.

Anyhows I've sent their support the complete logs I've shown here (execpt form anonymization of ips - they know their ip and may know ours) so they could check too.

[sw2090]

NAT-T was not the problem. Indeed the problem was the WAN IP. The FGT is behind a Lancom that does the internet connection. Thus IPSec packages pass the Lancom without NAT. So opposite Side don't see my WAN IP but the WAN IP of the WAN Interface of the FGT. Once remote Side changed this the tunnel came up and works.

[Stemjay]

hi sw2090, i have a similar challenge with no visibility if the remote may be natting from their end, kindly advise steps that taken be taken to resolve thi