Troubleshooting FortiGate VPN Tunnel IKE Failures
In our previous post, we have already discussed the IPSec VPN Configuration in Fortigate Firewall. Here in this post we will understand how to trouble shoot the FortiGate VPN tunnel IKE failures.
We are using below topology to troubleshoot the FortiGate VPN IPSec tunnel issues
- Peer A -> 27.67.38
- Peer B -> 83.200.6
- LAN A -> 10.10.150.1/24
- LAN B -> 68.0.1/24
- User A -> 10.150.75/24
- User B -> 168.0.33/24
You can see in the image above that the setup is very simple. Two firewalls are connected over IPSec VPN which means PC A can communicate to PC B
We have both firewalls Peer A and Peer B, both firewalls are using FortiGate firewalls side by side
# get vpn ipsec tunnel summary
# diagnose vpn ike gateway list name to <ip address>
# diagnose vpn ike log-filter dst-addr4 <ip-address>
# diagnose debug application ike -1
# diagnose debug enable
Now the current situation is that both the FortiGate VPN of Site A and Site B are down and when we try to establish the traffic and send traffic over VPN tunnel which should bring the tunnel up.
>ping 192.168.0.33 -t
You need to ping the VPN from one source to another source which will initiate traffic from one VPN
to another VPN and bring the VPN up.
Troubleshooting FortiGate VPN CASE 1: Issue with Pre-shared Key
Now we have changed some configuration settings in firewall which will manually bring down the VPN IPSec site.
And will troubleshoot the issue to identify the root cause.
We will perform debug through cli to check the issue. And run debug IKE to capture the packets.
- diagnose vpn ike log-filter destination <peer gateway IP>
- diagnose debug application ike -1
Now capture the logs from cli and run below command to stop the packet capture
- diagnose debug reset
Now we can see the pre-shared key is mismatched.
Troubleshooting FortiGate VPN CASE 2: Issue with Negotiation Algorithms
Now take another scenario. Again we have changed and take the debug again to see the root cause of the issue.
The error which we have got that Negotiations mismatch error further we need to determine why we are getting negotiation error here
- diagnose vpn ike log-filter destination <peer gateway IP>
- diagnose debug application ike -1
Now capture the logs from cli and run below command to stop the packet capture
- diagnose debug reset
If we search out in debug logs we can see that there is common proposal from Firewall B with the settings.
Crypto hash value is sha-265
Here our work is to compare the configuration with firewall B like encryption DES and authentication SHA methods. When we checked the proposals and found that the authentication methods are using sha-256 so the firewall has to match the same proposals settings on the peer firewall side.
We have made the changes in Firewall A and after that VPN starts showing up.
CASE 3: Issue with Negotiation Algorithms
In Case 3 again we have done another change in configuration of the firewall IPSec VPN settings. Now apply debug on the firewall. It looks very similar to the case 2 vpn issues however we need to see the 2 important differences here.
- IPSec is a error which indicates error in VPN IPSec phase II
- mismatch error logs in the phase II proposals
Here, we are getting ISAKMP errors,
Similarly check logs in Firewall A where we have found that the Firewall A is sending the negotiation to firewall B.
Here we are not seeing proposals that are not listed because we are not trying to match them with the remote peer. Furthermore we can see error statement in debug logs
- IPSEC SA error (which means issue with Phase II)
When we scroll the debug logs little up in the cli and can found that the log stream is indicating about Phase II by issuing a statement “matched phase2”.
Whereas we got the message that means firewall being notifying that there is no Proposal chosen which means firewall B not able to find a match for proposal in Phase II negotiation. All analysis indicates the problem of the VPN.
To fix the issue we need to match the configuration of IPSec Phase 2 proposal in Firewall B.
After enabling the configuration will fix the issue. We will be able to get access to the VPN tunnel for phase II.
Continue Reading:
Partial Redundant Route Based VPN FortiGate