Tag: practice questions

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).

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.