FORTIGATE-40F : Overlaps VPN SSL 7.2.0

[PaulSA]

Hello,

I have a problem with a client, their network is at 192.168.1.X.
They must access this network remotely through an SSL VPN.
However, the problem is that the client's home network is also on 192.168.1.X.
So when they have to access a server in RDP for example on the address 192.168.1.5, it will search on their home network and not via the SSL tunnel.
The FORTIGATE-40F is in version 7.2.0, I tried this solution:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-SSL-VPN-with-overlapping-subnets/ta-p/1898...
but this solution doen't work on version 7.2.0
Do you have solutions to create an overlapping on a network or another solution.
Thank you for your reply.

[sw2090]

the only solution I ever found and this also goes for ipsec vpn is the one listed in the link you posted. Since no one wants to enable overlapping subnets you have to rewrite it using vip. Then you have to use the vip address instead.

So e.g. when remote net on vpn is 192.168.1.0/24 and vip rewrites that to 192.168.5.0/24 on your site to not have overlapping that means you have to use 192.168.5.0/24 in your requests.

so if you want to reach 192.168.1.5 on remote side you have to use 192.168.5.5 on your side and vice versa if the remote side wants to reach your subnet.

I once had that working fine on ipsec vpn before we changed the remote subnet.

[PaulSA]

Thank you for your reply.

Small question in addition when I set up this solution, my network (lan client) lost access to the internet and I do not understand why. Did you have this problem too ?

[Karthikmurthy]

If the user change the IP in his Laptop/PC as 192.168.5.5, then the local LAN in the home router should also be in the same subnet as 192.168.5.0/24 for the network connectivity.

[pminarik]

Hi PaulSA,

There's two possible approaches I can think of:

1, Set up individual /32 split routes, and push them to the VPN clients.

For example if the user needs access to RDP server on 192.168.1.5, create a split route for 192.168.1.5/32 in the VPN portal. This /32 route should take higher priority in the client's routing table over the local subnet. Note that this will not work if the IP of the client's local gateway, or the client's own IP, conflicts with one of the IPs of servers/services you want them to access on your side.

2, Try the CLI-only option `exclusive-routing`, as described in this KB article. It should force all traffic to go into the tunnel. (this assumes that you are OK routing all of the client's traffic, i.e. you do not need to do split-routing)