S2S VPN Cisco FTD (Managed by FMC) <=> Fortigate

[jamesupcott1]

Hi All

I have a S2S VPN connected at phase 1, however doesn't successfully negotiate Phase 2. The issue I have is that my Cisco FTD sits behind a NAT device. I have configured NAT-T.

My configuration on my FTD has the local peer configured with the private IP of the interface (Which is then NATed on my edge router), and the remote side as the public IP address of my Fortigate.

The issue I have is that the Fortigate is configured with the remote peer (Cisco FTD) as the public IP address, but from the Crypto Map point of view, this doesn't mirror the configuration that's on Cisco FTD (FMC) so refuses to establish Phase 2 successfully. For info, on Phase 1 I can see the Fortigate receiving the Private IP address as the Peer ID for the Cisco FTD.

I need a way to manipulate the Peer ID sent from Cisco FTD (Managed by FMC) to the Fortigate, so instead of displaying as the private IP, it mirrors the Fortigate configuration, and Peer ID information it's expecting to receive.

If there is a better solution to effectively ensure the Crypto Maps match then I'm happy with an alternate approach.

Kind Regards

James

[MHM Cisco World]

In vpn topolgy 

Go to advanced 

Then go to  IKE 

Select option of identity sent to peer 

MHM

[jamesupcott1]

Thanks for your reply. I have been on this option and it gives me the option for "IP Address", which will be the interface IP, which I don't want. And the other two options are FQDN & DN, which I wanted to avoid having to use if I can manipulate the IP address.

Is there a way to use the method you mention with a manually entered IP address rather than it using the interface IP by default?

Kind Regards

[MHM Cisco World]

Sorry' I know only this way.

You can use fqdn as ID even if you use PSK not cert. Auth.

Just make fqdn modify the ID to be fqdn instead of IP.

MHM

[tvotna]

@jamesupcott1, if this is IKEv1, the Peer ID is not that important, since your PSK is always tied to the public peer IP address. If Fortigate cross-checks received Peer ID with the configured peer IP address, there should be an option on it to disable this check. Note that NAT scenario is very common and I don't believe Fortigate software doesn't have an option to disable this check.

If this is IKEv2, things are different, because PSK is always tied to the Peer ID, instead of the public peer IP address (because in IKEv2 peer identity is available early during negotiation process or, in other words, IKEv1 "hidden identity" concept no longer applies). In this case Fortigate must be configured with PSK linked to the Peer ID and public IP is not important.

Anyway, if Phase 1 is successful, but Phase 2 fails, it might be that something else happens which prevents Phase 2 to come up. In IKEv1 IDi is sent in message #5, i.e. before Phase 2.

[MHM Cisco World]

If you use fqdn and same issue 

share form ftd side this let me look why ID reject 

Debug crypto ipsec 127 <- ikev1

Debug crypto ikev2 platform 127 <- for ikev2 

I think there is mismatch in phaseII SA' but let me check it

MHM

[tvotna]

@MHM Cisco World Do you think that Fortigate has same debug commands as ASA/FTD? Notice that it is FTD which is behind NAT and it was reported that connection fails on Fortigate side because of this.

[MHM Cisco World]

any update for this case ?

MHM