Description
This article describes steps to aid in troubleshooting VPN connectivity between two FortiGates.
In this scenario the VPN tunnel phase1 and phase2 are down between a site-to-site VPN between two FortiGates, a 'could not send IKE Packet' message is observed when running following commands:
diagnose vpn ike log-filter dst-addr4 10.5.25.62
diagnose debug application ike -1
diagnose debug enable
For v7.4.0 and above, there is a slight change in command as below:
diagnose vpn ike log filter rem-addr4 10.5.25.62
diagnose debug application ike -1
diagnose debug enable
ike 0:vpn:vpn: IPsec SA connect 4 10.40.51.195->10.5.25.62:500 negotiating
ike 0:vpn:53: cookie 2ae2ae5896ea5d2c/1e7553f5c32607ee:d6d107b8
ike 0:vpn:53:vpn:23: initiator selectors 0 0:0.0.0.0/0.0.0.0:0:0->0:0.0.0.0/0.0.0.0:0:0
ike 0:vpn:53: enc 2AE2AE5896EA5D2C1E7553F5C32607EE08102001D6D107B8000002240100002459E2867B3319F9D108E3FEABCF240FE46929EF771AEA9CEC5F0CBAFED5BDDFEB0A0000EC0000000100000001000000E001030407A9A8586303000020010C0000800100018002A8C08004000180060080800500028003000503000020020C0000800100018
ike 0:vpn:53: out 2AE2AE5896EA5D2C1E7553F5C32607EE08102001D6D107B80000022C26C6330BE556F5AD2A7572C7BD125FA424CC9CD1A11B3761AD613BD4848582C9F4AB9689DE373A88A7D218FD133E4A4ACE90DDE0BFB16A31DDA0CA105B3BEE2F8C073439B5D0CDEDB37628AB10FD83568947D09E611E07602903078F44AB65385DEC430E47B7F7FFF340A6A3C28C4F6622F0234CCDEEC72849A14D2BFFB2F0DD2078E66CEE0AA792F0988F739722318
ike 0:vpn:53: could not send IKE Packet(quick_i1send):10.40.51.195:500->10.5.25.62:500, len=556: error 101:Network is unreachable
Scope
FortiGate.
Solution
'could not send IKE Packet' message states that there is no active static route from local gateway interface to remote gateway IP.
Scenario: IPsec site-to-site VPN between FortiGate A to FortiGate B.
On FortiGate A configured with a backup WAN interface as a local interface to connect the remote gateway:
config vpn ipsec phase1-interfaced
edit "vpn"
set interface "wan2"
set peertype any
set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1
set remote-gw 10.5.25.62
set psksecret ENC aVqCYg+r5OvgOrNLYqpfMYDdLq7fJig8+PNBuw52nSpdyni9L3Z758eER059TKlppo/oZUOlpzOl9pOx0gOcvv+/2EVSGDZR9ClxVkS5MUWY02bii+V+h+tlYEZvGViMsBGDlC961iYtfpNFl2dL9yCLJTdcKH1MiBfJb65GTwt/H82eXwXPD8U0iyiTod7IMzUd+g==
next
end
Current routing table on the FortiGate A is:
get router info routing-table details 10.5.25.62
Routing table for VRF=0
Routing entry for 0.0.0.0/0
Known via 'static', distance 10, metric 0, bes:
* 10.40.31.254, via wan1 <- wan1 is the active route to reach the remote gateway with lesser distance.
Routing entry for 0.0.0.0/0
Known via "static", distance 15, metric 0
10.40.63.254, via wan2
The solution to avoid such a situation occurring is to keep the backup wan interface (wan2) distance as same as wan1 i.e 10 with higher priority.
config router static
set gateway 10.40.63.254
set priority 10
set distance 10
set device wan2
end
get router info routing-table details 10.5.25.62
Routing table for VRF=0
Routing entry for 0.0.0.0/0
Known via "static", distance 10, metric 0, best
* 10.40.31.254, via wan1
* 10.40.63.254, via wan2
