- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can't establish IPSec VPN from Fortigate to Palo Alto
The Palo Alto is a VM-300 deployed in AWS running software version 8.1.23. It is behind a NAT, but is configured to present the AWS Elastic IP (public IP) as the identifier. The Fortigate is a 600D running 6.0.4, deployed on-prem.
Attempting IKEv2, I see these messages from the Palo Alto:
IKEv2 IKE SA negotiation is started as responder, non-rekey. Initiated SA: 10.20.30.37[500]-203.0.113.123[500] SPI:e4a92c5d6f68e7eb:2a5bbbbba383590d.
ignoring unauthenticated notify payload (16430)
My initial thought was an IKEv2 ID or NAT-T mismatch, so just for giggles, I set both sides for IKEv1 with NAT-T disabled and also "dumbed down" the proposals to only include AES128/SHA-1/Group2 on both ends. The error from the Palo Alto then switches to this:
IKE phase-1 negotiation is started as responder, main mode. Initiated SA: 10.20.30.37[500]-203.0.113.123[500] cookie:ac6fbea33f3808f1:42baa6f64bd23c89.
IKE phase-1 negotiation is failed as responder, main mode. Failed SA: 10.20.30.37[500]-203.0.113.123[500] cookie:2f7f5ae811aac034:a602a3f6b1f49f9f. Due to timeout.
IKE phase-1 SA is deleted SA: 10.20.30.37[500]-203.0.113.123[500] cookie:2f7f5ae811aac034:a602a3f6b1f49f9f.
On the Fortigate side, it just indicates a successful Phase 1 negotiation and that's it. I don't see anything related to Phase 2.
I do have a successful VPN between the same Palo Alto and a Fortigate 60-E running 7.0.12 no problem. I've been able to switch this connection between IKEv1 and v2, different encryption, etc with no issue.
- Labels:
-
FortiGate
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I suspect that there is connectivity issue. You may consider to sniff IKE traffic on both sides in order to verify whether both IPsec peers send/receive traffic.
10.20.30.37[500]-203.0.113.123[500] cookie:2f7f5ae811aac034:a602a3f6b1f49f9f. Due to timeout.
Is there particular reason why NAT-T is disabled?
Created on ‎07-18-2023 10:31 AM Edited on ‎07-18-2023 02:12 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I doubt it's connectivity. Ping works fine between the public IPs, and if I deliberately mismatch encryption settings, the Palo Alto reports error messages like this:
IKE phase-1 negotiation is failed. no suitable proposal found in peer's SA payload.
ignoring unauthenticated notify payload (NO_PROPOSAL_CHOSEN)
packet lacks expected payload
I did run all the debug commands, and looks like the "timeout" message is more a symptom of a "stuck in Phase 1" problem. Phase 1 and 2 are up on the Fortigate side, but the Palo Alto only reports a partial Phase 1 SA.
fortigate (my-vdom) # diagnose vpn ike gateway list name TEST_VPN_1
vd: my-vdom/3
name: TEST_VPN_1
version: 1
interface: vlan123 39
addr: 203.0.113.123:500 -> 198.51.100.140:500
created: 3s ago
IKE SA: created 1/1
IPsec SA: created 0/0
id/spi: 19247241 8f6c06152926e560/0000000000000000
direction: responder
status: connecting, state 3, started 3s ago
fortigate (my-vdom) # diagnose vpn tunnel list name TEST_VPN_1
list ipsec tunnel by names in vd 3
------------------------------------------------------
name=TEST_VPN_1 ver=1 serial=1d 203.0.113.123.1:0->198.51.100.140:0 dst_mtu=0
bound_if=39 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/520 options[0208]=npu frag-rfc run_state=0 accept_traffic=1 overlay_id=0
proxyid_num=1 child_num=0 refcnt=10 ilast=11 olast=11 ad=/0
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=on-demand on=0 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=TEST_VPN_1 proto=0 sa=0 ref=1 serial=2
src: 0:0.0.0.0/0.0.0.0:0
dst: 0:0.0.0.0/0.0.0.0:0
run_tally=1
The sa=0 implies traffic selector mismatch, but both sides are set for the route-based VPN (0.0.0.0/0.0.0.0)
Re: NAT-T, the connection should work with or without it. It's only disabled as a troubleshooting step. I've previously seen scenarios with Cisco and CheckPoint where one side negotiates NAT-T (udp/4500) with IKEv2 but old-school ESP (protocol 50) for IKEv1 but the other side disagrees.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Phase1 is not coming up on FortiGate side either:
status: connecting, state 3, started 3s ago
Connecting means Phase 1 is down.
https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-IPsec-VPNs-tunnels/ta-p/195955
You may consider to consider ike debug (diag deb app ike -1) on FortiGate side while trying to bring the tunnel up.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for providing more detailed information about the IKE negotiation issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I spotted version 1 under "diagnose vpn ike gateway list name TEST_VPN_1"
name: TEST_VPN_1
version: 1
isnt it a IKE v2 VPN?
