SSL VPN Traffic NAT'd

[AdrianForrester]

Hi,

We have recently introduced a FortiGate-30E to make our VPN solution more in-line with our business requirements. This has largely worked as expected, however, it has been identified that all connections are NAT'd, so all the traffic appears to come from the subnet's gateway IP rather than the VPN Pool IP that is allocated to the connection, this has some knock-on effects with some software that uses the IP to identify a users system.

I was hoping someone could point me in the right direction as to how best to handle this kind of traffic.

As an example we have the device interfacing with three subnets:

192.168.10.x 192.168.20.x 192.168.30.x

We were wanting for users to connect in and be allocated an IP from the 192.168.10.x DHCP pool, and be addressed as such. These users would then need to be able to connect to the 192.168.20.x and 192.168.30.x subnets, so I am figuring that there is something I need to do with Static Routes, but this doesn't seem as clear cut as it was on my older Watchguard Firebox Devices.

Any suggestions/help regarding this would be appreciated.

Regards

Adrian

[Toshi_Esumi]

We almost never use ssl vpn web-mode. But my understanding is the web-mode client doesn't have an IP assigned, instead picks up the FGT's outgoing interface toward the internal resource as the source IP described in the KB:

https://kb.fortinet.com/kb/documentLink.do?externalID=FD36530

And if you need to have an assigned IP per client, the SSL VPN needs to be in tunnel-mode. And, you can't set up tunnel-mode without FortiClient (or FortiClient VPN). This is what we always use and set up an IP pool for all clients (or per realm).

[If someone knows I'm wrong, please correct me.]

Toshi

[AdrianForrester]

Sorry, we are using the FortiClient VPN, the VPN is tunnelled but ALL the traffic from the remote users is NAT'd/masked with the IP of the FortiGate 192.168.10.4 rather than the IP of the VPN Client Connection e.g. 192.168.10.101

[Toshi_Esumi]

Then it's a question to yourself why NAT is/was needed when it was set up.

[AdrianForrester]

NAT was enabled as per the guide in the Fortinet Cookbook, if I disable the NAT rules for the other subnets, they are no longer reachable from the IP assigned by the VPN.

[Toshi_Esumi]

I was surprised when I saw a cookbook for 6.0 had NAT on on the policy like below:

https://docs.fortinet.com/document/fortigate/6.0.0/cookbook/364638/adding-security-policies

If the NAT is on, it uses outgoing interface IP like your case 192.168.20.x or 192.168.30.x configured on the FGT. I think that's why it was working before. If they're directry connected to the FGT, there is no need to add any static routes except for the IP pool 192.168.10.x. Since you didn't configure (I'm assuming) like 192.168.10.1/24 on ssl-root interface then made the IP pool 192.168.10.2-192.168.10.99, there is no route for 192.168.10.0/24 on your routing table. (check it via GUI or CLI [get router info routing-t all])

So you need to have a static route for 192.168.10.0/24 toward "ssl.root" interface.