Fortinet Enterprise Firewall 7.6 FCSS_EFW_AD-7.6 IKEv2 Child SAs Selectors Routing Practice Test

Practice Exams:

View All

Fortinet Enterprise Firewall 7.6 FCSS_EFW_AD-7.6 IKEv2 Child SAs Selectors Routing Practice Test

This practice test focuses on ikev2 child sas selectors routing and troubleshooting through original applied scenarios aligned to the final published Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator 7.6 blueprint. It is intended for study and does not reproduce live exam content. For broader exam preparation, review the Fortinet FCSS_EFW_AD-7.6 Exam Dumps page.

Question 1

For a FortiGate/FortiManager/FortiAnalyzer 7.6 deployment at Blue Yonder Airlines, which option correctly addresses the need to establish child SAs for only the protected local and remote networks? Choose the smallest targeted change. Only one site is affected; peer sites are healthy.

Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing

Correct answer: C

Explanation

Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This directly addresses the stated requirement.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, configure compatible phase-2 or child-SA traffic selectors and proposals on both peers. Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly.

Question 2

Trey Research has verified basic IP reachability. The remaining requirement is to route enterprise traffic through a route-based IPsec tunnel. Which action should the team take? The answer must address the stated cause rather than a different feature. The change must be validated on a pilot device before broader rollout.

Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers

Correct answer: D

Explanation

An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.
Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This directly addresses the stated requirement.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic. Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic.

Question 3

At Apex Retail, the Fortinet administrator must troubleshoot a tunnel that is up but carries no application traffic. Which action best addresses the requirement? Preserve the existing design unless the requirement says otherwise. Existing production IP addressing must remain unchanged.

Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic

Correct answer: D

Explanation

Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This directly addresses the stated requirement.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers. An established SA does not guarantee that the intended traffic is routed and permitted through it.

Question 4

During an enterprise firewall change at Proseware Media, the team needs to avoid accidentally source-NATing private-to-private VPN traffic. What should it do? Prefer a change that is reversible and easy to verify. The resulting configuration must remain centrally auditable.

Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic

Correct answer: C

Explanation

An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.
Unexpected NAT can break selector matching and remote return routing. This directly addresses the stated requirement.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required. Unexpected NAT can break selector matching and remote return routing.

Question 5

A production review at City Power & Light identifies this requirement: identify why child SAs repeatedly renegotiate under load. Which Fortinet action is most appropriate? The team needs an auditable result. A known-good rollback point is available before the change.

Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic

Correct answer: B

Explanation

Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This directly addresses the stated requirement.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.

Learning point: For this Fortinet NSE 7 – Enterprise Firewall 7.6 Administrator scenario, inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing. Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes.

Question 6

While troubleshooting at VanArsdel, the NOC engineer needs to establish child SAs for only the protected local and remote networks. What is the best next step? Use normal enterprise Fortinet administration practice. The design must preserve the current segmentation boundaries.

Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing

Correct answer: A

Explanation

Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This directly addresses the stated requirement.
Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.

Question 7

Woodgrove Bank is standardizing a FortiOS 7.6 enterprise deployment. Which approach should it use to route enterprise traffic through a route-based IPsec tunnel? Assume the platform versions are compatible with the feature. The team is not allowed to disable the security feature globally.

Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers

Correct answer: A

Explanation

Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This directly addresses the stated requirement.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.
Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.

Question 8

A change ticket for Alpine Ski House states that administrators must troubleshoot a tunnel that is up but carries no application traffic. Which choice is correct? No unrelated control should be weakened. The symptom appeared immediately after a planned configuration change.

Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers

Correct answer: A

Explanation

An established SA does not guarantee that the intended traffic is routed and permitted through it. This directly addresses the stated requirement.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.

Question 9

The security team at Datum Corporation wants to avoid accidentally source-NATing private-to-private VPN traffic. Which configuration or operational action most directly satisfies that goal? The team will validate the result immediately after the change. Logs from the affected traffic are available for verification.

Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers

Correct answer: B

Explanation

Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.
Unexpected NAT can break selector matching and remote return routing. This directly addresses the stated requirement.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.

Question 10

An incident at Contoso Finance requires the network operations engineer to identify why child SAs repeatedly renegotiate under load. What should be done first? The change is taking place in a controlled maintenance window. The equivalent configuration works correctly at a separate site.

Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required

Correct answer: D

Explanation

Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This directly addresses the stated requirement.
Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.

Question 11

For a FortiGate/FortiManager/FortiAnalyzer 7.6 deployment at Litware Logistics, which option correctly addresses the need to establish child SAs for only the protected local and remote networks? Choose the smallest targeted change. The change must be reversible within the same maintenance window.

Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers

Correct answer: E

Explanation

Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This directly addresses the stated requirement.

Question 12

Wide World Importers has verified basic IP reachability. The remaining requirement is to route enterprise traffic through a route-based IPsec tunnel. Which action should the team take? The answer must address the stated cause rather than a different feature. The device is already synchronized with its central-management database.

Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing

Correct answer: D

Explanation

Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.
Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This directly addresses the stated requirement.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.

Question 13

At Relecloud, the enterprise firewall engineer must troubleshoot a tunnel that is up but carries no application traffic. Which action best addresses the requirement? Preserve the existing design unless the requirement says otherwise. The current routing table contains the expected connected networks.

Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required

Correct answer: A

Explanation

An established SA does not guarantee that the intended traffic is routed and permitted through it. This directly addresses the stated requirement.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.

Question 14

During an enterprise firewall change at Adventure Works, the team needs to avoid accidentally source-NATing private-to-private VPN traffic. What should it do? Prefer a change that is reversible and easy to verify. Basic IP reachability to the remote endpoint has already been verified.

Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers

Correct answer: C

Explanation

Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.
Unexpected NAT can break selector matching and remote return routing. This directly addresses the stated requirement.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.

Question 15

A production review at Fourth Coffee identifies this requirement: identify why child SAs repeatedly renegotiate under load. Which Fortinet action is most appropriate? The team needs an auditable result. Hardware replacement is outside the approved change scope.

Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic

Correct answer: A

Explanation

Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This directly addresses the stated requirement.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.
Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.

Question 16

While troubleshooting at Coho Winery, the network operations engineer needs to establish child SAs for only the protected local and remote networks. What is the best next step? Use normal enterprise Fortinet administration practice. The requirement applies only to one policy, peer, or managed device group.

Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers

Correct answer: E

Explanation

Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This directly addresses the stated requirement.

Question 17

Fabrikam Manufacturing is standardizing a FortiOS 7.6 enterprise deployment. Which approach should it use to route enterprise traffic through a route-based IPsec tunnel? Assume the platform versions are compatible with the feature. The team must avoid broadening administrative trust or permissions.

Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers

Correct answer: C

Explanation

Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.
Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This directly addresses the stated requirement.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.

Question 18

A change ticket for Wingtip Energy states that administrators must troubleshoot a tunnel that is up but carries no application traffic. Which choice is correct? No unrelated control should be weakened. The design must preserve existing centralized logging and telemetry.

Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers

Correct answer: C

Explanation

Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This directly addresses the stated requirement.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.

Question 19

The security team at Lucerne Publishing wants to avoid accidentally source-NATing private-to-private VPN traffic. Which configuration or operational action most directly satisfies that goal? The team will validate the result immediately after the change. Production subnets cannot be renumbered as part of this change.

Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing

Correct answer: A

Explanation

Unexpected NAT can break selector matching and remote return routing. This directly addresses the stated requirement.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.

Question 20

An incident at Bellows College requires the network security architect to identify why child SAs repeatedly renegotiate under load. What should be done first? The change is taking place in a controlled maintenance window. A maintenance window is open, but service interruption must be minimized.

Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers

Correct answer: D

Explanation

Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This directly addresses the stated requirement.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.

Question 21

For a FortiGate/FortiManager/FortiAnalyzer 7.6 deployment at Tailspin Toys, which option correctly addresses the need to establish child SAs for only the protected local and remote networks? Choose the smallest targeted change. The team must preserve existing certificate-trust relationships unless the requirement explicitly changes them.

Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers

Correct answer: C

Explanation

Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This directly addresses the stated requirement.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to establish child SAs for only the protected local and remote networks.

Question 22

Humongous Insurance has verified basic IP reachability. The remaining requirement is to route enterprise traffic through a route-based IPsec tunnel. Which action should the team take? The answer must address the stated cause rather than a different feature. The change will be reviewed later using the configuration and event audit trail.

Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing

Correct answer: A

Explanation

Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This directly addresses the stated requirement.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.
Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to route enterprise traffic through a route-based IPsec tunnel.

Question 23

At Margie Travel, the security infrastructure engineer must troubleshoot a tunnel that is up but carries no application traffic. Which action best addresses the requirement? Preserve the existing design unless the requirement says otherwise. The chosen approach must continue to work as additional branch sites are added.

Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers

Correct answer: E

Explanation

Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to troubleshoot a tunnel that is up but carries no application traffic.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This directly addresses the stated requirement.

Question 24

During an enterprise firewall change at Northwind Health, the team needs to avoid accidentally source-NATing private-to-private VPN traffic. What should it do? Prefer a change that is reversible and easy to verify. A second engineer will verify the result using independent operational evidence.

Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic

Correct answer: C

Explanation

Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.
Unexpected NAT can break selector matching and remote return routing. This directly addresses the stated requirement.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to avoid accidentally source-NATing private-to-private VPN traffic.

Question 25

A production review at Blue Yonder Airlines identifies this requirement: identify why child SAs repeatedly renegotiate under load. Which Fortinet action is most appropriate? The team needs an auditable result. The team requires a deterministic rollback path if validation fails.

Use policy and NAT settings that preserve original source addressing for the protected VPN flow unless translation is explicitly required
Verify routes, firewall policies, selectors, NAT behavior, return path, and packet counters on both peers
Configure compatible phase-2 or child-SA traffic selectors and proposals on both peers
Inspect IKE and IPsec logs, lifetimes, replay or proposal errors, DPD, and peer-side diagnostics before changing routing
Use an IPsec tunnel interface with appropriate routes or dynamic routing and policies permitting the protected traffic

Correct answer: D

Explanation

Unexpected NAT can break selector matching and remote return routing. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.
An established SA does not guarantee that the intended traffic is routed and permitted through it. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.
Mismatched selectors or child-SA proposals prevent the protected traffic SAs from forming correctly. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.
Repeated rekey or teardown behavior should be tied to SA and negotiation evidence rather than unrelated routing changes. This directly addresses the stated requirement.
Route-based VPNs rely on normal routing and firewall policy to select and permit tunnel traffic. This can be correct in another enterprise firewall scenario, but it does not directly satisfy the requirement to identify why child SAs repeatedly renegotiate under load.

Related posts: