Cisco – Users want to work remotely, but need to use the same LAN IP addresses

You can do this in theory, but you will need a good client machine to do that and by good, I mean a good Windows installation.

This is because the operating system on the machine you want to use SSL VPN client will have to deal with all the traffic, and that machine will have to somehow prove router&firewall capabilities.

Step 1: you connect that machine (from remote office) to the headquarter. You will receive an IP address from the SSL_VPN_pool.

Step 2: you will add a static (persistent route) on all stations (from the remote office), that for the HQ destination would have to reach through the machine connected at Step 1.

Step 3: you will have to enable Routing&Remote Service on the machine you use SSL VPN client (I assume you will use a Windows platform, although Linux will work better for this), so that traffic from that location will be routed from lan interface to the VPN_interface. Here is a catch: you will either NAT this traffic with a source of your SSL_IP_pool or you can let it this way.

Step 4: if you don't NAT you have to add on Fortigate static routes for the remote office network and also firewall rule on the ssl.root interface-->to-->HQ_internal.

You can do this, but that extra_vpn_equipment_money you don't want to spend would be NAT-ed into some workstation_configuration_sweat.

Yes, what you suggest would work just fine, assuming that you have control over the existing default gateway/router for the subnet on each side. Variations on this same theme can be used to provide VPN backups to a primary connectivity method (MPLS, point-to-point T1/T3, etc.) using route tracking, static routes with a higher AD 'underneath' a dynamically learned route on the primary connection, etc.