Troubleshooting IPsec VPN Website-to-Website connections on a FortiGate firewall might be difficult because of the advanced nature of VPN connections. Right here’s a structured strategy to diagnose and resolve frequent IPsec VPN issues between two websites: “Headquarter” and “Branch”.
Topology
Step 1: Confirm the VPN Configuration
Examine Section 1 and Section 2 Settings
- Be sure that each phases of the VPN configuration match on each the FortiGate machine and the peer or endpoint. Key parameters to verify embody:
- WAN interface related to IPSec tunnel
- IKE model (IKEv1 or IKEv2) (IKEv1 has two modes: Foremost and Aggressive)
- Distant gateway
- Pre-shared key
- Encryption algorithms
- Hash algorithms
- Diffie-Hellman teams
- Section 2 selectors
Section 1 and a couple of Configuration on “Headquarter”
Section 1 and a couple of Configuration on “Branch”
Guarantee Static Routes Are Accurately Configured
Notice: The command #set machine "Headquater" refers back to the IPSec tunnel interface.
Evaluation Firewall Insurance policies Used for IPsec
- Confirm that the insurance policies, Inbound and Outbound are appropriately configured to permit visitors from and to the VPN.
- Examine NAT configuration, as improper NAT guidelines can intervene with VPN visitors. Be sure that NAT traversal is configured if required.
Step 2: Affirm Safety Associations (SAs)
- Examine SAs: Use the CLI command
diag vpn ike gatewayto verify the standing of IKE SAs anddiag vpn tunnel listingto view the IPsec SAs. These instructions will point out if the tunnels are up and supply data on their present stage. - Section 1 checks
# diagnose vpn ike gateway listing title
The necessary subject from this specific command is standing. The standing subject has a discrete output that may be both related or established.
- Established means Section 1 is up and operating.
- Connecting means Section 1 is down
If the standing of Section 1 is in a longtime state, then concentrate on Section 2.
#diagnose vpn tunnel listing title
The necessary subject from the actual output is the ‘sa’. SA can have three values:
- sa=0 signifies there’s a mismatch between selectors or no visitors is being initiated.
- sa=1 signifies IPsec SA is matching and there may be visitors between the selectors.
- sa=2 is just seen throughout IPsec SA rekey
- Search for mismatches: Any mismatch in SAs between your FortiGate and the peer may cause the tunnel to fail.
- As a way to establish errors, run IKE debugging as talked about in Step 3.
Step 2: Examine Community Connectivity
If Section 1 just isn’t established, conduct additional diagnostics to find out the trigger. Confirm bidirectional connectivity between the VPN gateways is operational.
Validate Connectivity
- Guarantee that there’s community connectivity between the VPN gateways. This may be checked utilizing instruments like ping or traceroute.
# execute ping
# execute traceroute
Notice: You would presumably must have a supply ip to ping/traceroute, add
#execute ping-options supply previous to performing ping and
#execute traceroute-options supply previous to traceroute
- Examine routes to make sure that the right routes are in place on each VPN gadgets to route visitors by the VPN tunnel.
- Affirm that IKE visitors for port 500 or 4500 just isn’t blocked someplace alongside the trail, utilizing a packet sniffer.
Capturing IKE Packets
When NAT just isn’t used:
# diag sniffer packet "host and udp port 500" 6 0 l
When NAT is used (with NAT traversal enabled below phase1):
# diagnose sniffer packet any 'host and udp port 500 or udp port 4500' 4 0 l
6: Print header and knowledge from Ethernet of packets (if accessible) with the interface title. (I often choose to make use of 4 – print header of packets with interface title)0: Limitless variety of packets shall be captured.l: Absolute LOCAL time,yyyy-mm-dd hh:mm:ss.ms.
Step 3: Study IPSec and Debug Logs
Use Log Messages
- FortiGate offers detailed logs that may assist establish which a part of the VPN connection is failing. Examine the occasion log for any error messages associated to IPsec.
Allow Detailed Debug Logs
- If logs are usually not offering sufficient data, you may allow detailed debugging for IPsec processes. Use the next CLI instructions:
#diagnose vpn ike log-filter clear
#diagnose vpn ike log-filter dst-addr4
#diagnose debug utility ike -1
#diagnose debug console timestamp allow
#diagnose debug allow
Notice: Ranging from FortiOS v7.4.1, the command diagnose vpn ike log-filter src-addr4 has been modified to diagnose vpn ike log filter loc-addr4.
Examine Packet Movement
#diagnose debug circulation filter addr
#diagnose debug circulation filter proto 17
#diagnose debug circulation present function-name enable
#diagnose debug allow
#diagnose debug console timestamp allow
#diagnose debug circulation hint begin 99
Notice: In command #diagnose debug circulation filter proto 17
- UDP – 17
- TCP – 6
- ICMP – 1
Bear in mind to show off debugging after you’re finished to keep away from filling up the log storage.
#diagnose debug disable
To reset all filters to the defaults:
#diagnose debug reset
Step 4: Further Checks
- Peer IP adjustments: If the IP deal with of the VPN peer has modified, the tunnel is not going to be established.
-
MTU Points: Examine and alter MTU settings on VPN interfaces to forestall fragmentation points that would have an effect on VPN efficiency.
-
Interface errors/drops:
#fnsysctl ifconfig or
Step 5: Seek the advice of FortiGate Documentation
- FortiGate documentation: For extra particular error codes or messages, consult with the FortiGate documentation or data base articles that present options tailor-made to specific points.
Conclusion
Troubleshooting IPsec VPNs entails a cautious strategy of elimination, checking configurations, logs, and community settings. By systematically working by these steps, you may establish and resolve the problems affecting your VPN connection.