FortiExpert logoFortiExpert
Sign in
← Back to knowledge base
mediumVPN (IPsec / SSL)

Troubleshooting SSL VPN access to spoke LANs through hub IPsec tunnels

Confirmed 8/3/2026

Problem

An SSL VPN client connected to an FGT60E hub cannot directly reach a LAN behind an FGT60E spoke over IPsec. The client can reach a PC on the hub LAN by RDP, and that PC can then reach the spoke LAN, but a direct RDP connection from the SSL VPN client to the spoke LAN fails.

Symptoms

The topology is `[PC]--<Internet SSLVPN>----[FGT60E@HUB]----<IPsecVPN>----[FGT60E@SPOKE1]----[LAN@SPOKE1]`, with another IPsec tunnel from the hub to `[FGT60E@SPOKE2]----[LAN@SPOKE2]`. The SSL VPN client receives an address by DHCP. A traceroute for the failed direct connection reaches the hub DMZ interface as the next hop and then fails. Existing policies permit traffic from `ssl.root` to `spoke1` and `spoke2`, with NAT enabled. The hub has `dmz` at `192.168.1.254 255.255.255.0` and `internal` at `172.16.1.254 255.255.255.0`.

Environment

FGT60E devices in a hub-and-spoke design using SSL VPN on the hub and route-based IPsec tunnels to two spokes. Reported hub configuration: ```config system interface edit "wan1" set mode pppoe set role wan next edit "dmz" set ip 192.168.1.254 255.255.255.0 next edit "internal" set ip 172.16.1.254 255.255.255.0 next ``` ```config firewall policy edit 1 set srcintf "ssl.root" set dstintf "spoke1" set srcaddr "all" set dstaddr "LAN@SPOKE1" set action accept set schedule "always" set service "ALL" set groups "SSL-VPN-GRP" set nat enable next edit 2 set srcintf "ssl.root" set dstintf "spoke2" set srcaddr "all" set dstaddr "LAN@SPOKE2" set action accept set schedule "always" set service "ALL" set groups "SSL-VPN-GRP" set nat enable next ``` ```config router static edit 1 set dst [IP address] set device "spoke1" next edit 2 set dst [IP address] set device "spoke2" next ```

Root Cause

Two configuration areas must be considered. First, NAT can cause the SSL VPN traffic source to fall outside the IPsec Phase 2 selectors or use an unsuitable tunnel-interface address. The supported approaches are either to route the SSL VPN client subnet through IPsec without NAT and include it in the Phase 2 selectors, or to source-NAT it to an address already covered by the selectors, such as an address in the local LAN range. In the reported case, the confirmed resolution was changing the hub DMZ interface type from `physical` to `switch`; the precise reason the physical-interface type caused the observed routing behavior was not established.

Solution

  1. Confirm that spoke1 and spoke2 are the intended IPsec tunnel interfaces and determine whether IP addresses are configured on those tunnel interfaces.

  2. Verify that the hub has firewall policies from ssl.root to each spoke IPsec interface and that the destination address objects represent the correct spoke LANs. The reported policies use SSL-VPN-GRP, schedule always, service ALL, and have NAT enabled.

  3. Choose one consistent method for carrying the SSL VPN client traffic over IPsec:

    • Routed without NAT: Disable NAT on the SSL VPN-to-IPsec policies, add the SSL VPN client address range configured in SSL VPN settings and/or individual portals to the local Phase 2 selectors, and ensure each spoke has a return route for that subnet. The spoke must also allow the SSL VPN subnet in policy and include it in its Phase 2 selectors.
    • Source NAT: Keep NAT enabled but translate SSL VPN traffic to an address covered by the existing Phase 2 selectors, such as an address in the hub local LAN range. Do not rely on an interface IP if that address is outside the selectors.

  4. Review routing for the spoke LAN prefixes. Each destination must resolve through the appropriate tunnel interface, as represented by the existing static-route structure:

edit 1
set dst [IP address]
set device "spoke1"
next
edit 2
set dst [IP address]
set device "spoke2"
next

  1. Because traceroute selected the DMZ interface and the reported incident was resolved by changing its type, change the hub DMZ interface from type physical to type switch. No exact CLI command or GUI path for this change was provided in the source.

  2. Retest direct access from the SSL VPN client to the PCs in LAN@SPOKE1 and LAN@SPOKE2.

Verification

Connect the PC to SSL VPN through the Internet and confirm that it receives an address from the configured SSL VPN pool. Run traceroute and RDP directly from the SSL VPN client to a PC in LAN@SPOKE1, and repeat for LAN@SPOKE2. The route should use the applicable IPsec tunnel rather than terminating through the DMZ interface. Also verify that return traffic matches the selected design: either the SSL VPN client subnet is routed and present in both sides' Phase 2 selectors, or the translated source address is included in the existing selectors.

Tags

No tags yet.

Community rating

— / 5 (0)

Discussion (0)

    No comments yet.