Ipsec phase 1 error

SITE TO SITE IPSEC VPN PHASE-1 AND PHASE-2 TROUBLESHOOTING STEPS , NEGOTIATIONS STATES AND MESSAGES MM_WAIT_MSG

(Image Source – www.Techmusa.com)

Network Troubleshooting is an art and site to site vpn Troubleshooting is one of my favorite network job.I believe other networking folks like the same. The first and most important step of troubleshooting is diagnosing the issue, isolate the exact issue without wasting time.

In this article i wanted to describe the steps of Troubleshooting a site-to-site VPN tunnel, most of vpn appliances provide the Plenty of debugging information for engineer to diagnose the issue.

I love to work on CLI (command line) and cisco Firewall is my favorite and have successfully created vpn tunnels including Cisco ASA, SonicWALL, Cyberoam, Checkpoint, Palo-Alto and lots more. As a network engineer, it doesn’t matter what vpn device you are using at each end of the vpn site. While creating vpn tunnels, we generally encounter common issue and as a set of rules’, there are basically few checks that you need to validate for when a tunnel fails to establish.

There are Four most common issue we generally face while setting up vpn tunnel.

• Phase 1 (ISAKMP) security associations fail
• Phase 2 (IPsec) security associations fail
• VPN Tunnel is established, but not traffic passing through
• Intermittent vpn flapping and disconnection

Most of time,  the remote end tunnel may be configured by a different engineer, so ensure that Phase-1 and Phase-2 configuration should be identical of both side of the tunnel. It would be helpful if we can use a common vpn template and exchange the Phase-1 and Phase-2  SA (security associations) information between both parties before setting up the vpn tunnel.

Phase 1 (ISAKMP) security associations fail

The first step to take when Phase-1 of the tunnel not comes up. Make sure your encryption setting, authentication, hashes, and lifetime etc. should be same for both ends of the tunnel for the phase 1 proposal.

Here’s a quick checklist of phase-1 (ISAKMP)

• ISAKMP parameters match exactly.
• Pre-shared-keys match exactly.
• External route to the peer address or Peer IP should be reachable/ping from your Firewall.
• Enable ISAKMP on the outside interfaces.
• ESP traffic permitted through the outside interface
• UDP port 500 open on the outside ACL
• Some situations UDP port 4500 need to open for the outside.

IPsec VPN Messages Type  #MM_WAIT_MSG

---

ISAKMP (IKE Phase 1) Negotiations States and Messages MM_WAIT_MSG

MM_WAIT_MSG2 – Initiator sent encryption, hashes and DH ( Diffie–Hellman) to responder and Awaiting initial reply from other end gateway. If Initiator stuck at MM_WAIT_MSG2 means the remote end is not responding to Initiator. This could be happening due to the following reason.

• Routing issue at remote end
• Remote end does not have configured ISAKMP enabled on the outside.
• remote gateway ip is incorrect
• Firewall is blocking connectivity somewhere between the two
• Firewall blocking ISAKMP (usually UDP port 500)
• Remote end peer is down

MM_WAIT_MSG3 – Initiator Received back its IKE policy to the Receiver. Initiator sends encryption, hash, DH and IKE policy details to create initial contact. Initiator will wait at MM_WAIT_MSG2 until it hears back from Receiver. Tunnel stuck at MM_WAIT_MSG3 due to the following reason.

• Mismatch in device vendors
• Firewall in the way
• ASA version mismatch
• No return route to the initiating device

MM_WAIT_MSG4 – Now the Initiator has received the IKE policy and sends the Pre-Shared-Key to Receiver. Now Initiator will stay at MM_WAIT_MSG4 until it gets a Pre-Shared-Key back from Receiver. If the receiver is does not have configured tunnel group or Pre-Shared-Key the initiator will stay at MM_WAIT_MSG4.
There are following reason that tunnel stuck at MM_WAIT_MSG4

• Missing a tunnel group
• Pre-Shared-Key mismatched at Receiver end.

MM_WAIT_MSG5 – Initiator Received its Pre-Shared-Key hash from Receiver. If receiver has a tunnel group and PSK configured for the initiators peer address, it sends its PSK hash to the initiator. If PSKs don’t match, receiver will stay at MM_WAIT_MSG5.There are following reason that tunnel stuck at MM_WAIT_MSG5

• Initiator sees the Pre-Shared-Key do not match
• NAT-T on and should be off

MM_WAIT_MSG6 – Initiator see if Pre-Shared-Key hashes match. If Pre-Shared-Key match, Initiator state becomes MM_ACTIVE and acknowledge to receiver. If Pre-Shared-Key does not match, initiator stays at MM_WAIT_MSG6. There are following reason that tunnel stuck at MM_WAIT_MSG6

• Pre-Shared-Key don’t match
• NAT-T on and should be off

Note -:   if the state intermediately goes to MM_WAIT_MSG6 and tunnel gets rest that means phase 1 completed but phase 2 getting fail to establish the IPsec connection. Check IPSEC phase 2 settings matches of both the end of the tunnel.

AM_ACTIVE –   Receiver received MM_ACTIVE acknowledge from Initiator and it becomes MM_ACTIVE.ISAKMP SA negotiations are now completed and Phase 1 has successfully completed.

Phase 2 (IPsec) security associations fail

Once the Phase 1 negotiations have established and you are falling into IPsec phase 2. There are a few different set of things need to be checked.

• Check the phase 2 proposal encryption algorithm, authentication algorithm or hash, and lifetime are the same on both sides.
• Check VPN Encryption Domain (Local and remote subnet) should be identical.
• Check correct ACL should binding with Crypto Map
• Check Firewall Inside local route to reach inside hosted network/servers
• Make sure remote subnet should not overlap with your local Lan
  Check NAT Exemption.
• Check the PFS (perfect forward secrecy) if you are using.
• Make sure the tunnel is bound to the public facing interface (crypto map outside_map interface outside)

After the above check and validation, Now If you have both phase 1 and phase 2 successful established and vpn tunnel is reported as up. Ensure traffic is passing through the vpn tunnel. Initiates some traffic (ICMP Traffic ) from inside the host or run packet tracer from firewall to originate traffic to bring the phase-2 up and see the Packet encap and Packet decap happing.

VPN Tunnel is established, but  traffic not passing through

If the traffic not passing thru the vpn tunnel or packet  #pkts encaps  and  #pkts decaps  not happing as expected. These numbers tell us how many packets have traversed the IPSec tunnel and verifies that we are receiving traffic back from the remote end of the VPN tunnel. There is couple of  things that you need to check.

• Check firewall policies and routing.
• Run packet tracker from Firewall and check vpn traffic flow.
• Check Firewall Inside local route to reach inside hosted network/servers
• Make sure remote subnet should not overlap with your local Lan
• Make sure new vpn policy should not overlap with existing policy.

vpn-Firewall# sh crypto ipsec sa peer 90.1.1.1
peer address: 90.1.1.1
    Crypto map tag: Outside_Map, seq num: 90, local addr: 200.100.0.1

      access-list Test_vpn extended permit ip  172.16.10.0/24 192.168.0.0/24
      local ident (addr/mask/prot/port): (172.16.10.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (192.168.10.0/255.255.255.0/0/0)
      current_peer: 90.1.1.1

      #pkts encaps: 294486, #pkts encrypt: 294485, #pkts digest: 294485
      #pkts decaps: 306851, #pkts decrypt: 306851, #pkts verify: 306851
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 294486, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 3416

 Verify  #pkts encaps  and  #pkts decaps  

All of the above steps should resolve vpn tunnel issues that you are experiencing. If the vpn tunnel still not establish and traffic not passing , We recommend to try a different set of encryption settings. There may be something strange incompatibilities issue encounters with different vendor devices. Also check the latest release notes for firmware version of your VPN appliance. (If you have already upgraded any firmware to the latest version). Finally, check the knowledgebase and get vendor inputs for your specific appliance as it may provide further suggestions/assistance.

Intermittent vpn flapping and discontinuation

Sometimes it is crazy that vpn tunnel state is going up and down constantly and users getting frustrated due to connection drop with the servers.

There are couple of reasons that vpn tunnel is getting dropped and it start all of sudden even you have not made any change in the vpn tunnel.

In this case, you need to check following things listed as below -:

• Make sure there is no change done at remote end which you are not being notified.
• Re-validate the encryption domain (Local and Remote subnet in the vpn) both end should have identical match and exact CIDR.
• Re-check the Phase-1 and Phase-2 Lifetime settings at both ends of the tunnel (Phase-1 life time should be higher than Phase-2)
• Check the DPD (Dead Peer Detection) setting (If you are using different vendor firewall DPD should be disabled.)
• Check configuration in detail and make sure Peer IP should not be NATTED.
• Make sure internet link should be stable and there is no intermittent drop in the connectivity.

Phase 1 (IKEv1) and Phase 2 (IPsec) Configuration Steps-:

Phase 1 (IKEv1) Configuration

Complete the below mentioned steps for the Phase 1 configuration:

In this example we are using CLI mode in order to enable IKEv1 on the outside interface:

crypto ikev1 enable outside

Create an IKEv1 Phase-1 policy that defines the authentication , encryption , hashing, DH group(Diffie-Hellman) and lifetime

crypto ikev1 policy 1
  authentication pre-share
  encryption aes
  hash sha
  group 2
  lifetime 86400

Phase 2 (IPsec) Configuration

Complete these steps for the Phase 2 configuration:

Create an access list which defines the traffic to be encrypted and through the tunnel. In this example, the source traffic of interesting subnet would be from the 172.16.100.0/24 subnet to the 192.168.10.0/24. It can contain multiple entries if there are multiple subnets involved between the sites.

object network Obj_172.16.100.0
 subnet 172.16.100.0 255.255.255.0

object network Obj_192.168.10.0
 subnet 192.168.10.0 255.255.255.0

Note -:  In ASA Versions 8.4 and later, objects or object groups can be created for the networks, subnets, host IP addresses.Here we have Created two objects group that have the local and remote subnets and use them for both the crypto Access Control List (ACL) and the NAT statements.

access-list test_vpn extended permit ip object Obj_172.16.100.0 object Obj_192.168.10.0

NAT Exemption Or NO NAT

nat (inside,outside) 1 source static Obj_172.16.100.0 Obj_172.16.100.0 destination static Obj_192.168.10.0 Obj_192.168.10.0 no-proxy-arp route-lookup

(Note -: Make sure that VPN traffic is not subjected to any other NAT rule.)

Configure the IKEv1 Transform Set. Same an identical Transform Set must be created on the remote end as well.

crypto ipsec ikev1 transform-set myset esp-aes esp-sha-hmac

Configure the crypto map, which contains the Following components:

• Peer IP address
• Access list
• Transform Set
• An optional Perfect Forward Secrecy (PFS) setting, which creates a new pair of Diffie-Hellman keys which used to protect the data (both sides must be PFS-enabled)

crypto map outside_map 10 match address test_vpn
crypto map outside_map 10 set peer 90.1.1.1
crypto map outside_map 10 set ikev1 transform-set myset
crypto map outside_map 10 set pfs

Create a tunnel group under the IPsec attributes and configure the peer IP address and IPSec vpn tunnel pre-shared key

tunnel-group 90.1.1.1 type ipsec-l2l
tunnel-group 90.1.1.1 ipsec-attributes
 ikev1 pre-shared-key cisco

Apply the crypto map on the outside interface:

crypto map outside_map interface outside

VPN Troubleshooting and Verification Command

VPN-Firewall# sh crypto isakmp sa | b  90.1.1.1
5   IKE Peer: 90.1.1.1
    Type    : L2L             Role    : responder
    Rekey   : no              State   : MM_ACTIVE

VPN-Firewall# sh crypto ipsec sa peer 90.1.1.1
peer address: 90.1.1.1
    Crypto map tag: Outside_Map, seq num: 90, local addr: 200.100.0.1

      access-list Test_vpn extended permit ip 172.16.10.0/24  192.168.10.0/24
      local ident (addr/mask/prot/port): (172.16.10.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (192.168.10.0/255.255.255.0/0/0)
      current_peer: 90.1.1.1

      #pkts encaps: 294486, #pkts encrypt: 294485, #pkts digest: 294485
      #pkts decaps: 306851, #pkts decrypt: 306851, #pkts verify: 306851
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 294486, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 3416

      local crypto endpt.: 200.100.0.1, remote crypto endpt.: 90.1.1.1

      path mtu 1500, ipsec overhead 58, media mtu 1500
      current outbound spi: A12ACD06
      current inbound spi : ADA4ACB9

VPN-Firewall# sh vpn-sessiondb detail l2l | b 90.1.1.1
Connection   : 90.1.1.1
Index        : 48142                  IP Addr      : 90.1.1.1
Protocol     : IKE IPsec
Encryption   : 3DES                   Hashing      : SHA1
Bytes Tx     : 82449639               Bytes Rx     : 262643640
Login Time   : 16:26:32 EDT Tue Jul 11 2017
Duration     : 11d 14h:16m:29s
IKE Tunnels: 1
IPsec Tunnels: 4

IKE:
  Tunnel ID    : 48142.1
  UDP Src Port : 500                    UDP Dst Port : 500
  IKE Neg Mode : Main                   Auth Mode    : preSharedKeys
  Encryption   : 3DES                   Hashing      : SHA1
  Rekey Int (T): 86400 Seconds          Rekey Left(T): 39341 Seconds
  D/H Group    : 2
  Filter Name  :

IPsec:
  Tunnel ID    : 48142.2
  Local Addr   : 172.16.10.0/255.255.255.255/0/0
  Remote Addr  : 192.168.10.0/255.255.255.255/0/0
  Encryption   : 3DES                   Hashing      : SHA1
  Encapsulation: Tunnel
  Rekey Int (T): 28800 Seconds          Rekey Left(T): 6219 Seconds
  Rekey Int (D): 4608000 K-Bytes        Rekey Left(D): 4606645 K-Bytes
  Idle Time Out: 30 Minutes             Idle TO Left : 29 Minutes
  Bytes Tx     : 20200839               Bytes Rx     : 65481714
  Pkts Tx      : 294551                 Pkts Rx      : 306920

Related

Issue

Phase 1 Negotiation between IPSec Peer and PAN is being identified as «LAND attack». Receiving the following error entry in the Ikemgr.log:

IKE phase-1 negotiation is failed as initiator, main mode. Failed SA: 216.204.241.93[500]-216.203.80.108[500] message id:0x43D098BB. Due to negotiation timeout.

Details

If the Proxy IDs have been checked for mismatch, try the following:

1. Configure a filter source peer WAN IP to destination Palo Alto Networks WAN IP
   > debug dataplane packet-diag set filter match source x.x.x.x destination y.y.y.y
2. Turn on the filter.
   > debug dataplane packet-diag set filter on
3. Initiate a ping in the reverse path. On a remote machine behind the VPN Peer, ping across the VPN tunnel to a host behind the PAN Firewall.
   From a host on the remote peer network try to ping a host on the local network behind the PAN Firewall (w.w.w.w)
   c:> ping w.w.w.w

   This should cause the tunnel to be created, and initiate a new Phase1 IPSec negotiation.

4. Run the following command a couple of times:
   > show counter global filter delta yes packet-filter yes
   

Look for drops in the output. For example:

Global counters:

Elapsed time since last sampling: 1.481 seconds

name                      value  rate  severity  category  aspect    description

——————————————————————————————

session_allocated         1      0     info      session   resource  Sessions allocated

session_freed             1      0     info      session   resource  Sessions freed

flow_policy_nat_land      1      0     drop      flow      session   Session setup: source NAT IP allocation result in LAND attack

nat_dynamic_port_xlat     1      0     info      nat       resource  The total number of dynamic_ip_port NAT translate called

nat_dynamic_port_release  1      0     info      nat       resource  The total number of dynamic_ip_port NAT release called

——————————————————————————————

Total counters shown: 5

——————————————————————————————

Resolution

In this case, the ‘flow_policy_nat_land‘ global counter is showing a ‘drop’, indicating a configuration issue causing the traffic to be dropped, causing this «timeout» error.

In the order to resolve the LAND attack, see: Misconfigured Source NAT and LAND attacks

owner: vvasilasco

Troubleshooting IPsec VPNs

Renegotiation Errors

If a tunnel comes up initially, but then fails after a Phase 1 or Phase
2 expiration, try changing the following settings on both ends of the
tunnel:

• On the IPsec Phase 1 settings, disable NAT Traversal (NAT-T)
• On the IPsec Phase 1 settings, enable DPD
• On the IPsec Phase 2 settings, enter an Automatically Ping Host
  in the remote Phase 2 subnet.

Common Errors

The following examples have logs edited for brevity but significant
messages remain.

Logging for IPsec is configured at VPN > IPsec, Advanced
Settings tab. The most useful logging settings for diagnosing tunnel
issues with strongSwan on pfSense® software version 2.2.x are:

• IKE SA, IKE Child SA, and Configuration Backend on Diag
• All others on Control

Other notable behaviors:

• If there is an Aggressive/Main mode mismatch and the side set for
  Main initiates, the tunnel will still establish
• Lifetime mismatches do not cause a failure in Phase 1 or Phase 2

Normal / OK Connection

Initiator:

charon: 09[IKE] IKE_SA con2000[11] established between 192.0.2.90[192.0.2.90]...192.0.2.74[192.0.2.74]
charon: 09[IKE] CHILD_SA con2000{2} established with SPIs cf4973bf_i c1cbfdf2_o and TS 192.168.48.0/24|/0 === 10.42.42.0/24|/0

Responder:

charon: 03[IKE] IKE_SA con1000[19] established between 192.0.2.74[192.0.2.74]...192.0.2.90[192.0.2.90]
charon: 16[IKE] CHILD_SA con1000{1} established with SPIs c1cbfdf2_i cf4973bf_o and TS 10.42.42.0/24|/0 === 192.168.48.0/24|/0

Phase 1 Main / Aggressive Mismatch

Initiator (Aggressive set, responder on Main):

charon: 15[IKE] initiating Aggressive Mode IKE_SA con2000[1] to 192.0.2.74
charon: 15[IKE] received AUTHENTICATION_FAILED error notify
charon: 13[ENC] parsed INFORMATIONAL_V1 request 1215317906 [ N(AUTH_FAILED) ]
charon: 13[IKE] received AUTHENTICATION_FAILED error notify

Responder:

charon: 13[IKE] Aggressive Mode PSK disabled for security reasons
charon: 13[ENC] generating INFORMATIONAL_V1 request 2940146627 [ N(AUTH_FAILED) ]

Phase 1 Identifier Mismatch

Initiator:

charon: 10[ENC] parsed INFORMATIONAL_V1 request 4216246776 [ HASH N(AUTH_FAILED) ]
charon: 10[IKE] received AUTHENTICATION_FAILED error notify

Responder:

charon: 12[CFG] looking for pre-shared key peer configs matching 192.0.2.74...192.0.2.90[someid]
charon: 12[IKE] no peer config found
charon: 12[ENC] generating INFORMATIONAL_V1 request 4216246776 [ HASH N(AUTH_FAILED) ]

Phase 1 Pre-Shared Key Mismatch

Initiator:

charon: 09[ENC] invalid HASH_V1 payload length, decryption failed?
charon: 09[ENC] could not decrypt payloads
charon: 09[IKE] message parsing failed

Responder:

charon: 09[ENC] invalid ID_V1 payload length, decryption failed?
charon: 09[ENC] could not decrypt payloads
charon: 09[IKE] message parsing failed

Phase 1 Encryption Algorithm Mismatch

Initiator:

charon: 14[ENC] parsed INFORMATIONAL_V1 request 3851683074 [ N(NO_PROP) ]
charon: 14[IKE] received NO_PROPOSAL_CHOSEN error notify

Responder:

charon: 14[CFG] received proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
charon: 14[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
charon: 14[IKE] no proposal found
charon: 14[ENC] generating INFORMATIONAL_V1 request 3851683074 [ N(NO_PROP) ]

Phase 1 Hash Algorithm Mismatch

Initiator:

charon: 10[ENC] parsed INFORMATIONAL_V1 request 2774552374 [ N(NO_PROP) ]
charon: 10[IKE] received NO_PROPOSAL_CHOSEN error notify

Responder:

charon: 14[CFG] received proposals: IKE:AES_CBC_256/MODP_1024
charon: 14[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
charon: 14[IKE] no proposal found
charon: 14[ENC] generating INFORMATIONAL_V1 request 2774552374 [ N(NO_PROP) ]

Phase 1 DH Group Mismatch

Initiator:

charon: 11[ENC] parsed INFORMATIONAL_V1 request 316473468 [ N(NO_PROP) ]
charon: 11[IKE] received NO_PROPOSAL_CHOSEN error notify

Responder:

charon: 14[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_8192
charon: 14[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
charon: 14[IKE] no proposal found
charon: 14[ENC] generating INFORMATIONAL_V1 request 316473468 [ N(NO_PROP) ]

Phase 2 Network Mismatch

Initiator:

charon: 08[CFG] proposing traffic selectors for us:
charon: 08[CFG] 192.168.48.0/24|/0
charon: 08[CFG] proposing traffic selectors for other:
charon: 08[CFG] 10.42.43.0/24|/0
charon: 08[ENC] generating QUICK_MODE request 316948142 [ HASH SA No ID ID ]
charon: 08[NET] sending packet: from 192.0.2.90[500] to 192.0.2.74[500] (236 bytes)
charon: 08[NET] received packet: from 192.0.2.74[500] to 192.0.2.90[500] (76 bytes)
charon: 08[ENC] parsed INFORMATIONAL_V1 request 460353720 [ HASH N(INVAL_ID) ]
charon: 08[IKE] received INVALID_ID_INFORMATION error notify

Responder:

charon: 08[ENC] parsed QUICK_MODE request 2732380262 [ HASH SA No ID ID ]
charon: 08[CFG] looking for a child config for 10.42.43.0/24|/0 === 192.168.48.0/24|/0
charon: 08[CFG] proposing traffic selectors for us:
charon: 08[CFG] 10.42.42.0/24|/0
charon: 08[CFG] proposing traffic selectors for other:
charon: 08[CFG] 192.168.48.0/24|/0
charon: 08[IKE] no matching CHILD_SA config found
charon: 08[IKE] queueing INFORMATIONAL task
charon: 08[IKE] activating new tasks
charon: 08[IKE] activating INFORMATIONAL task
charon: 08[ENC] generating INFORMATIONAL_V1 request 1136605099 [ HASH N(INVAL_ID) ]

Phase 2 Encryption Algorithm Mismatch

Initiator:

charon: 14[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
charon: 14[ENC] generating QUICK_MODE request 759760112 [ HASH SA No ID ID ]
charon: 14[NET] sending packet: from 192.0.2.90[500] to 192.0.2.74[500] (188 bytes)
charon: 14[NET] received packet: from 192.0.2.74[500] to 192.0.2.90[500] (76 bytes)
charon: 14[ENC] parsed INFORMATIONAL_V1 request 1275272345 [ HASH N(NO_PROP) ]
charon: 14[IKE] received NO_PROPOSAL_CHOSEN error notify

Responder:

charon: 13[CFG] selecting proposal:
charon: 13[CFG] no acceptable ENCRYPTION_ALGORITHM found
charon: 13[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
charon: 13[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
charon: 13[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSEN
charon: 13[IKE] queueing INFORMATIONAL task
charon: 13[IKE] activating new tasks
charon: 13[IKE] activating INFORMATIONAL task
charon: 13[ENC] generating INFORMATIONAL_V1 request 1275272345 [ HASH N(NO_PROP) ]

Phase 2 Hash Algorithm Mismatch

Initiator:

charon: 10[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA2_512_256/NO_EXT_SEQ
charon: 10[ENC] generating QUICK_MODE request 2648029707 [ HASH SA No ID ID ]
charon: 10[NET] sending packet: from 192.0.2.90[500] to 192.0.2.74[500] (188 bytes)
charon: 10[NET] received packet: from 192.0.2.74[500] to 192.0.2.90[500] (76 bytes)
charon: 10[ENC] parsed INFORMATIONAL_V1 request 757918402 [ HASH N(NO_PROP) ]
charon: 10[IKE] received NO_PROPOSAL_CHOSEN error notify

Responder:

charon: 11[CFG] selecting proposal:
charon: 11[CFG] no acceptable INTEGRITY_ALGORITHM found
charon: 11[CFG] received proposals: ESP:AES_CBC_256/HMAC_SHA2_512_256/NO_EXT_SEQ
charon: 11[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
charon: 11[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSEN
charon: 11[IKE] queueing INFORMATIONAL task
charon: 11[IKE] activating new tasks
charon: 11[IKE] activating INFORMATIONAL task
charon: 11[ENC] generating INFORMATIONAL_V1 request 757918402 [ HASH N(NO_PROP) ]

Phase 2 PFS Mismatch

Initiator:

charon: 06[ENC] generating QUICK_MODE request 909980434 [ HASH SA No KE ID ID ]
charon: 06[NET] sending packet: from 192.0.2.90[500] to 192.0.2.74[500] (444 bytes)
charon: 06[NET] received packet: from 192.0.2.74[500] to 192.0.2.90[500] (76 bytes)
charon: 06[ENC] parsed INFORMATIONAL_V1 request 3861985833 [ HASH N(NO_PROP) ]
charon: 06[IKE] received NO_PROPOSAL_CHOSEN error notify

Responder:

charon: 08[CFG] selecting proposal:
charon: 08[CFG] no acceptable DIFFIE_HELLMAN_GROUP found
charon: 08[CFG] received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ
charon: 08[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ
charon: 08[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSEN
charon: 08[ENC] generating INFORMATIONAL_V1 request 3861985833 [ HASH N(NO_PROP) ]

Mismatched Identifier with NAT

In this case, strongSwan is set for a Peer Identifier of Peer IP
address, but the remote router is actually behind NAT. In this case
strongSwan expects the actual private before-NAT IP address as the
identifier.

Responder:

charon: 10[IKE] remote host is behind NAT
charon: 10[IKE] IDir '192.0.2.10' does not match to '203.0.113.245'
[...]
charon: 10[CFG] looking for pre-shared key peer configs matching 198.51.100.50...203.0.113.245[192.0.2.10]

To correct this condition, change the Peer Identifier setting to IP
Address and then enter the pre-NAT IP address, which in this example is
192.0.2.10.

Incorrect Destination Address

When multiple WAN IP addresses are available, such as with CARP VIPs or
IP Alias VIPs, an additional failure mode can occur where the connection
appears in the logs but matches bypasslan or «%any…%any». In this
case, IPsec is configured to listen to one IP address but the client is
connecting to another address. For example, an IPsec Phase 1 entry may
be configured to use the WAN IP address but clients are connecting to a
CARP VIP. In this case, the destination address in the logs will be the
VIP address and not the interface address. Confirm by checking the logs
against «ipsec statusall».

Disappearing Traffic

If IPsec traffic arrives but never appears on the IPsec interface
(enc0), check for conflicting routes/interface IP addresses. For
example, if an IPsec tunnel is configured with a remote network of
192.0.2.0/24 and there is a local OpenVPN server with a tunnel network
of 192.0.2.0/24 then the ESP traffic may arrive, strongSwan may process
the packets, but they never show up on enc0 as arriving to the OS for
delivery.

Resolve the duplicate interface/route and the traffic will begin to
flow.

IPsec Status Page Issues

If the IPsec status page prints errors such as:

Warning: Illegal string offset 'type' in /etc/inc/xmlreader.inc on line 116

That is a sign that the incomplete xmlreader XML parser is active, which
is triggered by the presence of the file /cf/conf/use_xmlreader. This
alternate parser can be faster for reading large config.xml files, but
lacks certain features necessary for other areas to function well.
Removing /cf/conf/use_xmlreader will return the system to the default
parser immediately, which will correct the display of the IPsec status
page.

IPsec Debugging

The logging options for the IPsec daemon are located under VPN > IPsec on
the Advanced Settings tab and may be adjusted live without affecting the
operation of IPsec tunnels. As mentioned above, the recommended setting for most
common debugging is to set IKE SA, IKE Child SA, and
Configuration Backend on Diag and set all others on Control.

Shrew Soft VPN Client Debugging

Open the Trace app. Stop the IKE Service, and go to File, Options.
Change the log output level to debug and click OK. Start the IKE Service
and attempt to connect.

Packet Loss with Certain Protocols

If packet loss is experienced only when using specific protocols (SMB,
RDP, etc), MSS clamping may be required to reduce the effective MTU of
the VPN. IPsec does not handle fragmented packets very well, and a
reduced MTU will ensure that the packets traversing the tunnel are all
of a size which can be transmitted whole. A good starting point would be
1300, and if that works, slowly increase the MSS until the breaking
point is located, then back off a little from there.

MSS clamping is configured under System > Advanced on the
Miscellaneous tab on pfSense software version 2.1.x and before. On
pfSense software version 2.2, it is under VPN > IPsec on the
Advanced Settings tab. Check the box to enable MSS Clamping for VPNs,
and fill in the appropriate value.

Some Hosts Work, Others Do Not

If some hosts can communicate across a VPN tunnel and others cannot, it
typically means that for some reason the packets from that client system
are not being routed to the pfSense system. This could happen for a
number of reasons, but the two most common are:

• Incorrect gateway on client system: the pfSense router needs to be
  the gateway, or the gateway must have a static route for tunnel traffic
  which forwards those packets to the pfSense router.
• Incorrect subnet mask on the client system: If the VPN subnets are
  close, say 192.168.0.x and 192.168.1.x, ensure that the subnet mask
  is 255.255.255.0 on the client systems. If one of them has an
  incorrect mask, such as 255.255.0.0, it will try to reach the remote
  systems locally and not send the packets out via the gateway.

Dropping Tunnels on ALIX/embedded

If tunnels are dropped during periods of high IPsec throughput on an
ALIX or other embedded hardware, it may be necessary to disable DPD on
the tunnel. When the CPU on an ALIX is tied up with sending IPsec
traffic, it may not take the time to respond to a DPD request on the
tunnel. As a consequence, the tunnel will fail a DPD check and be
disconnected.

Crash/Panic in NIC driver with IPsec in Backtrace

If a crash occurs and the backtrace shows signs of both the NIC driver
and IPsec in the backtrace, such as the following edited example:

Sleeping thread (tid 100066, pid 12) owns a non-sleepable lock
[...]
igb_mq_start_locked() at igb_mq_start_locked+0xe4/frame 0xfffffe001c39cda0
igb_mq_start() at igb_mq_start+0x224/frame 0xfffffe001c39ce10
ether_output() at ether_output+0x58d/frame 0xfffffe001c39ce80
[...]
ipsec4_common_input_cb() at ipsec4_common_input_cb+0x20d/frame 0xfffffe001c39d410
esp_input_cb() at esp_input_cb+0x4ce/frame 0xfffffe001c39d4a0
swcr_process() at swcr_process+0x89/frame 0xfffffe001c39d6d0
crypto_dispatch() at crypto_dispatch+0x6e/frame 0xfffffe001c39d700
esp_input() at esp_input+0x5a9/frame 0xfffffe001c39d790
ipsec_common_input() at ipsec_common_input+0x29a/frame 0xfffffe001c39d800
ipsec4_common_input() at ipsec4_common_input+0x91/frame 0xfffffe001c39d860
[...]
igb_rxeof() at igb_rxeof+0x698/frame 0xfffffe001c39dad0
igb_msix_que() at igb_msix_que+0x16d/frame 0xfffffe001c39db20

Try adding the following tunable to System > Advanced, System
Tunables tab:

net.inet.ipsec.directdispatch=0

Was does the MM_NO_STATE usually mean when having errors bringing phase 1 up?

IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
X.X.X.122  X.X.X.107    MM_NO_STATE          0 ACTIVE

Debug log:

Feb 18 09:25:36.732: IPSEC(sa_request): ,
  (key eng. msg.) OUTBOUND local= X.X.X.107:500, remote= X.X.X.122:500,
    local_proxy= LOCAL.LAN.SUBNET/255.255.255.0/256/0,
    remote_proxy= REMOTE.LAN.SUBNET/255.255.240.0/256/0,
    protocol= ESP, transform= esp-aes 256 esp-sha256-hmac  (Tunnel), 
    lifedur= 3600s and 4608000kb, 
    spi= 0x0(0), conn_id= 0, keysize= 256, flags= 0x0
Feb 18 09:25:36.732: ISAKMP:(0): SA request profile is (NULL)
Feb 18 09:25:36.732: ISAKMP: Created a peer struct for X.X.X.122, peer port 500
Feb 18 09:25:36.732: ISAKMP: New peer created peer = 0x21027558 peer_handle = 0x80000022
Feb 18 09:25:36.732: ISAKMP: Locking peer struct 0x21027558, refcount 1 for isakmp_initiator
Feb 18 09:25:36.732: ISAKMP: local port 500, remote port 500
Feb 18 09:25:36.732: ISAKMP: set new node 0 to QM_IDLE      
Feb 18 09:25:36.732: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 3D3B8698
Feb 18 09:25:36.732: ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
Feb 18 09:25:36.732: ISAKMP:(0):found peer pre-shared key matching X.X.X.122
Feb 18 09:25:36.732: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
Feb 18 09:25:36.732: ISAKMP:(0): constructed NAT-T vendor-07 ID
Feb 18 09:25:36.732: ISAKMP:(0): constructed NAT-T vendor-03 ID
Feb 18 09:25:36.732: ISAKMP:(0): constructed NAT-T vendor-02 ID
Feb 18 09:25:36.732: ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
Feb 18 09:25:36.732: ISAKMP:(0):Old State = IKE_READY  New State = IKE_I_MM1 

Feb 18 09:25:36.732: ISAKMP:(0): beginning Main Mode exchange
Feb 18 09:25:36.732: ISAKMP:(0): sending packet to X.X.X.122 my_port 500 peer_port 500 (I) MM_NO_STATE
Feb 18 09:25:36.732: ISAKMP:(0):Sending an IKE IPv4 Packet
Feb 18 09:25:46.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
Feb 18 09:25:46.732: ISAKMP (0): incrementing error counter on sa, attempt 1 of 5: retransmit phase 1
Feb 18 09:25:46.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
Feb 18 09:25:46.732: ISAKMP:(0): sending packet to X.X.X.122 my_port 500 peer_port 500 (I) MM_NO_STATE
Feb 18 09:25:46.732: ISAKMP:(0):Sending an IKE IPv4 Packet.
Feb 18 09:25:51.340: ISAKMP:(0):purging node -1205386052
Feb 18 09:25:51.340: ISAKMP:(0):purging node 359996904
Feb 18 09:25:56.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
Feb 18 09:25:56.732: ISAKMP (0): incrementing error counter on sa, attempt 2 of 5: retransmit phase 1
Feb 18 09:25:56.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
Feb 18 09:25:56.732: ISAKMP:(0): sending packet to X.X.X.122 my_port 500 peer_port 500 (I) MM_NO_STATE
Feb 18 09:25:56.732: ISAKMP:(0):Sending an IKE IPv4 Packet.
Feb 18 09:26:01.340: ISAKMP:(0):purging SA., sa=3D3A9E34, delme=3D3A9E34
Feb 18 09:26:06.732: IPSEC(key_engine): request timer fired: count = 1,
  (identity) local= X.X.X.107:0, remote= X.X.X.122:0,
    local_proxy= LOCAL.LAN.SUBNET/255.255.255.0/256/0,
    remote_proxy= REMOTE.LAN.SUBNET/255.255.240.0/256/0
Feb 18 09:26:06.732: IPSEC(sa_request): ,
  (key eng. msg.) OUTBOUND local= X.X.X.107:500, remote= X.X.X.122:500,
    local_proxy= LOCAL.LAN.SUBNET/255.255.255.0/256/0,
    remote_proxy= REMOTE.LAN.SUBNET/255.255.240.0/256/0,
    protocol= ESP, transform= esp-aes 256 esp-sha256-hmac  (Tunnel), 
    lifedur= 3600s and 4608000kb, 
    spi= 0x0(0), conn_id= 0, keysize= 256, flags= 0x0
Feb 18 09:26:06.732: ISAKMP: set new node 0 to QM_IDLE      
Feb 18 09:26:06.732: ISAKMP:(0):SA is still budding. Attached new ipsec request to it. (local X.X.X.107, remote X.X.X.122)
Feb 18 09:26:06.732: ISAKMP: Error while processing SA request: Failed to initialize SA
Feb 18 09:26:06.732: ISAKMP: Error while processing KMI message 0, error 2.
Feb 18 09:26:06.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
Feb 18 09:26:06.732: ISAKMP (0): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1
Feb 18 09:26:06.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
Feb 18 09:26:06.732: ISAKMP:(0): sending packet to X.X.X.122 my_port 500 peer_port 500 (I) MM_NO_STATE
Feb 18 09:26:06.732: ISAKMP:(0):Sending an IKE IPv4 Packet.
Feb 18 09:26:16.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
Feb 18 09:26:16.732: ISAKMP (0): incrementing error counter on sa, attempt 4 of 5: retransmit phase 1
Feb 18 09:26:16.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
Feb 18 09:26:16.732: ISAKMP:(0): sending packet to X.X.X.122 my_port 500 peer_port 500 (I) MM_NO_STATE
Feb 18 09:26:16.732: ISAKMP:(0):Sending an IKE IPv4 Packet.
Feb 18 09:26:26.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
Feb 18 09:26:26.732: ISAKMP (0): incrementing error counter on sa, attempt 5 of 5: retransmit phase 1
Feb 18 09:26:26.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
Feb 18 09:26:26.732: ISAKMP:(0): sending packet to X.X.X.122 my_port 500 peer_port 500 (I) MM_NO_STATE
Feb 18 09:26:26.732: ISAKMP:(0):Sending an IKE IPv4 Packet.
Feb 18 09:26:36.732: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
Feb 18 09:26:36.732: ISAKMP:(0):peer does not do paranoid keepalives.

Feb 18 09:26:36.732: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (I) MM_NO_STATE (peer X.X.X.122)
Feb 18 09:26:36.732: IPSEC(key_engine): request timer fired: count = 2,
  (identity) local= X.X.X.107:0, remote= X.X.X.122:0,
    local_proxy= LOCAL.LAN.SUBNET/255.255.255.0/256/0,
    remote_proxy= REMOTE.LAN.SUBNET/255.255.240.0/256/0
Feb 18 09:26:36.732: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (I) MM_NO_STATE (peer X.X.X.122) 
Feb 18 09:26:36.732: ISAKMP: Unlocking peer struct 0x21027558 for isadb_mark_sa_deleted(), count 0
Feb 18 09:26:36.732: ISAKMP: Deleting peer node by peer_reap for X.X.X.122: 21027558
Feb 18 09:26:36.732: ISAKMP:(0):deleting node 1892890669 error FALSE reason "IKE deleted"
Feb 18 09:26:36.732: ISAKMP:(0):deleting node -2013997155 error FALSE reason "IKE deleted"
Feb 18 09:26:36.732: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
Feb 18 09:26:36.732: ISAKMP:(0):Old State = IKE_I_MM1  New State = IKE_DEST_SA 

Feb 18 09:26:36.732: IPSEC(key_engine): got a queue event with 1 KMI message(s)
Feb 18 09:27:26.732: ISAKMP:(0):purging node 1892890669
Feb 18 09:27:26.732: ISAKMP:(0):purging node -2013997155
Feb 18 09:27:36.732: ISAKMP:(0):purging SA., sa=3D3B8698, delme=3D3B869

Troubleshooting

This section contains tips to help you with some common challenges of IPsec VPNs.

A VPN connection has multiple stages that can be confirmed to ensure the connection is working properly. It is easiest to see if the final stage is successful first since if it is successful the other stages will be working properly. Otherwise, you will need to work back through the stages to see where the problem is located.

When a VPN connection is properly established, traffic will flow from one end to the other as if both ends were physically in the same place. If you can determine the connection is working properly then any problems are likely problems with your applications.

On some FortiGate units, such as the FortiGate 94D, you cannot ping over the IPsec tunnel without first setting a source-IP. In this scenario, you must assign an IP address to the virtual IPsec VPN interface. Anything sourced from the FortiGate going over the VPN will use this IP address.

If the egress/outgoing interface (determined by kernel route) has an IP address, then use the IP address of the egress/outgoing interface. Otherwise, use the IP address of the first interface from the interface list (that has an IP address).

The first diagnostic command worth running, in any IPsec VPN troubleshooting situation, is the following: diagnose vpn tunnel list

This command is very useful for gathering statistical data such as the number of packets encrypted versus decrypted, the number of bytes sent versus received, the SPI identifier, etc. This kind of information in the resulting output can make all the difference in determining the issue with the VPN.

Another appropriate diagnostic command worth trying is: diagnose debug flow

This command will inform you of any lack of firewall policy, lack of forwarding route, and of policy ordering issues.

Common IPsec VPN problems

The most common IPsec VPN issues are listed below. Please read thoroughly and note that, although the list is extensive, it is not exhaustive.

This section includes support for the following:

l Failed VPN connection attempts l Debug output table l The options to configure policy-based IPsec VPN are unavailable l The VPN tunnel goes down frequently l The pre-shared key does not match (PSK mismatch error) l The SA proposals do not match (SA proposal mismatch) l Pre-existing IPsec VPN tunnels need to be cleared l Other potential VPN issues

Failed VPN connection attempts

If your VPN fails to connect, check the following:

• Ensure that the pre-shared keys match exactly (see The pre-shared key does not match (PSK mismatch error) below).
• Ensure that both ends use the same P1 and P2 proposal settings (seeThe SA proposals do not match (SA proposal mismatch) below).
• Ensure that you have allowed inbound and outbound traffic for all necessary network services, especially if services such as DNS or DHCP are having problems. l Check that a static route has been configured properly to allow routing of VPN traffic.

If you are still unable to connect to the VPN tunnel, run the following diagnostic command in the CLI:

diagnose debug application ike -1 diagnose debug enable

The resulting output may indicate where the problem is occurring. When you are finished, disable the diagnostics by using the following command:

diagnose debug reset diagnose debug disable

View the table below for some assistance in analyzing the debug output.

Debug output table

Problem	Debug output	Common causes	Common solutions
Tunnel is not coming up	Error: negotiation failure	IPsec configuration mismatch	Check phase 1 and 2 settings
Error: no SA proposal chosen	IPsec configuration mismatch	Check phase 1 and 2 settings
FortiGate using the wrong VPN	Missing or wrong local ID	If there are more than one preshared key dial-up VPN with the same local gateway, use aggressive mode and different local IDs
Error: connection expiring due to XAUTH failure	Wrong username, password, or user group	Check user credentials and user group configuration
Error: peer has not completed XAUTH exchange	XAuth is disabled in the client	Fix the client’s XAuth configuration
Tunnel is bouncing	DPD packets lost	ISP issue	Check the ISP connection

Common IPsec VPN problems

Problem	Debug output	Common causes	Common solutions
Tunnel is up but traffic does not go through	Error: No matching IPsec selector, drop	Quick mode selector mismatch	Fix the quick mode selector
NAT is enabled	Disable NAT in the firewall policy
Traffic is not routed to the tunnel	Route or firewall policy misconfiguration	Route-based: traffic must be routed to IPsec virtual interface Policy-based: traffic must match a firewall policy with action set to IPSEC

The options to configure policy-based IPsec VPN are unavailable

Go to System > Feature Visibility. Select Show More and turn on Policy-based IPsec VPN.

The VPN tunnel goes down frequently

If your VPN tunnel goes down often, check the Phase 2 settings and either increase the Keylife value or enable Autokey Keep Alive.

The pre-shared key does not match (PSK mismatch error)

It is possible to identify a PSK mismatch using the following combination of CLI commands:

diag vpn ike log filter name <phase1-name> diag debug app ike -1 diag debug enable

This will provide you with clues as to any PSK or other proposal issues. If it is a PSK mismatch, you should see something similar to the following output:

ike 0:TRX:322: PSK auth failed: probable pre-shared key mismatch ike Negotiate SA Error:

The SA proposals do not match (SA proposal mismatch)

The most common problem with IPsec VPN tunnels is a mismatch between the proposals offered between each party. Without a match and proposal agreement, Phase 1 can never establish. Use the following command to show the proposals presented by both parties. diag debug app ike -1 diag debug enable

The resulting output should include something similar to the following, where blue represents the remote VPN device, and green represents the local FortiGate.

responder received SA_INIT msg incoming proposal:

proposal id = 1:

protocol = IKEv2: encapsulation = IKEv2/none type=ENCR, val=AES_CBC (key_len = 256)

Common IPsec VPN problems

type=INTEGR, val=AUTH_HMAC_SHA_96 type=PRF, val=PRF_HMAC_SHA type=DH_GROUP, val=1536.

proposal id = 2:

protocol = IKEv2: encapsulation = IKEv2/none type=ENCR, val=3DES_CBC

type=INTEGR, val=AUTH_HMAC_SHA_2_256_128 type=PRF, val=PRF_HMAC_SHA2_256 type=DH_GROUP, val=1536.

proposal id = 1:

protocol = IKEv2: encapsulation = IKEv2/none type=ENCR, val=AES_CBC (key_len = 128) type=INTEGR, val=AUTH_HMAC_SHA_96 type=PRF, val=PRF_HMAC_SHA type=DH_GROUP, val=1536.

Pre-existing IPsec VPN tunnels need to be cleared

Should you need to clear an IKE gateway, use the following commands:

diagnose vpn ike restart diagnose vpn ike gateway clear

Other potential VPN issues

• Ensure that your FortiGate unit is in NAT/Route mode, rather than Transparent.
• Check your NAT settings, enabling NAT traversal in the Phase 1 configuration while disabling NAT in the security policy. You might need to pin the PAT/NAT session table, or use some of kind of NAT-T keepalive to avoid the expiration of your PAT/NAT translation.
• Ensure that both ends of the VPN tunnel are using Main mode, unless multiple dial-up tunnels are being used.
• Remove any Phase 1 or Phase 2 configurations that are not in use. If a duplicate instance of the VPN tunnel appears on the IPsec Monitor, reboot your FortiGate unit to try and clear the entry.
• If you have multiple dial-up IPsec VPNs, ensure that the peer ID is configured properly on the FortiGate and that clients have specified the correct local ID. Furthermore, in circumstances where multiple remote dialup VPN tunnels exist, each tunnel must have a peer ID set.
• If you are using FortiClient, ensure that your version is compatible with the FortiGate firmware by reading the FortiOS Release Notes. l If you are using Perfect Forward Secrecy (PFS), ensure that it is used on both peers. You can use the diagnose

vpn tunnel list command to troubleshoot this.

• Ensure that the Quick Mode selectors are correctly configured. If part of the setup currently uses firewall addresses or address groups, try changing it to either specify the IP addresses or use an expanded address range. This is especially useful if the remote endpoint is not a FortiGate device.
• If XAUTH is enabled, ensure that the settings are the same for both ends, and that the FortiGate unit is set to Enable as Server.
• Check IPsec VPN Maximum Transmission Unit (MTU) size. A 1500 byte MTU is going to exceed the overhead of the ESP-header, including the additional ip_header,etc. You can use the diagnose vpn tunnel list command to troubleshoot this.

Troubleshooting connection issues

• If your FortiGate unit is behind a NAT device, such as a router, configure port forwarding for UDP ports 500 and 4500.

Troubleshooting connection issues

The following section includes troubleshooting suggestions related to:

l LAN interface connection l Dialup connection l Troubleshooting VPN connections l Troubleshooting invalid ESP packets using Wireshark l Attempting hardware offloading beyond SHA1 l Check Phase 1 proposal settings l Check your routing l Try enabling XAuth

LAN interface connection

To confirm whether a VPN connection over LAN interfaces has been configured correctly, issue a ping or traceroute command on the network behind the FortiGate unit to test the connection to a computer on the remote network. If the connection is properly configured, a VPN tunnel will be established automatically when the first data packet destined for the remote network is intercepted by the FortiGate unit.

If the ping or traceroute fail, it indicates a connection problem between the two ends of the tunnel. This may or may not indicate problems with the VPN tunnel. You can confirm this by going to Monitor > IPsec Monitor where you will be able to see your connection. A green arrow means the tunnel is up and currently processing traffic. A red arrow means the tunnel is not processing traffic, and this VPN connection has a problem.

If the connection has problems, see Troubleshooting VPN connections on page 227.

Dialup connection

A dialup VPN connection has additional steps. To confirm that a VPN between a local network and a dialup client has been configured correctly, at the dialup client, issue a ping command to test the connection to the local network. The VPN tunnel initializes when the dialup client attempts to connect.

If the ping or traceroute fail, it indicates a connection problem between the two ends of the tunnel. This may or may not indicate problems with the VPN tunnel, or dialup client. As with the LAN connection, confirm the VPN tunnel is established by checking Monitor > IPsec Monitor.

Troubleshooting VPN connections

If you have determined that your VPN connection is not working properly through Troubleshooting on page 223, the next step is to verify that you have a phase2 connection.

If traffic is not passing through the FortiGate unit as you expect, ensure the traffic does not contain IPcomp packets (IP protocol 108, RFC 3173). FortiGate units do not allow IPcomp packets, they compress packet payload, preventing it from being scanned.

Testing Phase 1 and 2 connections is a bit more difficult than testing the working VPN. This is because they require diagnose CLI commands. These commands are typically used by Fortinet customer support to discover more information about your FortiGate unit and its current configuration.

Before you begin troubleshooting, you must:

• Configure FortiGate units on both ends for interface VPN l Record the information in your VPN Phase 1 and Phase 2 configurations – for our example here the remote IP

address is 10.11.101.10 and the names of the phases are Phase 1 and Phase 2

• Install a telnet or SSH client such as putty that allows logging of output l Ensure that the admin interface supports your chosen connection protocol so you can connect to your FortiGate unit admin interface.

For this example, default values were used unless stated otherwise.

Obtaining diagnose information for the VPN connection – CLI

1. Log into the CLI as admin with the output being logged to a file.
2. Stop any diagnose debug sessions that are currently running with the CLI command diagnose debug disable
3. Clear any existing log-filters by running

diagnose vpn ike log-filter clear

1. Set the log-filter to the IP address of the remote computer (10.11.101.10). This filters out all VPN connections except ones to the IP address we are concerned with. The command is diagnose vpn ike log-filter dst-addr4 10.11.101.10.
2. Set up the commands to output the VPN handshaking. The commands are:

diagnose debug app ike 255 diagnose debug enable

1. Have the remote FortiGate initiate the VPN connection in the web-based manager by going to VPN > IPsec Tunnels and selecting Bring up.

This makes the remote FortiGate the initiator and the local FortiGate becomes the responder. Establishing the connection in this manner means the local FortiGate will have its configuration information as well as the information the remote computer sends. Having both sets of information locally makes it easier to troubleshoot your VPN connection.

1. Watch the screen for output, and after roughly 15 seconds enter the following CLI command to stop the output.

diagnose debug disable

1. If needed, save the log file of this output to a file on your local computer. Saving the output to a file can make it easier to search for a particular phrase, and is useful for comparisons.

Troubleshooting a Phase 1 VPN connection

Using the output from Obtaining diagnose information for the VPN connection – CLI, search for the word proposal in the output. It may occur once indicating a successful connection, or it will occur two or more times for an unsuccessful connection — there will be one proposal listed for each end of the tunnel and each possible Troubleshooting connection issues

combination in their settings. For example if 10.11.101.10 selected both Diffie-Hellman Groups 1 and 5, that would be at least 2 proposals set.

A successful negotiation proposal will look similar to

IPsec SA connect 26 10.12.101.10->10.11.101.10:500 config found created connection: 0x2f55860 26 10.12.101.10->10.11.101.10:500 IPsec SA connect 26 10.12.101.10->10.11.101.10:500 negotiating no suitable ISAKMP SA, queuing quick-mode request and initiating ISAKMP SA negotiation initiator: main mode is sending 1st message…

cookie 3db6afe559e3df0f/0000000000000000 out [encryption]

sent IKE msg (ident-i1send): 10.12.101.10:500->10.11.101.10:500, len=264, id=3db6afe559e3df0f/0000000000000000

diaike 0: comes 10.12.101.1:500->10.11.101.1:500,ifindex=26….

Note the phrase “initiator: main mode is sending 1st message…” which shows you the

handshake between the ends of the tunnel is in progress. Initiator shows the remote unit is sending the first message.

Troubleshooting invalid ESP packets using Wireshark

The following section provides information to help debug an encryption key mismatch. The ESP packet invalid error is due to an encryption key mismatch after a VPN tunnel has been established. When an IPsec VPN tunnel is up, but traffic is not able to pass through the tunnel, Wireshark (or an equivalent program) can be used to determine whether there is an encryption mismatch. A mismatch could occur for many reasons, one of the most common is the instability of an ISP link (ADSL, Cable), or it could effectively be any device in the physical connection.

The following information is required to troubleshoot the problem.

• Take a packet sniffer trace on both FortiGates.
• Run the diag vpn tunnel list command a few times on both FortiGates when generating traffic that will pass through the tunnel.

In the following example, the error message was seen on the recipient FortiGate:

date=2010-12-28 time=18:19:35 devname=Kosad_VPN device_id=FG300B3910600118 log_ id=0101037132 type=event subtype=ipsec pri=critical vd=”root” msg=”IPsec ESP” action=”error” rem_ ip=180.87.33.2 loc_ip=121.133.8.18 rem_port=32528 loc_port=4500 out_intf=”port2″ cookies=”88d40f65d555ccaf/05464e20e4afc835″user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”fortinet_0″ status=esp_error error_num=Invalid ESP packet detected (HMAC validation failed). spi=c32b09f7 seq=00000012

This is the output of the command diag vpn tunnel list on the FortiGate:

inet ver=1 serial=2 192.168.1.205:4500->121.133.8.18:4500 lgwy=dyn tun=intf mode=auto bound_if=4 proxyid_num=1 child_num=0 refcnt=7 ilast=0 olast=0 stat: rxp=41 txp=56 rxb=4920 txb=3360 dpd: mode=active on=1 idle=5000ms retry=3 count=0 seqno=696 natt: mode=keepalive draft=32 interval=10 remote_port=4500 proxyid=P2_60C_Fortinet proto=0 sa=1 ref=2 auto_negotiate=0 serial=1 src:

0:182.40.101.0/255.255.255.0:0 dst: 0:100.100.100.0/255.255.255.0:0 connection issues

SA: ref=3 options=0000000d type=00 soft=0 mtu=1428 expire=1106 replaywin=0 seqno=15 life: type=01 bytes=0/0 timeout=1777/1800

dec: spi=29a26eb6 esp=3des key=24 bf25e69df90257f64c55dda4069f01834cd0382fe4866ff2 ah=sha1 key=20 38b2600170585d2dfa646caed5bc86d920aed7ff

enc: spi=c32b09f7 esp=3des key=24 0abd3c70032123c3369a6f225a385d30f0b2fb1cd9687ec8 ah=sha1 key=20 214d8e717306dffceec3760464b6e8edb436c6 This is the packet capture from the FortiGate:

How to verify if the original packet has been encrypted correctly

To verify, it is necessary to decrypt the ESP packet using Wireshark. Open the packet capture that is taken from initiator FortiGate using Wireshark. Go to Edit > Preferences, expand Protocol and look for ESP. Select “Attempt to detect/decode encrypted ESP payloads“, and fill in the information for the encryption algorithm and the keys. This information can be obtained from the output of the command diag vpn tunnel list.

If the packet was encrypted correctly using the correct key, then the decryption will be successful and it will be possible to see the original package as shown below:

Repeat the decryption process for the packet capture from the recipient firewall. If the decryption failed using the same key, the packet may be corrupted and the interface should then be checked for CRC or packet errors.

Attempting hardware offloading beyond SHA1

If you are trying to off-load VPN processing to a network processing unit (NPU), remember that only SHA1 authentication is supported. For high levels of authentication such as SHA256, SHA384, and SHA512 hardware offloading is not an option—all VPN processing must be done in software—unless using an NP6 (although the NP4lite variation also supports SHA256, SHA384, and SHA512).

Enable/disable IPsec ASIC-offloading

Much like NPU-offload in IKE phase1 configuration, you can enable or disable the usage of ASIC hardware for IPsec Diffie-Hellman key exchange and IPsec ESP traffic. By default hardware offloading is used. For debugging purposes, sometimes it is best for all the traffic to be processed by software.

config sys global set ipsec-asic-offload [enable | disable] end

Check Phase 1 proposal settings

Ensure that both sides have at least one Phase 1 proposal in common. Otherwise they will not connect. If there are many proposals in the list, this will slow down the negotiating of Phase 1. If its too slow, the connection may timeout before completing. If this happens, try removing some of the unused proposals.

NPU offloading is supported when the local gateway is a loopback interface.

Check your routing

If routing is not properly configured with an entry for the remote end of the VPN tunnel, traffic will not flow properly. You may need static routes on both ends of the tunnel. If routing is the problem, the proposal will likely setup properly but no traffic will flow.

Try enabling XAuth

If one end of an attempted VPN tunnel is using XAuth and the other end is not, the connection attempt will fail. The log messages for the attempted connection will not mention XAuth is the reason, but when connections are failing it is a good idea to ensure both ends have the same XAuth settings. If you do not know the other end’s settings enable or disable XAuth on your end to see if that is the problem.

General troubleshooting tips

Most connection failures are due to a configuration mismatch between the FortiGate unit and the remote peer. In general, begin troubleshooting an IPsec VPN connection failure as follows:

1. Ping the remote network or client to verify whether the connection is up. See General troubleshooting tips on page 231.
2. Traceroute the remote network or client. If DNS is working, you can use domain names. Otherwise use IP addresses.
3. Check the routing behind the dialup client. Routing problems may be affecting DHCP. If this appears to be the case, configure a DHCP relay service to enable DHCP requests to be relayed to a DHCP server on or behind the FortiGate server.
4. Verify the configuration of the FortiGate unit and the remote peer. Check the following IPsec parameters: l The mode setting for ID protection (main or aggressive) on both VPN peers must be identical.
   • The authentication method (preshared keys or certificates) used by the client must be supported on the FortiGate unit and configured properly.
   • If preshared keys are being used for authentication purposes, both VPN peers must have identical preshared keys.
   • The remote client must have at least one set of Phase 1 encryption, authentication, and Diffie-Hellman settings that match corresponding settings on the FortiGate unit.
   • Both VPN peers must have the same NAT traversal setting (enabled or disabled).
   • The remote client must have at least one set of Phase 2 encryption and authentication algorithm settings that match the corresponding settings on the FortiGate unit.
   • If you are using manual keys to establish a tunnel, the Remote SPI setting on the FortiGate unit must be identical to the Local SPI setting on the remote peer, and vise versa.

1. To correct the problem, see the following table.

VPN troubleshooting tips

Configuration problem	Correction
Mode settings do not match.	Select complementary mode settings. See Phase 1 parameters on page 46.
Peer ID or certificate name of the remote peer or dialup client is not recognized by FortiGate VPN server.	Check Phase 1 configuration. Depending on the Remote Gateway and Authentication Method settings, you have a choice of options to authenticate FortiGate dialup clients or VPN peers by ID or certificate name (see Phase 1 parameters on page 46). If you are configuring authentication parameters for FortiClient dialup clients, refer to the Authenticating FortiClient Dialup Clients Technical Note.
Preshared keys do not match.	Reenter the preshared key. See Phase 1 parameters on page 46.
Phase 1 or Phase 2 key exchange proposals are mismatched.	Make sure that both VPN peers have at least one set of proposals in common for each phase. See Phase 1 parameters on page 46 and Phase 2 parameters on page 66.
NAT traversal settings are mismatched.	Select or clear both options as required. See Phase 1 parameters on page 46 and Phase 1 parameters on page 46.

A word about NAT devices

When a device with NAT capabilities is located between two VPN peers or a VPN peer and a dialup client, that device must be NAT traversal (NAT-T) compatible for encrypted traffic to pass through the NAT device. For more information, see Phase 1 parameters on page 46.

Troubleshooting L2TP and IPsec

This section describes some checks and tools you can use to resolve issues with L2TP-over-IPsec VPNs.

This section includes:

• Quick checks l Mac OS X and L2TP
• Setting up logging
• Using the FortiGate unit debug commands

Quick checks

The table below is a list of common L2TP over IPsec VPN problems and the possible solutions.

L2TP and

Problem	What to check
IPsec tunnel does not come up.	Check the logs to determine whether the failure is in Phase 1 or Phase 2. Check the settings, including encapsulation setting, which must be transport-mode. Check the user password. Confirm that the user is a member of the user group assigned to L2TP. On the Windows PC, check that the IPsec service is running and has not been disabled. See Troubleshooting L2TP and IPsec on page 232.
Tunnel connects, but there is no communication.	Did you create an ACCEPT security policy from the public network to the protected network for the L2TP clients? See Troubleshooting L2TP and IPsec on page 232.

Mac OS X and L2TP

FortiOS allows L2TP connections with empty AVP host names and therefore Mac OS X L2TP connections can connect to the FortiGate.

Prior to FortiOS 4.0 MR3, FortiOS refused L2TP connections with empty AVP host names in compliance with RFC 2661 and RFC 3931.

Setting up logging

L2TP logging must be enabled to record L2TP events. Alert email can be configured to report L2TP errors.

Configuring FortiGate logging for L2TP over IPsec

1. Go to Log & Report > Log Settings.
2. Select Event Log.
3. Select the VPN activity event check box.
4. Select Apply.

Viewing FortiGate logs

1. Go to Log & Report > VPN Events.
2. Select the Log location if required.
3. After each attempt to start the L2TP over IPsec VPN, select Refresh to view logged events.

Using the FortiGate unit debug commands

Viewing debug output for IKE and L2TP

1. Start an SSH or Telnet session to your FortiGate unit.
2. Enter the following CLI commands

L2TP and diagnose debug application ike -1 diagnose debug application l2tp -1 diagnose debug enable

1. Attempt to use the VPN and note the debug output in the SSH or Telnet session.
2. Enter the following command to reset debug settings to default:

diagnose debug reset

Using the packet sniffer

1. Start an SSH or Telnet session to your FortiGate unit.
2. Enter the following CLI command diagnose sniffer packet any icmp 4
3. Attempt to use the VPN and note the debug output.
4. Enter Ctrl-C to end sniffer operation.

Typical L2TP over IPsec session startup log entries – raw format

2010-01-11 16:39:58 log_id=0101037127 type=event subtype=ipsec pri=notice vd=”root” msg=”progress IPsec Phase 1″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1″ status=success init=remote mode=main dir=outbound stage=1 role=responder result=OK

2010-01-11 16:39:58 log_id=0101037127 type=event subtype=ipsec pri=notice vd=”root” msg=”progress IPsec Phase 1″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1″ status=success init=remote mode=main dir=outbound stage=2 role=responder result=OK

2010-01-11 16:39:58 log_id=0101037127 type=event subtype=ipsec pri=notice vd=”root” msg=”progress IPsec Phase 1″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1″ status=success init=remote mode=main dir=inbound stage=3 role=responder result=DONE

2010-01-11 16:39:58 log_id=0101037127 type=event subtype=ipsec pri=notice vd=”root” msg=”progress IPsec Phase 1″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1_0″ status=success init=remote mode=main dir=outbound stage=3 role=responder result=DONE

2010-01-11 16:39:58 log_id=0101037129 type=event subtype=ipsec pri=notice vd=”root” msg=”progress IPsec Phase 2″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1_0″ status=success init=remote mode=quick dir=outbound stage=1 role=responder result=OK

2010-01-11 16:39:58 log_id=0101037133 type=event subtype=ipsec pri=notice vd=”root” msg=”install IPsec SA” action=”install_sa” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1_0″ role=responder in_spi=61100fe2 out_spi=bd70fca1

2010-01-11 16:39:58 log_id=0101037139 type=event subtype=ipsec pri=notice vd=”root” msg=”IPsec Phase 2 status change” action=”phase2-up” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_group=”N/A” vpn_tunnel=”dialup_p1_0″ phase2_name=dialup_p2

2010-01-11 16:39:58 log_id=0101037138 type=event subtype=ipsec pri=notice vd=”root” msg=”IPsec connection status change” action=”tunnel-up” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_ user=”N/A” xauth_group=”N/A” vpn_tunnel=”dialup_p1_0″ tunnel_ip=172.20.120.151 tunnel_id=1552003005 tunnel_type=ipsec duration=0 sent=0 rcvd=0 next_stat=0 tunnel=dialup_p1_0

GRE over

2010-01-11 16:39:58 log_id=0101037129 type=event subtype=ipsec pri=notice vd=”root” msg=”progress IPsec Phase 2″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1_0″ status=success init=remote mode=quick dir=inbound stage=2 role=responder result=DONE

2010-01-11 16:39:58 log_id=0101037122 type=event subtype=ipsec pri=notice vd=”root” msg=”negotiate IPsec Phase 2″ action=”negotiate” rem_ip=172.20.120.151 loc_ip=172.20.120.141 rem_port=500 loc_port=500 out_ intf=”port1″ cookies=”5f6da1c0e4bbf680/d6a1009eb1dde780″ user=”N/A” group=”N/A” xauth_user=”N/A” xauth_ group=”N/A” vpn_tunnel=”dialup_p1_0″ status=success role=responder esp_transform=ESP_3DES esp_auth=HMAC_ SHA1

2010-01-11 16:39:58 log_id=0103031008 type=event subtype=ppp vd=root pri=information action=connect status=success msg=”Client 172.20.120.151 control connection started (id 805), assigned ip 192.168.0.50″

2010-01-11 16:39:58 log_id=0103029013 type=event subtype=ppp vd=root pri=notice pppd is started

2010-01-11 16:39:58 log_id=0103029002 type=event subtype=ppp vd=root pri=notice user=”user1″ local=172.20.120.141 remote=172.20.120.151 assigned=192.168.0.50 action=auth_success msg=”User ‘user1’ using l2tp with authentication protocol MSCHAP_V2, succeeded”

2010-01-11 16:39:58 log_id=0103031101 type=event subtype=ppp vd=root pri=information action=tunnel-up tunnel_id=1645784497 tunnel_type=l2tp remote_ip=172.20.120.151 tunnel_ip=192.168.0.50 user=”user1″ group=”L2TPusers” msg=”L2TP tunnel established”

Troubleshooting GRE over IPsec

This section describes some checks and tools you can use to resolve issues with the GRE-over-IPsec VPN.

Quick checks

Here is a list of common problems and what to verify.

Problem	What to check
No communication with remote network.	Use the execute ping command to ping the Cisco device public interface. Use the FortiGate VPN Monitor page to see whether the IPsec tunnel is up or can be brought up.
IPsec tunnel does not come up.	Check the logs to determine whether the failure is in Phase 1 or Phase 2. Check that the encryption and authentication settings match those on the Cisco device. Check the encapsulation setting: tunnel-mode or transport-mode. Both devices must use the same mode.
Tunnel connects, but there is no communication.	Check the security policies. See Troubleshooting GRE over IPsec on page 235. Check routing. See Troubleshooting GRE over IPsec on page 235.

Setting up logging

Configuring FortiGate logging for IPsec

1. Go to Log & Report > Log Settings.
2. Select the Event Logging.
3. Select VPN activity event.
4. Select Apply.

Viewing FortiGate logs

1. Go to Log & Report > VPN Events.
2. Select the log storage type.
3. Select Refresh to view any logged events.

GRE tunnel keepalives

In the event that each GRE tunnel endpoint has keepalive enabled, firewall policies allowing GRE are required in both directions. The policy should be configured as follows (where the IP addresses and interface names are for example purposes only):

config firewall policy edit < id >

set srcintf “gre” set dstintf “port1” set srcaddr “1.1.1.1” set dstaddr “2.2.2.2” set action accept set schedule “always” set service “GRE”

next

end

Cisco compatible keep-alive support for GRE

The FortiGate can send a GRE keepalive response to a Cisco device to detect a GRE tunnel. If it fails, it will remove any routes over the GRE interface.

Configuring keepalive query – CLI:

config system gre-tunnel edit <id> set keepalive-interval <value: 0-32767> set keepalive-failtimes <value: 1-255>

next

end

GRE tunnel with multicast traffic

If you want multicast traffic to traverse the GRE tunnel, you need to configure a multicast policy as well as enable multicast forwarding.

GRE over

• To configure a multicast policy, use the config firewall multicast-policy
• To enable multicast forwarding, use the following commands:

config system settings set multicast-forward enable

end

Using diagnostic commands

There are some diagnostic commands that can provide useful information. When using diagnostic commands, it is best practice that you connect to the CLI using a terminal program, such as puTTY, that allows you to save output to a file. This will allow you to review the data later on at your own speed without worry about missed data as the diag output scrolls by.

Using the packet sniffer – CLI:

1. Enter the following CLI command:

diag sniff packet any icmp 4

1. Ping an address on the network behind the FortiGate unit from the network behind the Cisco router.

The output will show packets coming in from the GRE interface going out of the interface that connects to the protected network (LAN) and vice versa. For example:

114.124303 gre1 in 10.0.1.2 -> 10.11.101.10: icmp: echo request

114.124367 port2 out 10.0.1.2 -> 10.11.101.10: icmp: echo request

114.124466 port2 in 10.11.101.10 -> 10.0.1.2: icmp: echo reply

114.124476 gre1 out 10.11.101.10 -> 10.0.1.2: icmp: echo reply

1. Enter CTRL-C to stop the sniffer.

Viewing debug output for IKE – CLI:

1. Enter the following CLI commands diagnose debug application ike -1 diagnose debug enable
2. Attempt to use the VPN or set up the VPN tunnel and note the debug output.
3. Enter CTRL-C to stop the debug output.
4. Enter the following command to reset debug settings to default:

diagnose debug reset

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Don’t Forget To visit the YouTube Channel for the latest Fortinet Training Videos and Question / Answer sessions!
— FortinetGuru YouTube Channel
— FortiSwitch Training Videos

Cybersecurity Videos and Training Available Via: Office of The CISO Security Training Videos