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

[NetworkVA]

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

[oheigl]

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]

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]

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)

[NetworkVA]

I found the solution. I used Option#2 from this article from Cisco: https://supportforums.cisco.com/t5/security-documents/l2l-vpn-troubleshooting-quot-ipsec-policy-inva...

Cut and paste from ARticle:

Solution:

The problem here is that the Crypto Map is referencing the ISAKMP Profile "RouterA", which means that during Phase1 the Remote Router should match the ISAKMP Profile.

A common mistake is that while defining the "match" statement in the ISAKMP Profile the POST-NAT address of the Remote Peer is used and the ISAKMP profile never gets matched as seen above. This results in Phase2 failure with error 32.

This can be fixed in two ways

Option 1:

Remove the ISAKMP profile reference from the Crypto Map, however this is probably not the best approach. The ISAKMP profiles provide great flexibility therefore Option 2 as below is a better option.

Option 2:

A. Modify the "match.." statement in the ISAKMP profile to match the address as being sent by the Remote peer. As seen from the above debugs , this address is 10.1.1.1. So the below config will fix the problem

crypto isakmp profile RouterA

   no match identity address 172.31.1.100 255.255.255.255

   match identity address 10.1.1.1 255.255.255.255

B. However the above solution can represent a problem, when the Remote Peer has a DHCP assigned address. In this case a better approach can be to configure the Remote Router to send its hostname as the ISAKMP Identity instead of "IP Address".

On Cisco devices this can be configured as

crypto isakmp identity hostname

Modify "Router C" config as below

crypto isakmp profile RouterA

   no match identity address 172.31.1.100 255.255.255.255

   match identity host RouterA

The above will fix the problem and the solution will keep working even if RouterA's WAN IP changes.

[oheigl]

Interesting, did you go with Option A or B? Because I'm not aware of setting something like a hostname in the phase 2 settings on the FortiGate. But defining the local IP of the FGT instead of the NAT address makes sense to me.

Thank you for posting the solution to your problem!

[Antonio_Milanese]

NetworkVA wrote:

*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

Umm.. no isakmp profile matched...but you have a match address.. i've two guesses

1)  since you have specified set keylife-type both on FGT i would double check that the default on cisco box it's 3600 secs since you do not have an explicit statement in your isakmp profile..

2) explicitate set local-gw in phase1 on FGT

BTW if "VTI tunnel protection" it's  supported on cisco box I would prefer that as per OHEIGL suggestion.

Regards,

Antonio