Technical Tip: Common mistake when forwarding SSL VPN Traffic Into IPsec tunnel in dynamic routing deployments

[akileshc]

Description	This article describes a common configuration mistake when forwarding SSL VPN traffic into an IPsec tunnel in Hub-and-Spoke deployments using dynamic routing.
Scope	FortiOS.
Solution	Administrators often configure a loopback interface with the SSL VPN user subnet so the HUB can advertise this subnet to Spokes via Dynamic Routing (BGP). However, this introduces an incorrect connected route, causing return traffic from Spokes to be misrouted and ultimately dropped due to Reverse Path Forwarding (RPF) check failure. Static Routing Scenario: When static routing is used, the administrator manually configures: Phase-2 selectors must include the SSL VPN client IP range. Policy between the SSL-VPN interface and the site-to-site tunnel in Site A, with SSL VPN users added. On Site B, a static route where the destination is 'ssl-vpn subnet' and the interface is the IPsec tunnel. If dial-up split tunnel is enabled, ensure the routing address is configured. Reference: Technical Tip: Forward traffic originating from SSL VPN into the IPsec tunnel  Dynamic Routing (BGP) Scenario:  When BGP is used, the HUB must advertise the SSL VPN user subnet to all Spokes. Because BGP enforces 'network-import-check', the HUB must have a valid route to the SSL-VPN subnet in its FIB. This leads to the most common misconfiguration. Common mistake. To satisfy the BGP route-existence requirement, administrators often do: Create a loopback interface. Assign the SSL-VPN user subnet to that loopback. Use a subnet in the BGP network advertisement configuration. Impact. A connected route points to the loopback. HUB assumes SSL-VPN users are behind the loopback. Return traffic for SSL-VPN users is forwarded to the wrong interface → packets are black-holed. HUB drops packets due to RPF check failure. Correct solution. Use a Static Route toward the ssl.root interface. Instead of using a loopback interface, configure the SSL-VPN subnet with a static route pointing to ssl.root. Benefits. HUB returns traffic to SSL VPN users through the correct interface. No RPF failures occur. BGP can still advertise the SSL VPN subnet. BGP Configuration example: config router bgp     config network         edit 0             set prefix <SSL-VPN-subnet>          next     end end Static route example: config router static     edit 0         set dst <SSL-VPN-subnet>         set device ssl.root     next end