SSL VPN Connection and Subnets

[Joker5893]

Hi,

We just put a Fortigate in place. I have the SSL VPN working and vpn my clients can get to the 172.19.0.0/16 network that the Fortigate is also on. However, they can't get to devices that are on the 172.18.0.0/16 network. 

[pgautam]

Hi @Joker5893 

You are able to get access to the 172.19.0.0/16 network post connecting to the Forticlient but not the 172.18.0.0/16.

For this,if you are using a split tunnel then make sure the subnet is added in the routable address.

 

>> Make sure you have a subnet added in the ssl.root to a particular LAN interface

You can collect sniffer log as well to check the traffic flow:-

dis sniffer packet any "host <source_IP> and host <destination_ip> " 4 0 a

Regards

Priyanka 

- Have you found a solution? Then give your helper a "Kudos" and mark the solution.

[sjoshi · Accepted solution]

Dear Joker5893,

Thank you for posting to the Fortinet Community Forum.

Problem Description:-
SSL VPN Connection and Subnets

As per the case notes you are not able to reach the dst 172.18.0.0/16.
In the SSL VPN settings which ever the portal the user group matches make sure in that portal split tunnelling is enable and select enabled based on policy destination.
After that in the firewall policy create a policy from ssl.root to lan interface where the NW 172.18.0.0/16 is connected .
In the destination address define the address 172.18.0.0/16.

Let us know if this helps.

Thanks

[Joker5893]

Thanks. I did have this in place but apparently, these firewall policies don't update until you disconnect and reconnect to the VPN. I went back to it last night and it was working but wasn't working earlier in the day when I was testing. 

[sw2090]

yes you either have to use split tunneling to distribute the routing upon connecting the vpn or all client traffic will flow to the Fortigate once the VPN is connected.

In both cases you will also have to have a policy to allow the traffic to flow on.

[Nchandan]

Please inform us if you have followed the previously mentioned suggestions and you are still encountering the same issue. In case the problem persists, you may need to collect the debug flow and packet capture and then submit a ticket to the TAC for further verification.