04-10-2024 09:37 AM
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
04-10-2024 09:54 AM
In vpn topolgy
Go to advanced
Then go to IKE
Select option of identity sent to peer
MHM
04-10-2024 11:07 AM
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
04-10-2024 11:56 AM
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
04-11-2024 04:39 AM
@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.
04-11-2024 04:47 AM - edited 04-11-2024 05:01 AM
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
04-11-2024 04:58 AM
@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.
04-26-2024 03:10 PM
any update for this case ?
MHM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide