SSL-VPN: Restrict destinations by group?

[#1]

Hi everyone. I' ve been scratching my head on this one: I' d like to restrict what destination IP addresses on the protected network are reachable via ssl-vpn client groups. I thought this would be doable by defining a wide SSL-VPN range, then restricting which addresses were actually assigned on connection via the SSL-VPN group settings (restrict IP tunnel range), and finally creating a SSL-VPN policy which explictly states the source and destinations allowed and assigning the appropriate group(s). It seems as if this should work, but alas; it does not and I' m left banging my head. Everyone SSL-VPN' ing in can access everything on the said protected subnet. What am I missing?

[weinsjs]

Hi Brian, I have same problem. I have two FortiGate 500' s in A-A HA and not comfortable enough with moving from 2.8 to 3.0 for production. So, I am using an FG60 for SSL VPN purposes off one of the interfaces. Upon configuration, I had/have the same problem. I ended up " patching mine" by configuring the policies on both the FG60 and the FG500. It is duplicate (which stinks) but met with my goal. I don' t know if this is a known bug or just something I missed as well. Take care weinsjs

[#3]

Hi, Had the same problem, and knocked my head against the wall before giving in and calling support. I guess I could have saved myself a headache, as according to support, this is a feature request for MR4. Until then, you set one policy for access and the destination. If you put in more than one SSL policy, the least restrictive seems to take effect. It seems to take (no matter what source you put in the policy address) the address field for Source from the range of IP addresses set up in SSL VPN. After talking to the gentleman from Fortinet (who talked to escalation before getting back to me), I tried a few configurations and have found a " solution" of sorts. Do the following after setting up your basic SSL VPN configuration. Create two (or more) SSL VPN user groups. Split up your SSL VPN range into however many groups you want to configure. For example, if you had 192.168.1.10-20 set in the SSL VPN range, and you want to configure access for 2 groups, then the range could be split to x.10-15 for group a, and x.16-20 for group b. You would do this in the SSL User Group Options " Restrict tunnel IP range for this group " . Then create to address ranges, call the first ssl 10to15 and the second ssl 16to20, or whatever you want. Create your base (i.e. bottom position) SSL Authentication policy, i.e. WAN1, Address SSL VPN Entire Original Pool to Internal, Entire Private net, action SSL VPN. The create 2 policies that you will insert in front of it, one a policy that will deny action all access to the private net (middle position), and one policy that will allow action access to the restricted group to whatever specific machines you want to allow access (top position). In this setup, you end up with one restricted group, and a second (administrators?) unrestricted group. You can nest more allow/deny policies to tighted up as needed. Ok I know that is a bit confusing, so here' s a picture., it' s relatively simple once you get the idea. Think restriction by IP ranges, and SSL Action used once for authentication. Hope this helps.

[#4]

Thanks for the responses and suggestions. Walter, I' ll try your set up and see if it works. I' m a bit confused as to why it works, but I think I know how to get it set up. I guess we' ll wait for MR4! Does anyone know when that is supposed to be released?

[#5]

Let me know how it turns out for you. As for how it works, think Linux Ipchains/Iptables. Top down rule matching, with the deny as your " default" policy, and all the allow policies above designating actual access. The SSL VPN action at the very bottom is simply an " authentication" rule that you use to state who can use the VPN tunnel. The SSL VPN is not affected because the users do not have does source IP ranges until after they connect. However, once they connect, their source IP ranges (the private IP addresses on your LAN) changes and that' s when the policies above start to affect them. Walter

[Paul_Dean]

Thanks Walter. That was very useful indeed. I have also been able to access multiple interfaces across the SSL VPN too. Set it up as Walter describes, then create rules on the second interface pair to allow or deny access (as rules 34 and 35 above). You only need 1 authentication policy (as in rule 33).

[#7]

Hi, I did same firewall policies " Number 35 is number 1 and Number 33 is number 2 in my configuration " with range 192.168.1.10-15 allowed access group to policie 1 and range 192.168.1.16-20 in allowed access group to policie 2 For the policies 1 it is ok , one user take ip 192.168.1.11 but when an user who match policie 2 is ip is also 192.168.1.11 and no in the range 192.168.1.16-20 I change order of policie :policie 2 become 1 and policie 1 become 2 The result is For the policies 1 it is ok , one user take ip 192.168.1.17 but when an user who match policie 2 is ip is also 192.168.1.17 and no in the range 192.168.1.10-15. If somebody have an idea Thanks for your help FG60 V3.MR3

[#8]

I' m not sure if I' m understanding this right but I' ll take a shot at it. When you set up your user groups, for ssl vpn, you can arrange for restrictions to what ip address they are assigned. So in the user groups, you should have one for policy 1' s ip range, and another for policy 2' s ip range. So when a user logs on, depending on what policy you would like to apply to the user, they should be part of the respective ssl vpn user group. So if policy 1 is 192.168.1.10-15, then the ssl vpn user group (user group 1 for example) should be restricted to 10-15. Then the user, who should be part of the autheticated user group 1, will only be assigned an ip in the policy 1 range. Hope that helps. Z

[#9]

Sorry Walter for my english, You are understanding my problem. It is OK for an user where is in user group with policy 1' s ip range. But when it' s an user where is in user group with policy 2' s ip range(differently with policy1' s ip range) , his ip was assigned in the range of policy 1. My problem is the ip is automatically assigned in the ip range in the policy 1 even if policy 2 or 3!!!!! was matched compared to user. Thanks for your answer. If you have an idea or somebody...

[#10]

It' s OK. The problem was that users matched the same policie!!!!!