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

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