Skip to main content
NetworkVA
NetworkVA
New Member
August 30, 2017
Question

Site to Site VPN - Phase 2 Failure (Network Diagram Attached)

  • August 30, 2017
  • 1 reply
  • 27678 views

Good Afternoon,

 

I am trying to bring up a site to site vpn between a Cisco device and a Fortigate 60D 5.4.5. Phase1 is coming up fine, but phase 2 is not establishing and giving me the error: ike 0:vpn2mpls:32522: notify msg received: NO-PROPOSAL-CHOSEN ike 0:vpn2mpls:32522:vpn2mpls:22985: IPsec SPI 2230d800 match ike 0:vpn2mpls:32522:vpn2mpls:22985: delete phase2 SPI 2230d800 All the phase1, phase 2 configuration security parameters match, and the subnet selectors match. The static routes, and firewall policy match as well. The Cisco side of the connection says they are not seeing any phase2 traffic reach the Cisco device. I attached a image of the visio I created. FORTINET PHASE 1: config vpn ipsec phase1-interface     edit "vpn2mpls"         set interface "wan1"         set keylife 3600         set peertype any         set proposal 3des-md5         set comments "VPN Phase 1 connection to MPLS network"         set dhgrp 1         set remote-gw 1.1.1.1         set psksecret ENC m05/qVmjVXqW1L6IZ1rBcdi2OOKAyKU+wGMQ1vtFHkPOKbBrSiEUc8r3qkO1OkE9VWgMMmw7wUQRoWLordYVWylwvgVtPRFqjUqSEUIQo8wWZZZpfTjC0PcmT29BQaEh9jsYX7BIa0skCsHPVQ33Mbk2XV1+6RAx12GULzhuR56ujahzvGaRS1uvIJcHacbQz8Tx0Q==     next end

FORTINET PHASE 2

    edit "vpn2mpls"         set phase1name "vpn2mpls"         set proposal 3des-md5         set dhgrp 1         set auto-negotiate enable         set keylife-type both         set comments "VPN Phase 2 connection to MPLS network"         set keylifeseconds 3600         set keylifekbs 216000         set src-subnet 192.168.19.0 255.255.255.0         set dst-subnet 192.11.11.0 255.255.255.0     next end

 

CISCO CONFIGURATION:

crypto keyring V1519:ccwho-50072066 vrf V1519:ccwho

  description ABC Comp - XYZ Site

  pre-shared-key address 1.1.1.2 key psksecret-fake

 

crypto isakmp profile V1519:ccwho-50072066

   vrf V1519:ccwho

   keyring V1519:ccwho-50072066

   match identity address 1.1.1.2 255.255.255.255 V1519:ccwho

 

crypto ipsec transform-set V1519:ccwho-50072066 esp-3des esp-md5-hmac

 

crypto map V1519:ccwho 20 ipsec-isakmp

 set peer 1.1.1.2

set security-association lifetime kilobytes 216000

set transform-set V1519:ccwho-50072066

 set pfs group1

set isakmp-profile V1519:ccwho-50072066

match address V1519:ccwho-50072066

 !

ip access-list extended V1519:ccwho-50072066

permit ip 192.11.11.0 0.0.0.255 192.168.19.0 0.0.0.255

1 reply

oheigl
oheigl
New Member
August 31, 2017

I guess they are wrong if they say that no "phase 2" traffic reaches their gateway, because they are sending the notify message to the FortiGate but anyway - from the first look you have enabled the key lifetime both data and seconds, but not on the Cisco side. Maybe change that and try again. Also is the FortiGate behind a NAT or did you mask the ip addresses? Maybe NAT traversal needs to be enabled on both gateways.

Edit: I advise you not to use 3DES and MD5 in the proposal, they are considered broken

NetworkVA
NetworkVAAuthor
New Member
August 31, 2017

I tried removing the timers, however I was able to get the debugs from the Cisco Side and they show the following: VAS-GATEWAY#debug crypto ipsec Crypto IPSEC debugging is on VAS-GATEWAY# *Aug 31 13:12:03.047: IPSEC(validate_proposal_request): proposal part #1 *Aug 31 13:12:03.047: IPSEC(validate_proposal_request): proposal part #1,   (key eng. msg.) INBOUND local= 1.1.1.2:0, remote= 1.1.1.1:0,     local_proxy= 192.11.11.0/255.255.255.0/0/0 (type=4),     remote_proxy= 192.168.19.0/255.255.255.0/0/0 (type=4),     protocol= ESP, transform= NONE  (Tunnel-UDP),     lifedur= 0s and 0kb,     spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0 *Aug 31 13:12:03.051: Crypto mapdb : proxy_match         src addr     : 192.11.11.0         dst addr     : 192.168.19.0         protocol     : 0         src port     : 0         dst port     : 0 *Aug 31 13:12:03.051: map_db_check_isakmp_profile profile did not match *Aug 31 13:12:03.051: Crypto mapdb : proxy_match         src addr     : 192.11.11.0         dst addr     : 192.168.19.0         protocol     : 0         src port     : 0         dst port     : 0 *Aug 31 13:12:03.051: map_db_check_isakmp_profile profile did not match *Aug 31 13:12:03.051: map_db_find_best did not find matching map *Aug 31 13:12:03.051: IPSEC(ipsec_process_proposal): proxy identities not supported

 

I am thinking that is has to do with the subnets not matching up somehow.

oheigl
oheigl
New Member
August 31, 2017

Okay at least good to know that only phase 2 is failing. I just googled an example and in the cookbook from Fortinet the preview of the CLI lists the subnetmask normal (255.255.255.0 and not 0.0.0.255)

http://cookbook.fortinet.com/wp-content/uploads/FortiGate/ipsec-fgt-cisco/C8.png

Maybe worth to try and swap them around :)

 

Also if the remote partner is a good guy you could ask him to implement it via VTI, then you don't have to worry about the selectors ever again. (http://kb.fortinet.com/kb/documentLink.do?externalID=FD34846 ignore the OSPF in this article if you don't need it)

Terms & ConditionsAccessibility statement