Accessing SSL VPN addresses from a virtual IP. Virtual IP Translation - Subnet overlapping

[Palova]

Hi everyone, i hope i can be as clear as possible. I've been trying to copy this setting from an old firewall for the past few hours and i can't make it. 

One of my customers has a classic home subnet 192.168.1.0/24. (the mother of all broubles)

They have a lot of SSLVPN users that must access this network. 

This creates a lot of overlapping since 192.168.1.0 is a very common subnet.

On the old Firewall (Fortinet 40F) there was a setting that allowed a SSLVPN user to reach all addresses in the 192.168.1.0/24 subnet by using another subnet 172.16.0.0/24.

All IP addresses would then be automatically forwarded to the corresponding server IP in subnet 192.168.1.0: Example: if I ping 172.16.0.19 i would actually ping 192.168.1.19 but it would also work if i pinged 192.168.1.19. 

This was made to avoid ip conflicts in case your home subnet is the same as the company, allowing you to still reach the remote servers using a subnet that is usually not present in home connections. 

I know it has something to do with virtual IPs and SSLVPN Portal but all my attempts are in vain. 

Any help / alternative to avoid this subnet overlapping with SSLVPN?

[dbu · Accepted solution]

Hi @Palova , 
Maybe you are looking to create a VIP object to map the overlapping subnet.
Can you test like this: 

1-Create a VIP to map 172.16.1.19 to 192.168.1.0/24 subnet
2-Create a firewall policy with source IP range the VPN pool and destination the VIP object created above
https://docs.fortinet.com/document/fortigate/7.4.3/administration-guide/155333/virtual-ips-with-port...
.

[Palova]

Ok so i initially thought it should be done, as stated in this guide https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-SSL-VPN-with-overlapping-subnets/ta-...

I tried it but it does not seem to work. 

I created VIP group, i created separate sslvpn portal, i created firewall rule and put it on top of the other SSLVPN rules, no success. 

Am i missing something? 

[dbu]

If you  have done the configuration the same as in the mentioned article it should work. 

SSL VPN with overlapping subnets - Fortinet Community
Maybe the traffic did not match the correct policy for it to work? 

Run the following command to understand which policy is the traffic hitting :

diag debug reset

diag debug flow filter addr 192.168.103.83 <<< replace with the IP of the PC

diag debug console timestamp enable

diag debug flow show iprope enable

diag debug flow show function-name enable

diag debug enable

diag debug flow trace start 1000

Test again an check the output for matched policy-..

[Palova]

I tried this on a fresh firewall and everything worked after some troubleshooting and making sure everything was set the way it should. So the solution in this article https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-SSL-VPN-with-overlapping-subnets/ta-... and your help and tips solved the issue, now i will proceed on the customer's device, hoping not to blow anything up :). THANK YOU. 

[dbu]

I am happy i was able to help. Good luck on the customer's production network :) 

[pminarik]

Another idea:
If you enable exclusive-routing (full tunnel required!), FortiClient should forcefully push all traffic into the tunnel, including what would otherwise be traffic on the local subnet (excluding the local gateway IP, for obvious reasons).

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Enabling-SSL-VPN-Full-Tunnel/ta-p/191848

Other options are DNAT with a VIP+policy (as already noted), or more specific individual routes pushed to clients (if doing split-routing), e.g. a handful of /32s for destinations that need to be reached through the tunnel (won't work if that IP conflicts with the end user's local IP or local gateway IP).

[Palova]

Thanks for all the support, but there are about 100 total vpn users and a full /24 subnet of servers/clients to connect to, full tunneling could be crippling for the user, and making special rules and exceptions for everyone will have effects on my mental health. :\ As soon as i can i'm taking an old 60E that has the same firmware and make some tests in a clean environment, instead of doing things on the production device. (i already got a few calls for interruptions in VPN). In theory what i did should make sense, but it does not work yet, so to make deeper modifications i must use a test environment. 

[pminarik]

Sounds like VIP is your only option remaining then.
Including users needing to learn to use the new subnet for destination IPs (If they're using IPs directly to connect to. And if yes, perhaps it's time to introduce everyone to the wonders of DNS :) )

[Palova]

It's fine, i can just send an email with the new links to evryone, most of them are web interfaces and RDP connections so it will be easy. Plus this feature was present on the previous firewall so they probably already have them. DNS should work (even though in many cases you must manually make entries in the hosts file in windows) but we still use IP, it skips one step as well as a point of failure/troubleshooting.