Using SSL tunnel VPN only from defined set of computers

[sbuerger]

We currently evaluating fortigate for using it as a client ssl vpn endpoint.

Most of our users have notebooks where they are local administrators because they have to install software most of the time.

All of this notebooks are domain joined.

When they use the ssl vpn they should be able to work like as they are connected in house into our intranet.

Only this notebooks should be able to use the ssl vpn endpoint.

Our first thought was to use computer certificates as a 2nd factor. It looks like this isn't possible because the client does not show the computer certificates.

We have user certifactes for client authentication and email signature. But they are exportable. Users could export them and use them on their private computers and successfully connect to the network.

For now the only solution we found is to register the forticlient installations which generates more costs because we need to license the forticlient without using (at least for now) any of the other features the license brings.

Are there any other solutions we could use?

If you use it, how are you using this ssl tunnel vpn solutions? Could your vpn users use any device to connect from? Do you limit the services they could use through the ssl vpn, or are they connected like they are in house in the internal network?

[rdumitrescu · Accepted solution]

Hi,

I think that you could use the MAC check feature:

conf vpn ssl web portal     edit portal        set mac-addr-check enable        set mac-addr-action allow        config mac-addr-check-rule            edit "rule1"                set mac-addr-list 01:01:01:01:01:01 08:00:27:d4:06:5d                set mac-addr-mask 48            end        end

[sbuerger]

rdumitrescu wrote:

I think that you could use the MAC check feature:

Thanks. We already thought about that feature, but as I understand it is CLI only and we have at least 200 devices we would need to add. We don't want to limit it to alle devices from one vendor, because then they could use own devices from that vendor too.

And as we understand, it will be for the whole ssl web portal, so they couldn't use the web portal for some intranet websites from other devices (internet cafe, etc.).

[sbuerger]

Hi,

to give a feedback. We evaluated a bit more. We tried Forti Authenticator with certificates and a lot of other stuff too. Nothing was the solution we searched for

We had an issue while trying to limit the connection to registered clients only. Somehow in the firewall rule, the option to use a device group was hidden when you had the SSL VPN selected as source. Looked like an UI bug. It does work when you use the correct steps. Until then users could use the SSL VPN from any client regardless of the registration, you had only the user group to limit the source in the rule.

We decided to go with the registration, which gives us the following working solution:

1. SSL Webportal for ldap users with token.

  They have to use their Active Directory Login and a Token.

2. A second Webportal for ldap users without a token.

  This is for external contractors or customers with limited access to only some internal web servers.

3. A SSL VPN for a set of ldap users with token and for a set of registered Forticlient. We can have groups of defined clients allowing access to targets in rules.

It costs more because of the Client subscription licenses. We consider to use the other features in the client software (Antivirus, Vulnerability Scan, etc.) in the future.

[ebonick]

I too had this working, but now can't remember how I had it working when testing. Can you provide details as to how you did it? Fortinet says it's not supported and no matter what I do on 5.2.4 I can't get it working.

[sbuerger]

ebonick wrote:

I too had this working, but now can't remember how I had it working when testing. Can you provide details as to how you did it? Fortinet says it's not supported and no matter what I do on 5.2.4 I can't get it working.

The Forticlient registers the device on the fortigate. Then the Client is added to a custom group.

When you create a firewall rule you have to select a the ssl vpn as source and you select the user group and as "source device type" the device custom group.

If the "source device type" is hidden as you select the ssl vpn as source you have to create one rule via CLI. After that new rules you create via web interface with the ssl vpn and a device group should be possible.

BUT we still have a big problem with that. After about a week some IPs the users are assigned to are broken. The clients wouldn't be detected as registered and they are not allowed to send traffic through the rules that have a device group selected.

We had this since we implemented it in 5.2.2, running 5.2.4 now. We have a open case with Fortinet about this issue.

I hope they fix this issue soon. This is a big requirement for us to only allow systems we have registered.

[ebonick]

sbuerger wrote:

The Forticlient registers the device on the fortigate. Then the Client is added to a custom group.

When you create a firewall rule you have to select a the ssl vpn as source and you select the user group and as "source device type" the device custom group.

If the "source device type" is hidden as you select the ssl vpn as source you have to create one rule via CLI. After that new rules you create via web interface with the ssl vpn and a device group should be possible.

BUT we still have a big problem with that. After about a week some IPs the users are assigned to are broken. The clients wouldn't be detected as registered and they are not allowed to send traffic through the rules that have a device group selected.

We had this since we implemented it in 5.2.2, running 5.2.4 now. We have a open case with Fortinet about this issue.

I hope they fix this issue soon. This is a big requirement for us to only allow systems we have registered.

So are you manually assigning ip's to a device? I am using a range of ip's and I add the device group to the rule via the web interface on the screen with all the policies listed. You can right click the policy and add device groups. It's strange every time I call I am told device identity on the ssl interface is not supported since it goes across multiple layer 3 devices.

Here is my test rule which is disabled at the moment.

fw (64) # sh config firewall policy     edit 64         set uuid 471a9828-57cc-51e5-c45d-b3f326b92c19         set srcintf "ssl.root"         set dstintf "internal"         set srcaddr "SSL VPN Clients"         set dstaddr "Internal networks for 5.2.4 bug"         set action accept         set status disable         set schedule "always"         set service "ALL"         set utm-status enable         set groups "VPN"         set devices "Domain PCs"         set av-profile "default"         set profile-protocol-options "default"         set ssl-ssh-profile "certificate-inspection"     next end

Can you send me a sanitized version of your config with the relevant bits so I can try to figure out how you have it working? Also do you have a ticket number I can reference in my ticket to show them it in fact does work?

I appreciate the help, my current ticket has been open a month and now they want me to do a feature request through a sales engineer.

[sbuerger]

    edit 131
        set uuid 08030976-c1a5-51e4-cc93-06c235bd4c46
        set srcintf "ssl.root"
        set dstintf "VPN_XXX"
        set srcaddr "RANGE-SSLVPN_192.168.XX.10-250"
        set dstaddr "somehost"
        set action accept
        set schedule "always"
        set service "services - {40173}"
        set logtraffic all
        set groups "VPN XXX"
        set devices "VPN_Clients"
        set endpoint-compliance enable
        set nat enable
        set ippool enable
        set poolname "VPN-XXX_192.168.XXX.202"
    next

That is one of the rules.

The users are in the group "VPN XXX", the devices are in the device group "VPN_Clients".

And we have a ip range for the ssl vpn.

Sometimes the registration succeeded, sometimes not. When it does not work, most of the time the users had a "broken" ip. For example since the upgrade to 5.2.4, after a week, the IP .13 is affected. Everyone who gets this IP could not be registered. Other IPs are working fine.

Our ISP have reselled the device and makes the communication with fortinet, so I don't have a ticket number, and I'm not the administrator of the system myself, so I'm unable to send you a whole config. I tell my colleague to check the thread, maybe it helps to get in touch to speed the process up.

This feature was a requirement for buying this device. If they tell us it is in fact not supported... We are implementing the device since March...

[sbuerger]

@ebonick, do you got any progress with the issue?

We have a confirmation from fortinet about the issue.

I guess the case number is #1516583.

The problem is, that some connections that dont register correctly shows up with weird MAC "02:c0:a8:1e:0f:aa" for example. The ones that work are shown with their physical existing MACs.