I have a hub-spoke setup using BGP in a SDWAN setup. The SDWAN is due to having a fibre connection and a 4G for failover. So obviously I have both under each Zone.
HUB -> Spoke1
HUB -> Spoke2
The hub has a Dialup IPsec tunnel for fibre connection and one for 4G connection to allow multiple connections from all the Spokes.
Spoke1 has static IP IPsec VPN connection from its own fibre connection to the fibre connection of the HUB, and Dynamic DNS IPsec tunnel from its own 4G to the HUB's 4G connection.
Spoke 2 has the same setup to connect to the HUB.
I use BGP to advertise my internal networks of each of the 3 sites.
Everything internally is working and the internal networks can talk to each other, including when failing over to 4G.
My problem comes in with the FortiClient VPN. At each site I have a Dialup FortiClient VPN setup. When I connect to the remote VPN, I can access only the resources of the LAN at the site I am connected to. I can't talk to other IP ranges/VLANs at the site I am connected to.
But let's say I am connected from home to the remote VPN of Spoke1, then when I try to access resources on the HUB's internal network, it does not know how to get to the HUB's internal network. The routing table on my local laptop shows there is no entry to the HUB networks although it does try to go over the Remote Access VPN as when I do a tracert the first hop is the 169.254.1.1 IP that you see when you view the VPN connection on the FortiGate via CLI (not the gateway IP on the assigned IP range, 192.168.60.0/24, as per settings in the GUI).
edit "FortiClient"
set vdom "root"
set ip 169.254.1.1 255.255.255.255
set allowaccess fabric
set type tunnel
set remote-ip 169.254.1.1 255.255.255.255
set snmp-index 15
set interface "wan"
next
What I have also noticed is that although my remote FortiClient VPN IP ranges are added to BGP to be advertised, they are not listed in BGP. I understand if they are not active, it won't publish them. But even when I am connected to the remote client VPN so that it has an active connection on the IP range (192.168.60.0/24) , then it is still not published by BGP.
So due to the HUB and SPOKE2 not knowing of SPOKE1 remote VPN client, and the remote client VPN not knowing where to find the other internal networks, I can't talk to the other site's internal resources from the FortiClient VPN.
The same happens when I am connected to any of the other 2 sites remote VPN.
I have tried enabling/disabling add route, auto discovery sender, autodiscovery receiver, exchange interact IP, adding a static route to one of the remote internal networks as a test, and setting the client address range to be on the same IP range as the internal LAN.
How do I get the FortiClient VPN to be able to access all internal networks when connected to a site's remote FortiClient VPN?
My firewalls are running FortiOS V7.4.6 and the FortiClient VPN is V7.4.1.
Solved! Go to Solution.
Hi,
Assuming that you advertised under the BGP network statement from the Branch the 192.168.60.0/24 network and it's not being distributed to the Hub?
One cause of this might because you don't actually have a route installed in the RIB of the Branch FGT for that network but only /32's when a user connects.
You can handle this in several ways:
- create a static route with AD of 254 of 192.168.60.0/24 with the nexthop the DialUP IPsec interface, this way it will get advertised ( if it's not filtered by any route-map/prefix-list )
- follow this guide, https://community.fortinet.com/t5/FortiGate/Technical-Tip-Advertise-a-BGP-route-not-present-in-the-r... especially this command and disable it under the network statement for your VPN clients/network
Per Prefix Configuration:
config router bgp
config {network | network6}
edit <id>
set prefix x.x.x.x/zz
set network-import-check {global | enable | disable}
next
end
end
- another option would be to create a prefix-list set to outbound and in it specify the 192.168.60.0/24 le 32 , then under the neighbor statement enable it ( use with caution, because this will filter outbound only the prefixes set in the list so you have to make sure that you also define the rest of the local networks )
Hi,
Assuming that you advertised under the BGP network statement from the Branch the 192.168.60.0/24 network and it's not being distributed to the Hub?
One cause of this might because you don't actually have a route installed in the RIB of the Branch FGT for that network but only /32's when a user connects.
You can handle this in several ways:
- create a static route with AD of 254 of 192.168.60.0/24 with the nexthop the DialUP IPsec interface, this way it will get advertised ( if it's not filtered by any route-map/prefix-list )
- follow this guide, https://community.fortinet.com/t5/FortiGate/Technical-Tip-Advertise-a-BGP-route-not-present-in-the-r... especially this command and disable it under the network statement for your VPN clients/network
Per Prefix Configuration:
config router bgp
config {network | network6}
edit <id>
set prefix x.x.x.x/zz
set network-import-check {global | enable | disable}
next
end
end
- another option would be to create a prefix-list set to outbound and in it specify the 192.168.60.0/24 le 32 , then under the neighbor statement enable it ( use with caution, because this will filter outbound only the prefixes set in the list so you have to make sure that you also define the rest of the local networks )
@funkylicious thank you! That worked! I disabled set network-import-check globally then the routes showed up even before I added static routes or enabled it per prefix. I went ahead and added the Static routes for the remote VPN client ranges as well anyway with Blackholes.
The only other thing I needed to do was make sure Add Route and Auto discovery receiver were enabled on the remote VPN settings.
Thank you for the help!
User | Count |
---|---|
2551 | |
1356 | |
795 | |
646 | |
455 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2025 Fortinet, Inc. All Rights Reserved.