View all questions & answers for the NSE 4 - FortiOS 7.6 Administrator Exam Materials exam
NSE 4 - FortiOS 7.6 Administrator Exam Materials - Question #45 Discussion
Community Explanations & Comments (6)
javaughn Bryan
1 year ago
Selected: A, C
This setup provides IP-level connectivity in tunnel mode and allows you to configure hub-and-spoke
topologies with FortiGate devices as both the SSL VPN hub and spokes. This can be useful to avoid issues caused by intermediate devices, such as:
ESP packets being blocked
UDP ports 500 or 4500 being blocked
Fragments being dropped, causing IKE negotiation that uses large certificates to fail if the peer does not support IKE fragmentation
topologies with FortiGate devices as both the SSL VPN hub and spokes. This can be useful to avoid issues caused by intermediate devices, such as:
ESP packets being blocked
UDP ports 500 or 4500 being blocked
Fragments being dropped, causing IKE negotiation that uses large certificates to fail if the peer does not support IKE fragmentation
Goncalo Pereira
1 year ago
Selected: A, B
corret on
Miguel
10 months ago
Selected: A, B
Foti 7.4 is C -->You can configure a hub-and-spoke topology with SSL VPN tunnels to bypass blocked UDP ports. but in forti 7.6 is B.
Miguel
10 months ago
Selected: A, B
A — Use SSL VPN tunnel mode:
Intermediate devices often block IPsec’s ESP (IP proto 50) and/or the UDP 500/4500 ports used by IKE/NAT-T. SSL VPN tunnel mode encapsulates all traffic over HTTPS/TCP 443, which almost always passes through middleboxes and proxies. That sidesteps the ESP/UDP filtering entirely, letting users connect even when IPsec is blocked.
B — Enable IKE fragmentation:
When peers exchange large certificates or many proposals, IKE messages can exceed the path MTU. Some middleboxes mishandle or drop IP-fragmented packets, breaking negotiation. IKE fragmentation splits the IKE payload itself (not the IP packet), so the exchange succeeds without relying on IP fragmentation. This directly addresses certificate-related failures caused by intermediate devices.
Why not C/D?
C (SSL hub-and-spoke) is a topology choice; the real fix is already in A (using SSL/443).
D (use IKEv2) doesn’t solve ESP/UDP filtering by itself; if ports/protocols are blocked, the tunnel still fails.
Intermediate devices often block IPsec’s ESP (IP proto 50) and/or the UDP 500/4500 ports used by IKE/NAT-T. SSL VPN tunnel mode encapsulates all traffic over HTTPS/TCP 443, which almost always passes through middleboxes and proxies. That sidesteps the ESP/UDP filtering entirely, letting users connect even when IPsec is blocked.
B — Enable IKE fragmentation:
When peers exchange large certificates or many proposals, IKE messages can exceed the path MTU. Some middleboxes mishandle or drop IP-fragmented packets, breaking negotiation. IKE fragmentation splits the IKE payload itself (not the IP packet), so the exchange succeeds without relying on IP fragmentation. This directly addresses certificate-related failures caused by intermediate devices.
Why not C/D?
C (SSL hub-and-spoke) is a topology choice; the real fix is already in A (using SSL/443).
D (use IKEv2) doesn’t solve ESP/UDP filtering by itself; if ports/protocols are blocked, the tunnel still fails.
Anonymous User
6 months ago
Selected: A, B
A,B
Ahmed El Hasseen El Tom El Shaikh Berair
3 months ago
Selected: A, B
45
You are encountering connectivity problems caused by intermediate devices blocking IPsec traffic. In which two ways can you effectively resolve the problem? (Choose two answers)
Brave-Dump Community Votes