SSL VPN - Route assigned to client

Welcome to the forums. Are you using Forticlient or the web interface for SSL VPN connection?

Hi Bob, Thanks for the reply. I' m using the web portal for the connection. Thanks

The route for the SSL VPN tunnel are defined in the Portal rule that you configure on the Internet - LAN interface (ie, the rule that bind the SSL-VPN policy to the portal). If you enable connection from Any to LAN1 and LAN1 the route to LAN1 and LAN2 will be enabled on the client when the SSL VPN tunnel start. The ssl.root -> LAN policy act as pure firewall rule. Bye.

Is the new subnet local to the Fortigate or remote (across another router/firewall)?

Hi Guys, Thanks for looking at this. Hi Federico - Could you tell me where to go in the web interface? I' ve been through all of the options under VPN -> SSL and can' t find anything that allows me to set binding rules. Hi Bob - The second subnet is routed via another router on the LAN side of the Fortigate. The routing is in place (I can ping addresses on the second subnet from the Fortigate CLI).

OK, I' ve found out some more info on this. I looked again at the ssl -> LAN policy and noticed that the ' Action' was set to Allow instead of SSL-VPN If I change the Action to SSL-VPN and reconnect the client, it does indeed receive routes to both subnets BUT all communication from the SSL client to internal LAN stops working. Any idea why I would be able to successfully communicate with the internal LAN (albeit only one subnet!) when the action is set to Allow, but not when the action is set to SSL-VPN? Thanks

OK, I know where I was going wrong now. I' ve managed to crack it with another read through the Fortinet SSL VPN documentation. I think the first mistake I made was that the ssl -> LAN policy was set to ' ACCEPT' instead of ' SSL-VPN' as detailed in a previous post. When I changed this to ' SSL-VPN' , the routes were advertised to the client as expected. The reason I then couldn' t access any resources on the internal LAN is that you also need an ' ACCEPT' policy in addition to the ' SSL-VPN' policy. Apparently for a tunnel mode VPN, the first (SSL-VPN) policy sets up the authentication / client routing, and the second (ACCEPT) policy actually allows the traffic to pass from the client to the internal LAN. All this is in the SSL VPN documentation, but I obviously missed it! Looks like if you only have the ACCEPT policy, the VPN connection sort-of works, but the routes are not advertised to clients. I now have both policies in place and everything is working well! Thanks for your help. **EDIT** I think all of this is exactly what Federico was getting at in his earlier post.

ORIGINAL: blanni **EDIT** I think all of this is exactly what Federico was getting at in his earlier post.

Ok, my english is not so good, but that was the info ... Remote routing is configured by the Internet - PortXX rule (with Action SSL_VPN). When you configure the policy with an ANY to LAN1 you are allowing connection to LAN1 from the SSL portal but you are also " passing" LAN1 route to the remote client (if it connect with the VPN client ..). With the ssl.root - PortXX rule (with ACCEPT) you allow the traffic from the VPN ssl client. If you don' t need Portal Access VPN, just add only ping as the service in the SSL portal that you bind to the SSL VPN rule (so if the user connect to the SSL portal instead of using the SSL VPN client, he cannot bypass the ssl.root - PortXX rule). Bye !