Overlapping subnets SSL VPN 5.4.3

[Wyzz]

Hi Everyone,

Basically I'm looking for a how-to on SSL VPN with overlapping subnets. I've got a collegue at a hotel where they are cool enough to use the 172.16.0.0/16 for their wireless guest network. We've got a 172.16.x.0/24 in use, and thus the client (even when connected to the VPN) tries to use the local connection. Connectivity to internet works great via the same VPN (full tunnel, no split), only local resources give issues.

I found a document for 5.0-ish which describes pretty much what I'm trying to do on 5.4, but doesn't seem to work out:

http://kb.fortinet.com/kb/viewAttachment.do?attachID=SSL%20VPN%20with%20over%20lapping%20subnets.pdf...

So I created: A VIP:     edit "hotelnat"         set extip 192.168.x.2 (a free unused /24 on our side)         set extintf "any"         set portforward enable         set mappedip "172.16.x.2"         set extport 80         set mappedport 80 (Yes, also tried: set extintf "ssl.root", and without ports, and with a source IP range, and with the entire range instead of the /32's) IPv4 Policy: config firewall policy     edit 15         set name "Destination Hotel"         set srcintf "ssl.root"         set dstintf "LAN-Zone"         set srcaddr "SSLVPN_TUNNEL_ADDR1"         set dstaddr "LAN_DATA_VLAN_10" (original from clone)         set action accept         set schedule "always"         set service "ALL"         set utm-status enable         set logtraffic all         set groups "VPN_Users" => FW (15) # set dstaddr hotelnat renders error message: entry not found in datasource value parse error before 'hotelnat' Command fail. Return code -3

But the option "hotelnat" is no suggestion when tabbing / ?'ing.

In the GUI, I can select it, but it renders a useful "Some changes failed to save" message. A regular VIP mapped on the WAN interface works flawlessly.

What am I missing? The only thing I could guess it doesn't know anything that has the 192.168.x.x range, but I wouldn't see why that is _required_ to have (or where to put it if it is).

[Wyzz]

Bumb, that hard of a question? :)

[bgp179]

I ran into the same problem and I came away with some possibilities for you.  Our head-end office used 192.168.1.0/24 and, as you know, many users have the same home network subnet.  I followed the same guide you did and had the same problem where I couldn't apply a VIP to a SSLVPN policy.  I worked with Fortinet TAC but they couldn't provide a solid answer because they said it just "worked for them".  Anyways, here are some things I found out after testing on my own:

1.) You can't put user groups in an SSLVPN policy that has a VIP in it (at least, I couldn't when I was testing a FWF80CM with both 5.2.7 and 5.4.3).  So you'll have to block access by source IP and will have to have some other policy with that user group in it so it's activated.

2.) Then I created the VIP and installed it, but it blackholed all traffic from that 192.168.1.0/24 subnet to the Internet.  Why?  I have no idea, but I believe that this VIP overridden the outbound Internet policy overload NAT. Doesn't sound right to me, so I just thought it was a bug. But I had to change the extinf from "any" to "ssl.root". That cleaned it up.

3.) I also found I could disable split-tunneling.  Then I created 4 address objects.  Two objects of /25's to force the 192.168.1.0/24 subnet thru the VPN tunnel (192.168.1.0/25 and 192.168.1.128/25).  And a pair of catchall objects for Internet traffic to mimic split tunneling (0.0.0.0/128.0.0.0 and 128.0.0.0/128.0.0.0).  Apply all of these into a policy and boom, they get injected in the host's routing table.  I called these policies "SSLVPN DUCT TAPE".

4.) But what I ended up going with is the Virtual IP, DNS translation.  All hosts were reachable by DNS, so we used DNS servers not in the 192.168.1.0/24 range, and then any DNS record with a 192.168.1.0/24 got re-written to a 10.x.x.x address.  The SSLVPN host was completely oblivious and could communicate over the tunnel which the firewall NAT'd into 192.168.1.0/24.

So there you have it.  Maybe it will help you, maybe not.  Hope it does. 

[MikePruett]

I would disable split routing and see if it gives you the benefit. This is what we do in environments where the users home network is overlapping with the remote network.

[mr_csce]

The cause of "Some changes failed to save" message is that Web mode is enabled for the user who is configured in the policy. You need to disable "Web mode" for the user who is on overlapping subnets.