Fortinet NSE8/FCX Certification

Tag: nse8

  • Fortinet NSE Exam Practice Questions – FortiGate FortiOS 7.6 – Set 2

    These practice questions are original and hand-written as a personal aid while studying for the Fortinet NSE8 exam. Content may or may not be applicable to any specific exam levels, but may be useful for the NSE4, NSE7, NSE8, FCP, or FCSS FortiGate exams. No questions are pulled from actual exams. Content is sourced from and fact-checked via official Fortinet Documentation.

    Question 1

    What will happen to traffic matching the following route?
    config router policy
    edit 1
    set src "10.250.4.5/255.255.255.255"
    set dst "142.251.111.0/255.255.255.0"
    set action deny
    next
    end

    ← Back

    Thank you for your response. ✨

    Choose one option(required)

    Show Answer and Explanation

    Answer:
    The standard routing table (RIB) will be used to evaluate the traffic

    Explanation:
    The deny action, depicted in the Policy-Based Route GUI by the Stop Policy Routing Action, and when applied to a policy, will force any matched traffic to stop being evaluated by any policy routing (PBRs, ISDB Static Routes, or SD-WAN rules) and go straight to being evaluated by the standard routing table (RIB).

    Question 2

    BGP isn’t coming up between your two FortiGates that are connected via an IPsec tunnel called “Hub-and-Spoke”, which has been verified as up and able to pass traffic. What can be configured to bring BGP up between the two FortiGates?

    Firewall 1 (AzFW01) Configurations and Diagnostics:
    AzFW01 (10.100.1.1/32) # show
    config system interface
    edit "10.100.1.1/32"
    set vdom "root"
    set vrf 20
    set ip 10.100.1.1 255.255.255.255
    set allowaccess ping
    set type loopback
    set role lan
    next
    end

    AzFW01 (bgp) # show
    config router bgp
    set as 100
    config neighbor
    edit "10.200.1.1"
    set soft-reconfiguration enable
    set interface "10.100.1.1/32"
    set remote-as 100
    set update-source "10.100.1.1/32"
    next
    end
    config network
    edit 1
    set prefix 10.250.0.0 255.255.0.0
    next
    edit 2
    set prefix 10.100.1.1 255.255.255.255
    next
    end


    Firewall 2 (AzFW02) Configurations and Diagnostics:
    AzFW02 (BGP Loopback) # show
    config system interface
    edit "BGP Loopback"
    set vdom "root"
    set vrf 20
    set ip 10.200.1.1 255.255.255.255
    set allowaccess ping
    set type loopback
    set role lan
    next
    end

    AzFW02 (bgp) # show
    config router bgp
    set as 100
    config neighbor
    edit "10.100.1.1"
    set soft-reconfiguration enable
    set interface "BGP Loopback"
    set remote-as 100
    set update-source "BGP Loopback"
    next
    end
    config network
    edit 1
    set prefix 10.251.0.0 255.255.0.0
    next
    edit 2
    set prefix 10.200.1.1 255.255.255.255
    next
    end

    ← Back

    Thank you for your response. ✨

    Choose up to five options(required)

    Show Answer and Explanation

    Answer:
    On both FortiGates’ BGP loopback interfaces (labeled “10.100.1.1/32 and BGP Loopback), set vrf 0

    Explanation:
    Out of all the listed options, the answer above is the only change that will allow BGP to come up between the FortiGates. The base issue is that the BGP loopback interfaces (“10.100.1.1/32” and “BGP Loopback”, sorry for the confusing names here, they’re both functioning as BGP loopbacks) on both FortiGates cannot reach each other. The question states that the devices are connected via an IPsec tunnel called Hub-and-Spoke, which from the routing table on both FortiGates show, resides in VRF 0. The BGP loopback interfaces themselves reside in VRF 20.

    On both FortiGates, a static route via Hub-and-Spoke to the peer’s loopback IP
    This is already configured on both FortiGates, as seen by the route table entries for 10.100.1.1/32 and 10.200.1.1/32 in VRF 0.

    BGP VRF route leaking from VRF 0 into VRF 20
    This would add the single VRF 0 routes into the VRF 20 routing table, but only once BGP is up.

    On both FortiGates, set ebgp-enforce-multihop enable on the neighbor configuration, change AzFW02’s AS to 200, and AzFW01’s neighbor AS to 100
    These steps would configure eBGP, but the eBGP peering would still not come up due to the VRF issue.

    On both FortiGates, enabling the redistribution of all static and connected routes into BGP
    This would allow each FortiGate’s static and connected routes to be redistributed into BGP, but because BGP is not up and sharing routes, no redistribution would yet occur.





    Question 3

    Which of the following interfaces will be used for traffic to 55.55.55.55/32?

    ← Back

    Thank you for your response. ✨

    Choose one option(required)

    Show Answer and Explanation

    Answer:
    Proxy-VLAN

    Explanation:
    This is a simple administrative distance (AD) and static route priority order question. All routes are identical in destination, so the route with the lowest AD will be selected. As a tiebreaker between static routes with the same AD, the route with the lowest priority will be selected. If two static routes share the same destination, AD, and priority, they will be ECMP load-balanced.
    With this said, the order of priority for the listed routes is:
    Proxy-VLAN > asymVPN > Captive > 10.200.2.1/24

    Question 4

    Your FortiGate has the following configurations. Which of the following packet types will be evaluated by firewall policies and require an allow policy match to pass through the FortiGate?
    config system settings
    set asymroute enable
    set asymroute-icmp enable
    end

    ← Back

    Thank you for your response. ✨

    Choose up to six options(required)

    Show Answer and Explanation

    Answer:
    TCP SYN packets
    UDP packets

    Explanation:
    TCP SYN packets are not part of an existing session and will always require a firewall policy to pass.
    UDP packets are always checked by firewall policies, regardless of whether they’re part of an existing session or not.
    The asymroute and asymroute-icmp configurations do not change either of the above facts.

    TCP non-SYN packets that are part of an existing session, by the nature of stateful firewalls like FortiGate, do not require a firewall policy match to pass.
    TCP non-SYN packets that are NOT part of an existing session, when asymroute is enabled, are punted to the CPU and no firewall or security inspection will occur.
    ICMP packets that are part of an existing session, by the nature of stateful firewalls like FortiGate, do not require a firewall policy to pass.
    ICMP packets that are NOT part of an existing session, when asymroute-icmp is enabled, are punted to the CPU and no firewall or security inspection will occur.

    Question 5

    With the policy route and full routing table shown in the images below, users are reporting that App Store web traffic is failing. Which of the following configurations is most likely to remediate the issue?

    ← Back

    Thank you for your response. ✨

    Choose up to five options(required)

    Show Answer and Explanation

    Answer:
    Adding a default static route via the Outside interface

    Explanation:
    Policy-based routes, like SD-WAN routes, are only functional if there is a route in the RIB via the specified outgoing interface. The route table shows no routes to public/internet IPs. Adding a default route (0.0.0.0/0) via the Outside interface would allow for the policy-based route to function.

    Setting the gateway address on the policy-based route to the Outside interface’s WAN gateway is not required for a policy-based route to function. When only the outgoing interface is specified, FortiGate will do a RIB lookup for the gateway address matching interface.

    Removing the Apple-App.Store internet service and instead specifying the Apple App Store well known FQDNs as the destination address will have no effect on the functionality of the policy route, other than changing which destinations are matched. Traffic will still not be able to reach the Apple App Store without a route to the public internet.

    Changing the source port to 443 and destination port to 0 – 65535 will break the functionality of this policy-based route even further. Port 443 for web/HTTPS traffic is a destination port. When packets are sent for HTTPS web traffic, they are destined to 443 and sourced from a random ephemeral port (typically between 49152 and 65535). With 443 set as the source port, this PBR will only match when the random source port happens to be 443, which it never would.


    Question 6

    With the following configurations, you notice that SNMP polling and testing via SNMP walks is failing. You’ve verified your SNMP server is configured correctly to point to 10.250.4.4 and your SNMP community string matches. Which of the following changes are most likely to fix the SNMP issue?

    config system ha
    set mode a-p
    set group-name "HA"
    set password ENC [Redacted Password]
    set hbdev "port2" 0
    set override enable
    set priority 255
    set ha-mgmt-status enable
    config ha-mgmt-interface
    edit 1
    set interface port2
    next
    end
    end
    config system interface
    edit "port2"
    set vdom "root"
    set ip 10.250.4.4 255.255.255.0
    set allowaccess ping https ssh fgfm fabric snmp
    set type physical
    next
    end
    config system snmp sysinfo
    set status enable
    set description "AzFW01"
    end
    config system snmp community
    edit 1
    set name "Monitoring"
    config hosts
    edit 1
    set ip 192.168.50.10 255.255.255.255
    next
    end
    next
    end

    ← Back

    Thank you for your response. ✨

    Choose one option(required)

    Show Answer and Explanation

    Answer:
    In the SNMP host 1 settings, set ha-direct enable

    Explanation:
    The configuration in the question shows port2 acting as both the HA management interface and the target interface for SNMP polling. When ha-mgmt-status is enable and an HA management interface specified, that interface will not allow SNMP polling against it, unless ha-direct has been enabled on either the global HA settings or the SNMP host settings.

    Question 7

    You notice that the following session is not being offloaded to hardware like it’s supposed to be. Which configuration change should you make to resolve this?

    ← Back

    Thank you for your response. ✨

    Choose one option(required)

    Show Answer and Explanation

    Answer:
    config vpn ipsec phase1-interface
    edit Dial-Up
    set npu-offload enable
    next
    end

    Explanation:
    The key out from the session table list here is no_ofld_reason: disabled-by-policy. This offload failure reason will only appear when auto-asic-offload is disabled. Re-enabling the setting will resolve the offload failure reason.

    set npu-offload disable on the Phase 1 VPN configuration would create the npu-flag-off offload failure reason. Therefore set npu-offload enable would not resolve the offload failure reason.

    set np-accel-mode none would disable NTurbo and would not produce the disabled-by-policy offload failure reason. Therefore set np-accel-mode basic would not resolve the offload failure reason.

    set cp-accel-mode none would disable IPSA and would not produce the disabled-by-policy offload failure reason. Therefore set cp-accel-mode basic would not resolve the offload failure reason.

    Question 8

    Based on the following session information, which of the following is configured on this FortiGate?

    session info: proto=6 proto_state=02 duration=10 expire=2 timeout=3600 refresh_dir=both flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
    origin-shaper=
    reply-shaper=
    per_ip_shaper=
    class_id=0 ha_id=0 policy_dir=0 tunnel=/ tun_id=0.0.0.0/172.203.132.222 vlan_cos=0/255
    state=log may_dirty f00 f02
    statistic(bytes/packets/allow_err): org=180/3/1 reply=0/0/0 tuples=2
    tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
    orgin->sink: org pre->post, reply pre->post dev=19->4/4->19 gwy=0.0.0.0/0.0.0.0
    hook=pre dir=org act=noop 172.20.0.1:2067->10.251.4.5:139(0.0.0.0:0)
    hook=post dir=reply act=noop 10.251.4.5:139->172.20.0.1:2067(0.0.0.0:0)
    pos/(before,after) 0/(0,0), 0/(0,0)
    misc=0 policy_id=7 pol_uuid_idx=15878 auth_info=0 chk_client_info=0 vd=0
    serial=00003299 tos=ff/ff app_list=0 app=0 url_cat=0
    rpdb_link_id=00000000 ngfwid=n/a
    npu_state=0x000100
    no_ofld_reason: npu-flag-off
    hrx info: valid=0/0, qid=0/0, npuid=0/0, sublink=0/0
    reflect info 0:
    dev=19->4/4->19
    npu_state=0x000400
    npu info: flag=0x91/0x00, offload=8/0, ips_offload=0/0, epid=129/0, ipid=142/0, vlan=0x0017/0x0000
    vlifid=142/0, vtag_in=0x0017/0x0000 in_npu=1/0, out_npu=1/0, fwd_en=0/0, qid=4/0
    total reflect session num: 1

    ← Back

    Thank you for your response. ✨

    Choose one option(required)
    Show Answer and Explanation


    Answer:
    config system setting
    set auxiliary-session enable
    end

    Explanation:
    The key word from the diag sys session list output above is reflect. When auxiliary-session is enabled and created for a session, the session will be tagged as a reflect session.

    None of the other three configurations are indicated by the diagnostic output.

    Question 9

    Which of the routes listed above will be ECMP load-balanced with the route via Proxy-VLAN?

    ← Back

    Thank you for your response. ✨

    Choose one option(required)

    Show Answer and Explanation

    Answer:
    None of the above

    Explanation:
    For ECMP load-balancing to occur with static routes on FortiGate, the routes must have the same Distance (AD) and Priority. The question asks which route will be load-balanced with the first route, which carries an AD of 10 and Priority of 10. None of the listed routes also have an AD of 10 and Priority of 10.

    Question 10

    You configure the following policy-based route to use port1 for your FortiGate’s FortiGuard ISDB update traffic. After analyzing logs and hit count on the configured policy route, you determine that outbound traffic is still using the incorrect interface. What is the best reason as to why this is occurring?

    ← Back

    Thank you for your response. ✨

    Choose one option(required)

    Show Answer and Explanation

    Answer:
    Local-out traffic is not evaluated by policy-based routes

    Explanation:
    The above answer is the best reason the policy-based route is not being used, and will never be used. FortiGate FortiGuard ISDB updates are considered local-out traffic and will never match a PBR. The FortiGate’s local-out settings should be used to customize the outbound interface for this traffic.

    There is no incoming interface set
    An incoming interface on a PBR is not required to match traffic.

    There is not a RIB entry to FortiGuard servers via port1
    This would break traffic matching this PBR, but the PBR will never be matched because local-out traffic is not evaluated by PBRs.

    The firewall is not licensed to download ISDB updates from FortiGuard
    This would stop ISDB updates from succeeding, but not the policy from matching.

  • Fortinet NSE Exam Practice Questions – FortiGate FortiOS 7.6 – Set 1

    These practice questions are original and hand-written as a personal aid while studying for the Fortinet NSE8 exam. Content may or may not be applicable to any specific exam levels, but may be useful for the NSE4, NSE7, NSE8, FCP, or FCSS FortiGate exams. No questions are pulled from actual exams. Content is sourced from and fact-checked via official Fortinet Documentation.

    Question 1

    You have a multicast source that hops through your FortiGate firewalls before reaching the receiver device. The source and receiver devices are not in the same broadcast domain. You notice that multicast packets are being dropped before reaching their final destination. On your FortiGate, you run a packet sniffer specific to your multicast traffic and see the following output. Which configuration below, applied to your FortiGates, will allow traffic to reach its final destination?

    ← Back

    Thank you for your response. ✨

    Choose one option(required)

    Show Answer and Explanation

    Answer:
    config system settings
    set multicast-ttl-notchange enable
    end

    Explanation:
    The screenshot shows captured packets with a TTL of 1 when they pass through the FortiGate. When packets pass through FortiGate, the TTL will decrement by 1, therefore if a packet doesn’t have a TTL of 2 or higher when it reaches the FortiGate, it will be dropped. Multicast packets will sometimes source with a TTL of 1, common with link-local multicast traffic. The multicast-ttl-notchange setting, when enabled, will not decrement the TTL from 1 to 0, which would have caused the packet to be dropped. Assuming the multicast packet continues to flow through routers that do not decrement TTL, or the next hop is the multicast destination itself, the packet will reach the destination.

    None of the other listed options will fix the TTL=1 issue.
    set multicast-routing enable is a pre-requisite for multicast traffic to traverse broadcast domains, but does not fix the TTL issue causing traffic to be dropped.
    set multicast-forward enable allows multicast forwarding, which doesn’t apply since the source and receiver are on different broadcast domains.
    set ses-denied-multicast-traffic disable will have FortiGate not create sessions for denied multicast traffic. This setting is enabled to reduce CPU usage and improve performance, but does not affect the TTL=1 issue.

    Question 2

    You have configured SLAAC for IPv6 addressing to a downstream device, but the device is not receiving an IPv6 address. You have verified all device-level network settings are correct. Your SLAAC-serving interface is configured as follows:
    config system interface
    edit "port2"
    set vdom "root"
    set type physical
    set description "internal"
    set alias "Inside"
    config ipv6
    set ip6-address fd00:c74c:7fe5::4/128
    set ip6-mode static
    set ip6-allowaccess ping
    set ip6-send-adv disable
    set ip6-other-flag enable
    config ip6-prefix-list
    edit fd00:c74c:7fe5:3::/96
    next
    end
    end
    What two configurations need to be made to allow the downstream device to receive an IPv6 address?

    ← Back

    Thank you for your response. ✨

    Choose up to five options(required)

    Show Answer and Explanation

    Answer:
    Replace fd00:c74c:7fe5:3::/96 with fd00:c74c:7fe5:3::/64
    and
    set ip6-send-adv enable

    Explanation:
    You must replace fd00:c74c:7fe5:3::/96 with fd00:c74c:7fe5:3::/64 as SLAAC only works when the prefix is a /64.
    set ip6-send-adv enable is the required line of configuration for SLAAC on FortiGate.

    None of the other options will affect SLAAC.
    set dhcp6-relay-service enable configures the interface to relay DHCPv6 requests from clients to a DHCPv6 server outside of the interface. This is the IPv6 equivalent to the IPv4 DHCP relay configuration, set dhcp-relay-service enable.
    set ip6-mode dhcp configures the interface to act as a DHCPv6 client. this is the IPv6 equivalent to the IPv4 interface addressing configuration, set mode dhcp.

    Question 3

    A firewall policy is matched with the following configurations. What session TTL will be applied to the matching session?
    config firewall policy
    edit 3
    set name "Policy 3"
    set srcintf "any"
    set dstintf "any"
    set action accept
    set srcaddr "all"
    set dstaddr "10.0.0.0/8"
    set schedule "always"
    set service "TCP 433"
    set utm-status enable
    set ssl-ssh-profile "certificate-inspection"
    set application-list "default"
    set logtraffic all
    set session-ttl 1200
    next
    end

    config application list
    edit "default"
    config entries
    edit 1
    set action pass
    set session-ttl 1500
    next
    end
    end

    config firewall service custom
    edit "TCP 433"
    set tcp-portrange 433
    set session-ttl 900
    next
    end

    config system session-ttl
    set default 3600
    end

    ← Back

    Thank you for your response. ✨

    Choose one option(required)

    Show Answer and Explanation

    Answer:
    1500 seconds

    Explanation:
    The configurations shown are the four places you can customize a session’s TTL. The configurations take higher priority in the following order:
    1) Application Control Profile Session TTL
    2) Custom Service Session TTL
    3) Firewall Policy Session TTL
    4) Global Session TTL

    All four configurations apply to the listed firewall policy, including the “default” Application Control Profile, which has a custom session TTL set to 1500 seconds.

    Question 4

    An IPsec tunnel connects two FortiGate firewalls. You are trying to bring up an OSPF adjacency between the firewalls, but it’s showing the following state and won’t progress past it. What configuration change should you make to bring the adjacency up?

    On FortiGate-A:
    config router ospf
    set router-id 10.100.1.1
    config area
    edit 0.0.0.0
    next
    end
    config ospf-interface
    edit "Hub-and-Spoke"
    set interface "Hub-and-Spoke"
    set authentication message-digest
    set keychain "ospf"
    set dead-interval 40
    set hello-interval 10
    set mtu 1400
    set network-type point-to-multipoint
    next
    end
    config network
    edit 1
    set prefix 10.100.1.1 255.255.255.255
    next
    edit 2
    set prefix 172.20.0.0 255.255.255.252
    next
    end

    On FortiGate-B:
    config router ospf
    set router-id 10.200.1.1
    config area
    edit 0.0.0.0
    next
    end
    config ospf-interface
    edit "Hub-and-Spoke"
    set interface "Hub-and-Spoke"
    set authentication message-digest
    set keychain "ospf"
    set dead-interval 40
    set hello-interval 10
    set mtu-ignore enable
    set network-type point-to-point
    next
    end
    config network
    edit 1
    set prefix 10.200.1.1 255.255.255.255
    next
    edit 2
    set prefix 172.20.0.0 255.255.255.252
    next
    end

    ← Back

    Thank you for your response. ✨

    Choose up to six options(required)

    Show Answer and Explanation

    Answer:
    On FortiGate-A, set mtu-ignore enable

    Explanation:
    OSPF coming up to the Exchange start (ExStart) state, but not moving further, is a classic MTU mismatch problem. By default, OSPF routers connected by an IPsec tunnel will have an MTU of 1420 on both IPsec interfaces. In the question config, FortiGate-A’s OSPF interface has a custom MTU of 1400 set, mismatching with FortiGate-B’s default 1420.
    On FortiGate-A, the set mtu-ignore enable configuration will tell OSPF to ignore the MTU mismatch and bring the OSPF adjacency up anyways.

    None of the other answers will bring the OSPF adjacency up.
    On FortiGate-A, set network-type point-to-point will not bring up the adjacency as a point-to-multipoint and point-to-point interface are compatible.
    On FortiGate-A, set mtu 1500 will not bring up the adjacency as the FortiGate-A MTU will still not match the default IPsec interface MTU on FortiGate-B of 1420.
    On FortiGate-B, edit1, set prefix 10.100.1.1 255.255.255.255 will not bring up the adjacency, it will just change the advertised network to FortiGate-A.

    Question 5

    Which of the following networks will be advertised to BGP peer, 10.100.1.1?

    On AzFW02 (root):
    config router bgp
    set as 100
    set ebgp-multipath enable
    config neighbor
    edit "10.100.1.1"
    set ebgp-enforce-multihop enable
    set soft-reconfiguration enable
    set interface "BGP Loopback"
    set remote-as 100
    set update-source "BGP Loopback"
    next
    end
    config network
    edit 1
    set prefix 10.251.0.0 255.255.0.0
    next
    edit 2
    set prefix 10.200.1.1 255.255.255.255
    next
    edit 3
    set prefix 55.55.55.55 255.255.255.255
    next
    end
    config redistribute "connected"
    end
    config redistribute "static"
    set status enable
    end
    end

    ← Back

    Thank you for your response. ✨

    Choose up to five options(required)

    Show Answer and Explanation

    Answer:
    10.251.0.0/16
    10.200.1.1/32
    172.20.0.1/32

    Explanation:
    10.251.0.0/16 and 10.200.1.1/32 will be advertised because they are configured within the BGP networks list and there are routes to both subnets in AzFW02’s route table.
    172.20.0.1/32 will be advertised because it is a static type route and BGP is configured to redistribute static routes. The subnet is also present in AzFW02’s route table.
    10.101.1.0/24 will not be advertised as BGP is not configured to redistribute connected routes nor is the subnet configured within the BGP networks list.
    55.55.55.55/32 is configured within the BGP networks list, but there is not a route to the subnet within AzFW02’s route table.


    Question 6

    A FortiGate is seeing much higher CPU usage than usual after a junior admin made multiple configuration changes, leading to performance throttling. Which changes, if reverted, should improve steady-state performance conditions?

    ← Back

    Thank you for your response. ✨

    Choose one option(required)

    Show Answer and Explanation

    Answer:
    config system global
    set check-protocol-header strict
    end

    config system global
    set tcp-timewait-timer 0
    end

    Explanation:
    Setting check-protocol-header to strict disables all hardware offloading, increasing CPU usage.
    Setting the tcp-timewait-timer to 0 sets an unlimited TCP time wait after TCP handshakes have closed, leaving all TCP sessions in the session table indefinitely, increasing CPU usage.

    The IPS setting set fail-open enable will allow flow-based sessions to continue to flow while the FortiGate is in memory conserve mode. This will not directly lead to high CPU usage in steady-state.
    The IPS setting set socket-size 512 will allow for additional data to be passed by the kernel to the IPS engine each time the engine samples packets. Raising this value from the previous value of 256 may lead to high memory issue but does not directly impact CPU usage in stead-state.

    Question 7

    You have two FortiGates configured in FGCP HA mode. Your primary FortiGate has the following config:
    config system ha
    set group-name "HA"
    set mode a-p
    set password ENC [REDACTED PASSWORD HASH]
    set hbdev "port2" 0
    set override enable
    set session-pickup enable
    set priority 255
    end
    During a routine failover test from your active to passive unit, you notice that the following traffic flow takes a long time to reconnect after the failover.

    What can be configured in your HA settings to speed up recovery of the traffic flow?

    ← Back

    Thank you for your response. ✨

    Choose one option(required)

    Show Answer and Explanation

    Answer:
    set session-pickup-connectionless enable

    Explanation:
    set session-pickup-connectionless enable enables session synchronization of UDP and ICMP sessions, allowing for the maintenance of the UDP (proto=6) session seen in the diagnostic output above.
    set backup-hbdev port1 is a setting that assigns port1 to be the backup heartbeat interface. This will not improve session failover times.
    set gratuitous-arps disable stops the sending of gratuitous ARP packets during HA failover events. Gratuitous ARP assists in the updating of connected devices’ MAC forwarding tables during failover. Disabling this setting will not improve session failover times, it will likely extend them.
    set sync-config disable will stop the automated synchronization of configurations between HA devices. This will not improve session failover times.

    Question 8

    You log into your FortiGate device and navigate to the Automation page to configure an Automation Stitch, but are presented with this message:

    Which of the following should be set on the FortiGate you’re currently logged into in order to allow you to create an Automation Stitch?

    ← Back

    Thank you for your response. ✨

    Choose one option(required)
    Show Answer and Explanation


    Answer:
    config system setting
    set auxiliary-session enable
    end

    Explanation:
    The key word from the diag sys session list output above is reflect. When auxiliary-session is enabled and created for a session, the session will be tagged as a reflect session.

    None of the other three configurations are indicated by the diagnostic output.

    Question 9

    Assuming full functionality and that these options are being directly compared, which of the following routes will be used for Gmail traffic? For reference, Google-Gmail’s internet service ID is 65646.

    ← Back

    Thank you for your response. ✨

    Choose one option(required)

    Show Answer and Explanation

    Answer:
    config router policy
    edit 2
    set output-device “port2”
    set internet-service-id 65646
    next
    end

    Explanation:
    All three routes are valid. The listed route types are evaluated in the following order:
    Policy-Based Routes > ISDB Routes > SD-WAN Routes
    config router policy is a policy-based route configuration, therefore it is the right answer.
    config system sdwan is an SD-WAN route rule configuration, less preferred than the policy-based route.
    config router static is an ISDB route configuration, less preferred than the policy-based route.

    Question 10

    Which of the following CLI configurations would you find for this VPN tunnel under config vpn ipsec phase1-interface?

    ← Back

    Thank you for your response. ✨

    Choose one option(required)

    Show Answer and Explanation

    Answer:
    set childless-ike enable

    Explanation:
    We know that childless-ike is enabled because of the presence of PQC-KEM (IKE): yes. childless-ike is a required configuration for IKE PQC.

    We know that set mode aggressive is disabled because of the presence of version: 2. Setting the phase 1 mode is only applicable when IKE is set to version 1.
    We know that set nattraversal is enabled because of the presence of peer within the nat: me peer line as well as transport: UDP. If NAT-T was disabled, we would not be able to traverse NAT on the peer end, and transport would not take place over UDP. We can additionally see port 4500 in use, associated with NAT-T.
    We know that set auto-discovery-receiver is not enabled and is actually disabled because of the line auto-discovery: 1 sender. This tells us that only auto-discovery-sender is enabled.
    We know that set interface “Hub-and-Spoke” is not set because of the line interface: port1 4. This tells us that port1 is the interface binding for this tunnel.

  • NSE8 – Blog 19 – No longer slowing down

    It’s been a few weeks since the last post. I imagine this will continue to be a theme. I’m finding myself tired enough and so low on time by the time I finish studying on Sundays that I don’t prioritize making these posts. With that disclaimed, here’s the log from the past three weeks:

    As you can see, since the last post, I finished up the Authentication phase (phase 4/6) and started on what I call FortiManager, FortiAnalyzer, and Security Fabric (FMG/FAZ/SecFab). Both of these sections are a little shorter than some of the other big sections like Routing. In one case because topic weight is lesser (only 14% for authentication), and in the other because I’m already using FMG and FAZ on a daily basis, plus have a fair amount of experience with Security Fabric and Automation. At this time I’m just making sure I’m fully reviewed on the topics and have labbed all of the appropriate features. There are some topics, like FMG and FAZ HA, that I don’t have practical experience with at all.

    Another short update this time. I’m continuing to put in my hours each week and taking the subjects and subtopics one at a time, not worrying too much if I don’t cover something 100% or don’t get a chance to lab out every single situation. At this point I’m just trying to reach a 75% confidence level with every topic that’s listed in the NSE8 pre-release notes. Some topics I’m already at 100% confidence because work with them every day. Others I will come back to during the review phase (phase 6/6).

  • NSE8 – Blog 18 – A marathon, not a sprint

    A marathon, not a sprint. That’s the theme for this week. Between my skip day last week and my short days yesterday and today, I’m down quite a few hours below my 18-20 hour weekly target. I’m telling myself that’s okay, because it is. I’m not always going to have perfect week. This upcoming weekend I will be going on a trip and likely won’t be able to do much studying at all. Again, I’m telling myself this is okay because I’m honestly nervous about taking my first real “break” from studying since I started 3 or 4 months ago.

    In one of my upcoming posts, I will include more details about the Authentication phase of my study plan I’ve been working through these past couple of weeks.

  • NSE8 – Blog 17 – Tired

    Very short post this week. One day late and only for the sake of consistency. I’m very tired and as you can see from my hours above, have been slacking a little bit. Between personal days and a bit of illness, it’s one of those week’s I’ve simply had to get through. I continue to repeat in my head the advice I’ve received – to continue putting in the work each day, each week, and not worry about perfection or deadlines. The learning and understanding will continue to come with time.

  • NSE8 – Blog 16 – HOLs are Awesome

    Not a bad week at all. Not at consistent as previous weeks and I’m a bit under hours but I just want to start this by emphasizing how useful the FDN Hands on Labs (HOL) are. I spent a good portion of the week going through the SD-WAN HOL. Need I repeat from last week’s blog post that the HOL guide is over 200 pages long? It’s 7 labs that cover everything from simple hub-and-spoke SD-WAN from scratch with Jinja Orchestrator to ADVPN 2.0 and ICMP embedded SLAs.

    Quick update on lab costs as well – last month we got close to $50 after the FGT licensing free trials expired and before I got a chance to apply the eval licenses. This month we’re looking at something closer to $40.

    No other big updates other than starting the Authentication and User Access Phase (Phase 4) today and a bit of trouble getting access the FortiAuthenticator VM in my lab. Hoping to figure that out tomorrow.

  • NSE8 – Blog 15 – SD-WAN Strikes Back

    This week I spent with my foot in my mouth after last week’s post included me going on and on about how I didn’t know what to fill the next 2 weeks with to finish our the SD-WAN phase. Turns out there’s a lot more, and it was all under the SD-WAN Architecture section of the pre-release notes topic outline.

    It turns out these 4 topics were a weeks worth of deep notes (and a little bit of labbing). From there, this weekend I began the SD-WAN 7.6 Hands-on Lab from the Fortinet Developer Network and it’s probably going to fill the next week on its own. Let’s just say the lab documentation is somewhere around 200 pages. I spent 4 hours on the first of 6-7 labs included in the HOL, although the first 2 hours were wasted on me getting stuck because of a simple typo while importing the Fortinet-provided Jinja template.

    I did also spend some time this past week re-labbing ADVPN 2.0, just because I almost know for a fact it will be on the exam (it’s right there in the pre-release notes and it’s just a big offering for Fortinet in general). I still don’t feel perfectly comfortable, so I imagine I’ll do this at least 2 more times before I sit the exam.

    In terms of timing I think I will probably do at least another 1.5 weeks with SD-WAN before a quick 2-4 day review of SD-WAN and Traffic Shaping. Then we’re moving right along to Authentication and Access Control and I’ll be excited to get the FortiAuthenticator VM spun up and poke around for the first time.

  • Traffic Shaping on FortiGate – Maximum vs. Guaranteed Bandwidth Explained

    FortiGate Traffic Shaping – Guaranteed vs Maximum Bandwidth

    Maximum Bandwidth is simple:

    • Sets a limit to the amount of bandwidth that can be used.
      • In a Traffic Shaping Profile, this is a percentage of the outbandwidth.
      • In a Traffic Shaper, this is a rate (eg. 40Mbps). 
    • If you set the max to 50% of a 100Mbps WAN link, bandwidth is capped at 50Mbps even if the entire pipe is idle. Excess gets dropped (policing) or queued (queueing). 

    Guaranteed Bandwidth is more complex and less straightforward to understand. We can start by visualizing our egress interface as a pipe. We set our WAN link to 100Mbps, telling the FortiGate “this is the total capacity you have to work with.”

    config system interface
    edit port2
    set outbandwidth 100000
    next
    end

    First, guaranteed bandwidth is a Reservation. When congestion is happening and multiple classes are competing, the FortiGate will always honor each class’s guaranteed amount before giving leftovers to anyone. 

    • If Class A has 30% guaranteed and Class B has 20% guaranteed, and the pipe is saturated, Class A will get at least 30Mbps and Class B will get at least 20Mbps, regardless of priority. The guaranteed bandwidth is reserved and cannot be overridden.

    Second, guaranteed bandwidth determines who gets the leftovers. After all guaranteed reservations are fulfilled, there is bandwidth leftover. The remaining bandwidth is distributed based on priority. Higher priority classes get bandwidth first. If two classes share the same priority, the remaining bandwidth is split proportionally to their guaranteed bandwidth ratio. 

    Let’s do an example with the same 100Mbps pipe and three classes:

    • VoIP: guaranteed 20%, max 100%, priority High
    • Web: guaranteed 30%, max 80%, priority Medium
    • General: guaranteed 10%, max 100%, priority Low

    When the pipe is NOT congested, for example only 40Mbps is used, nobody cares about priorities or guarantees. Each class just uses what it needs, up to its maximum. 

    When the pipe IS congested, for example 150Mbps of demand hitting a 100Mbps pipe, it matters. 

    1. Honor the guarantees: VoIP gets 20Mbps, Web gets 30Mbps, General gets 10Mbps
    2. 40Mbps remains. VoIP (High priority) gets first dibs on leftovers, up to its maximum of 100Mbps. VoIP could take all remaining 40Mbps if it wanted. Let’s say it only needs 25Mbps more. 
    3. 15Mbps remains. Web (Medium priority) gets next dibs on leftovers, up to its maximum of 80Mbps. Web could take all remaining 15Mbps if it wanted. Let’s say it only needs 5Mbps more.
    4. 10Mbps remains. General (Low priority) gets next dibs on leftovers, up to its maximum of 100Mbps. Let’s say it needs 20 Mbps more. It takes the remaining 10Mbps and another 10Mbps of its traffic is dropped or queued.  

    Summary

    Guaranteed bandwidth protects you during congestion, regardless of priority. Priority determines who gets dibs on the leftover bandwidth. 

  • NSE8 – Blog 14 – SD-WAN

    This week has been all SD-WAN. And I by all SD-WAN I mean SD-WAN plus a bunch of other shit that relates to SD-WAN. The pre-release notes aren’t incredibly specific, but here are the topics they list:

    • SD-WAN Architecture
      • Application performance
      • Multi-datacenter
      • Redundant connectivity
      • Work from anywhere
    • SASE
      • Prepping for SPA
      • SD-WAN On-Ramp
      • Secure Private Access
    • Routing
      • SD-WAN Routing
    • VPN
      • SD-WAN

    Based on this list, I worked up the following sub-topics to cover within my Phase 3 section:

    Unfortunately it’s the end of day 8 and I do believe I’ve covered 80-90% of this. I do work with SD-WAN a lot in my day-to-day work environment but I’m a bit thrown off by the difference between my initial estimate and the current time worked. I had a similar feeling after finishing VPNs and Overlays. Things are just going a lot quicker than they did for my Phase 1 (Routing). Given that I went so in-depth for routing and covered many topics that I had not gone deep on before (OSPF, VRFs, Multicast, etc.), this makes some sense – but it’s still a weird feeling to almost be finished with what is supposed to be a 50 hour topic is closer to 20-25 hours. I don’t have a real solution for this at the moment other than telling myself I’ll come back to both VPNs and SD-WAN during my review phase but it doesn’t stop the worry that I may be missing chunks of content or simply not spending enough hours in the lab on these subtopics. The one thing I can do now is hope that there is updated topic documentation that gets released when (or before) the July 15th update – when NSE8 is official released.

  • NSE8 – Blog 13 – Some changes to NSE8

    Before we get into the NSE8 changes, as always, I’ll start with the time tracker. This week we finished up IPsec and Overlay VPNs and just today began SD-WAN. VPNs was a short phase 2 (of a total 7 phases I have planned) – roughly 3 weeks compared to Phase 1 (Routing) coming in at 6 weeks.

    NSE8 Changes

    The big change: the NSE8 Core module is an in-person practical exam. I know from my first brief start with FCX that the expert level exam was fully remote in terms of the proctored written and practical exams. I did expect it to stay remote but after this release we can see it is in fact required to be taken in-person. There are not yet details explaining where the exam is taken in terms of local (proctored via a standard local testing center or only at Fortinet offices), however I imagine this will come soon.

    The second big update is something I had previous asked our AM about: whether my FCS and FCSS certifications would qualify me for the NSE8 prerequisites. The answer is yes!

    Going off of this I’m going to go ahead and cross all 3 pre-reqs off my checklist:

    I will of course confirm this with our AM as well, just in case. However, for now it just means I don’t have to spend the time re-taking 2-3 additional exams, which is nice.

    The final update is the change in date for the first day to take the NSE8, July 15th. I imagine we’ll see at least 1-2 more big updates like this for the NSE8 before July 15th, so I will continue to keep a very close eye on anything released from Fortinet as well as updates to the NSE8 Pre-Release Guide.

    I don’t have any major study updates this week I’ll leave it at that. Thanks for reading and best of luck studying for anybody following along!