Are you having a lot of issues with the remote access solution?

[PeterK]

Hi All

We migrated from another Firewall with a separate VPN box to know using the Fortigate 800D all in one solution.  However we have run into multiple problems.  There is no English UK keyboard for RDP connections through the RAS web page, although I understand this has now been fixed by OS 6.2.  We are finding it a limited amount of portals (50).  The username from Active Directory is case sensitive.  You can only link the user to one portal (our other system let you be in one profile and then let you pick up more  below if you did uncheck a box).  A major issue is groups.  Creating a local group on the Firewall works with local users, and you can then use that group in policies work.  Mapping to an Active Directory Security group also works but this then does not use the two factor authentication which we need to use.  Creating a Firewall group though and adding LDAP users does not work.  The LDAP users work added to the Firewall policies individually but not as a group which is a nightmare to setup and manage.  Wondering if others had these issues with the RAS and if you had ended up using an external box?

Thanks

Peter

[PeterK]

Assume this is just  me then?

[PeterK]

Anyone?  Are you finding the remote access fine or having issues?

[ede_pfau]

Methinks this might be a question of which pair of sunglasses you set up, so to speak.

To some extent, each vendor follows it's own assumptions and work flow. It might be cumbersome and sometimes impossible to exactly copy the work flow from one vendor to the other.

Some thoughts on your questions:

- 50 web portals are not enough? Given that the 800D is not the smallest FGT and that some limits are hardware dependent (see maximum-values-matrix) it might just be that Fortinet does not envision that you create one web portal per user. In reality I have never had to set up more than a handful of portals.

Besides, why not use tunnel mode and the FortiClient? Web portals do have their limitations as they use proxies for a limited number of protocols. Using RDP over an SSL VPN tunnel might just work for your environment.

- then, if you resort to using the FortiClient anyway, why not switch to IPsec VPN? much more stable, substantially less CPU load on the FGT, proven and traffic-agnostic. This is what I deploy nearly all the time.

- AD: username is case sensitive? And, why mention? "it's not a bug, it's a feature".

- LDAP users: usually, I set up a remote usergroup in such a way that a user is authenticated against one AD subtree containing several groups. The test is "member-of" only. Used in dial-in VPNs and firewall policies. I would not use individual users (remote or local) in policies because then additions and changes would force you to work on the policy set. Instead, policies use usergroups, and changes are applied to usergroups only.

2FA is a complication I admit. This might be doable on a FGT but maybe you would need a FAC (FortiAuthenticator) appliance for special needs.

And as a last advice I would try to get professional (local) help from a seasoned Fortinet partner, or Fortinet itself. You can accomplish a lot yourself but there's a limit. You're tapping in on one resource, the User forum, but maybe need more resources.

[PeterK]

I am currently looking at combining portals.  We have a lot of different support companies though we only give access to certain things  and a huge amount of departments  but trying to scale down on the amount we use and combining portals.  We have created IPsec VPN for some services for some user groups.

I referred to the Active Directory case sensitivity as a bug because Active Directory itself is not case sensitive on usernames and if you want to keep the names in a certain case format to make it easier to explain to people how to logon you need to then edit peoples names in AD before you import them and I do not see it a feature as it is not consistent.  If you map to a group in AD it is not case sensate (but you lose the 2 factor if mapping to an AD distribution group) but if you add users individually into an policy directly it is case sensitive.  Unfortunately we do not seem to be able to get this working properly creating a local Firewall group and adding LDAP users into it so we can use the groups with the policies and retain the two factor authentication.  Getting the case sensitivity wrong has also ended up with the user getting a portal they were not a member of although this has not happened many times.  We need to look at getting the groups working with Fortigate (it only seems to be with the RAS there is an issue here) or it becomes very difficult to organise the traffic policies.

This is an area though we have not been able to go live properly with yet originally only having the option for a US keyboard for RPD connections recently.  The latest firmware 6.0.3 though that gave us this feature has knocked the icons out of most of the portals in a known bug that was not part of the release known bugs which we are now waiting for 6.0.4 to fix which is estimated for release on the 18th December.

Thank you for sharing your views.

[ede_pfau]

That sounds tedious. Sorry for my misconception about the AD case sensitivity. Hopefully, you made FTNT (support) aware of this bug by opening a support case. Otherwise it will probably never be changed.

I'd love to hear how v6.0.4 works out for you.

[PeterK]

I reported the issue.  You can map to AD user account name rather than display name.  While this is still case sensitive it negates having a user maybe have to possibly log in with a display name that may be different than their account name and then using their account name once logged into the portal.  We have kept with the cn or display name though as I think its easier to adjust on the fly.

I will let you know if all our portals get fixed with 6.0.4.  I am waiting on retrying groups until we upgrade to that firmware.