Troubleshooting Tip: OSPF adjency down on IPSec interface due to Hello timer expire only 1-way state

[bkarl]

Description	This article describes a way to troubleshoot and fix the OSPF adjacency issue when it can not be established. The issue could be related to other causes but here the article will focus on one of them.
Scope	FortiOS OSPF over IPSec.
Solution	Run the following commands: get router info routing-table all get sys arp get router info routing-table ospf get router info ospf status diag sniffer packet any “proto 89” 6 0 l diag sniffer packet any “ host 224.0.0.5” 6 0 l get router info ospf neighbor get router info ospf interface diagnose ip router ospf all enable / disable diagnose ip router ospf level info diagnose debug enable To confirm the Hello time expire issue only 1-way state: FG_LAB_A (root) # get router info ospf neighbor OSPF process 0, VRF 0: Neighbor ID Pri State Dead Time Address Interface 192.168.168.28 1 Init/ - 00:00:34 10.114.133.233 VPN_A(tun-id:192.168.168.28) 172.31.14.68 255 Full/DR 00:00:37 172.31.14.68 wan1 172.31.14.69 1 Full/DROther 00:00:31 172.31.14.69 wan1 FG01-Talca_la_Florid~143 (root) # The OSPF debug shows 'Hello timer expire' and only 1-way state. OSPF: IFSM[VPN_A:10.114.133.234]: Hello timer expire OSPF: SEND[Hello]: To 224.0.0.5 via VPN_A:10.114.133.234, length 48 OSPF: RECV[Hello]: From 192.168.168.28 via VPN_A:10.114.133.234 (10.114.133.233 -> 224.0.0.5) OSPF: NFSM[VPN_A:10.114.133.234-192.168.168.28]: Init (HelloReceived) OSPF: NFSM[VPN_A:10.114.133.234-192.168.168.28]: nfsm_ignore called OSPF: NFSM[VPN_A:10.114.133.234-192.168.168.28]: Init (1-WayReceived) OSPF: IFSM[VPN_A:10.114.133.234]: Hello timer expire OSPF: SEND[Hello]: To 224.0.0.5 via VPN_A:10.114.133.234, length 48 OSPF: LSA [-: Type5:10.114.133.233:(self)]: Flooding via interface [VPN_A:10.114.133.234] OSPF: IFSM[VPN_A:10.114.133.2349010786]: Hello timer expire OSPF: SEND[Hello]: To 224.0.0.5 via VPN_A:10.114.133.234, length 48 OSPF: LSA [-: Type5:10.114.133.233:(self)]: Flooding via interface [VPN_A:10.114.133.234] OSPF: RECV[Hello]: From 192.168.168.28 via VPN_A:10.114.133.234 (10.114.133.233 -> 224.0.0.5) OSPF: NFSM[VPN_A:10.114.133.234-192.168.168.28]: Init (HelloReceived) OSPF: NFSM[VPN_A:10.114.133.234-192.168.168.28]: nfsm_ignore called OSPF: NFSM[VPN_A:10.114.133.234-192.168.168.28]: Init (1-WayReceived) Type the following commands: config system global     set check-protocol-header strict end Read the following article to understand this command: Technical Tip: Protocol header checking After that, perform a reboot to make the changes take effect. If the issue happens again, run the following CLI commands on FortiGate affected: SSH 1: get system status diagnose npu np6xlite register 0 diagnose npu np6xlite dce 0 diagnose npu np6xlite anomaly-drop 0 diagnose npu np6xlite session-stats 0 diagnose npu np6xlite sse-stats 0 diagnose vpn ike gateway list diagnose vpn tunnel list diagnose vpn ipsec status  fnsysctl cat /proc/net/np6xlite_0/ipsec-perf fnsysctl cat /proc/net/np6xlite_0/ipsec-log SSH 2: diag sniffer packet any “proto 89” 6 0 l Then submit a ticket with Fortinet TAC and share the information collected.