SSL VPN - Route assigned to client

[blanni]

Hi, I' ve inherited a Fortigate 80C from a previous admin. SSL VPN (Tunnel-Mode) for remote clients is configured and working well. When clients log on to the SSL VPN tunnel, they are automatically assigned a route in their local routing table to access our internal network (192.168.10.0/24) and eveything works fine. I now need to add a new internal network subnet (192.168.20.0/24) for the remote clients to get access to. I' ve created a new ssl.root -> LAN policy allowing the SSL VPN clients to access the new subnet on the internal network, the problem is that when clients connect, they are still only provided with a route to 192.168.10.0/24 in their local routing table. The route to 192.168.20.0/24 is not being automatically created, so the client can' t access that subnet. I' ve been through the SSL VPN docs and can' t find the details anywhere for specifying the internal network routes that get assigned to the clients. I assumed that the SSL-VPN policy would have taken care of this bu apparently not. Can anyone help? Thanks

[blanni]

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.

[rwpatterson]

Are you using policy based tunnels?

[vanc]

ORIGINAL: blanni I now have both policies in place and everything is working well!

That' s strange. You don' t actually need to use an extra ACCEPT policy for SSL VPN traffic, unless there are some kind of firmware bug?

[vanc]

ORIGINAL: blanni I now have both policies in place and everything is working well!

That' s strange. You don' t actually need to use an extra ACCEPT policy for SSL VPN traffic, unless there are some kind of firmware bug?

[Federico_Vecchiatti]

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 !

[rwpatterson]

For what it' s worth, I don' t use the ' any' interface. I lock my units down more than that, so my traffic is from WAN -> SSL.root -> inside port(s). There is now way traffic could bypass the ssl.root interface and get anywhere. Still takes 2 policies, but I know who/what/where all the traffic is allowed to go. My 2 cents