Verifying the traffic

To verify that pings are sent across the IPsec VPN tunnels
  • On the HQ FortiGate, run the following CLI command:
    # diagnose sniffer packet any 'host 10.0.2.10' 4 0 1 interfaces=[any]
    Using Original Sniffing Mode
    interfaces=[any]
    filters=[host 10.0.2.10]
    pcap_snapshot: snaplen raised from 0 to 262144
    2021-06-05 11:35:14.822600 AWS_VPG out 169.254.55.154 -> 10.0.2.10: icmp: echo request
    2021-06-05 11:35:14.822789 FGT_AWS_Tun out 172.16.200.2 -> 10.0.2.10: icmp: echo request
    2021-06-05 11:35:14.877862 FGT_AWS_Tun in 10.0.2.10 -> 172.16.200.2: icmp: echo reply
    2021-06-05 11:35:14.878887 AWS_VPG in 10.0.2.10 -> 169.254.55.154: icmp: echo reply
  • On the cloud FortiGate-VM, run the following CLI command:
    # diagnose sniffer packet any 'host 10.0.2.10' 4 0 1 interfaces=[any]
    Using Original Sniffing Mode
    interfaces=[any]
    filters=[host 10.0.2.10]
    pcap_snapshot: snaplen raised from 0 to 262144
    2021-06-05 11:37:57.176329 port2 in 169.254.55.154 -> 10.0.2.10: icmp: echo request
    2021-06-05 11:37:57.176363 port2 out 10.0.2.10 -> 169.254.55.154: icmp: echo reply
    2021-06-05 11:37:57.176505 Core_Dialup in 172.16.200.2 -> 10.0.2.10: icmp: echo request
    2021-06-05 11:37:57.176514 Core_Dialup out 10.0.2.10 -> 172.16.200.2: icmp: echo reply
To verify the SLA health checks on the HQ FortiGate:
  1. Go to Network > SD-WAN, select the Performance SLAs tab, select Packet Loss, and click the ping_AWS_Gateway SLA:

  2. Run the following CLI command:
    # diagnose sys sdwan health-check
    …
    Seq(1 AWS_VPG): state(alive), packet-loss(0.000%) latency(56.221), jitter(0.290) sla_map=0x0
    Seq(2 FGT_AWS_Tun): state(alive), packet-loss(0.000%) latency(55.039), jitter(0.223) sla_map=0x0
To verify service rules:
  1. Go to Network > SD-WAN and select the SD-WAN Rules tab:

  2. Run the following CLI command:
    # diagnose sys sdwan service
    
    Service(1): Address Mode(IPV4) flags=0x0
      Gen(1), TOS(0x0/0x0), Protocol(6: 80->80), Mode(manual)
      Members:
        1: Seq_num(2 FGT_AWS_Tun), alive, selected
      Src address:
            0.0.0.0-255.255.255.255
      Dst address:
            10.0.2.0-10.0.2.255
    
    Service(2): Address Mode(IPV4) flags=0x0
      Gen(1), TOS(0x0/0x0), Protocol(6: 22->22), Mode(manual)
      Members:
        1: Seq_num(1 AWS_VPG), alive, selected
      Src address:
            0.0.0.0-255.255.255.255
      Dst address:
            10.0.2.0-10.0.2.255
    
    Service(3): Address Mode(IPV4) flags=0x0
      Gen(1), TOS(0x0/0x0), Protocol(6: 443->443), Mode(manual)
      Members:
        1: Seq_num(2 FGT_AWS_Tun), alive, selected
      Src address:
            0.0.0.0-255.255.255.255
      Dst address:
            10.0.2.0-10.0.2.255
    
    Service(4): Address Mode(IPV4) flags=0x0
      Gen(1), TOS(0x0/0x0), Protocol(0: 1->65535), Mode(manual)
      Members:
        1: Seq_num(1 AWS_VPG), alive, selected
      Src address:
            0.0.0.0-255.255.255.255
      Dst address:
            10.0.2.21-10.0.2.21
To verify that sessions are going to the correct tunnel:
  1. Run the following CLI command to verify that HTTPS and HTTP traffic destined for the Web server at 10.0.2.20 uses FGT_AWS_Tun:
    # diagnose sys session filter dst 10.0.2.20
    # diagnose sys session list
    
    session info: proto=6 proto_state=11 duration=2 expire=3597 timeout=3600 flags=00000000 socktype=0 sockport=0 av_idx=0 use=4
    origin-shaper=
    reply-shaper=
    per_ip_shaper=
    class_id=0 ha_id=0 policy_dir=0 tunnel=FGT_AWS_Tun/ vlan_cos=0/255
    state=log may_dirty npu f00 csf_syncd_log app_valid
    statistic(bytes/packets/allow_err): org=593/4/1 reply=3689/5/1 tuples=3
    tx speed(Bps/kbps): 264/2 rx speed(Bps/kbps): 1646/13
    orgin->s