Ya that was their answer when I requested it. But also all the local DC stuff will eventually go away. I’d like to see EMS with mdm integrations such as inTune more so that RPC stuff.
Thing is you can deploy the .exe too. I must admit as someone who hasnt done anything like that in the past it’s not exactly self explanatory but in the end it works for most of our customers. Everything from installing the app, over to importing a config and even hiding the „no support disclaimer“ page on first time using forticlient via command line which you can then automatically deploy in most deployment tools.
Thanks. I didn’t know about the MSI deployment element. That is a factor.
For my clients, EMS has made sense to them once they’ve tried to manage over 25 to 30 end-points…
Who cares if nothing else needs to be exposed to the Internet? It’s additional attack surface all the same. And yes, best practice is to put it into the DMZ, but then you lose certain features that require internal network access like adding AD domains.
I’ve seen that DNS problem, but only on Linux workstations, never on Windows for some reason.
That’s interesting, we initially suspected it was DNS related as the WiFi seemed to remain connected to the router, it actually doesn’t stay connected but the NIC is still capable of running in monitor mode, just can’t reconnect.
Yep, I had that one too. FortiClient’s split DNS implementation is absolutely a buggy mess. At least it was in prior versions. I have up because I had too many problems like that bug, and the awful performance of DNS lookups to your standard DNS servers when the VPN was up. It was just awful. I finally said screw it and just use our company DNS for all resolution for VPN clients. It at least doesn’t break DNS that way.
Went from free version to paid version without much hassle. The other way around is more difficult. If you don’t clean your installation correctly the free version won’t let you do anything after having a paid one.
Yes, you too are speaking my language now . I am looking to use them in place of Cisco FTD but because of this nonsense, I can’t make the move .Hack , sell me the vpn client at the EMS price , but No, you have to deal with one more thing to manage .
I agree, you can still hack your way around and use the free version. The thing is that this way really felt and feels like a hack…
At that time, FortiEMS was considered as the only “pro” and right way to go.
Also the amount of endpoints is “huge” (3k) and having support was considered as a huge bonus, especially for the managers.
In retrospective I would now advise the use of the free version as well.
To some degree I can relate but the benefits for me outway the disadvantages…
Especially when you require a telemetry key to make a connection to EMS and keep in mind as of EMS 6.4.7+ Certifcate for Endpoint Control has been introduced to further enhance security https://docs.fortinet.com/document/forticlient/6.4.7/administration-guide/48156
Some benefits to exposing EMS with TCP 8013:
- Remote Upgrade FortiClient to newer versions
- Send Profile Updates
- Trigger manual Scans
- Do Posture checking (ZTNA TAGS)
Alternative is EMS Cloud (Fortinet Hosted EMS)
Regarding AD Domains you can do the following (so you can still make your AD bind):
Telemetry related: WAN → TCP 8013 -->DMZ (EMS)
AD (least privilege AD User): DMZ (EMS) → TCP 636 or TCP 389 → Internal Segment
You mean you went from free client to EMS and did not have to uninstall the free Forticlient manually first ?
Did you go forticlient local or on cloud ? Was it difficult to setup ?
Exactly. We currently pay for AnyConnect licenses from Cisco. I don’t mind paying for a full FortiClient. Just don’t make EMS a requirement.
Does 8013 allow remote upgrades? I always thought 10443 was also needed for this to work or it couldn’t download the new package, which of course allows anyone with the URL to download an installer that can register to your EMS…
I also see the benefits on exposing your FortiEMS. The only thing I don’t get it is why did they use a non standard port? It should be 443 and a protocol over HTTPS.
My reasoning behind this is, for example: providers, at least in my country, are more and more pushing “security” features to their customers. One of those features is filtering out non standard ports. I bet this is a concern in other places too like hotels and public WiFi.
And the excuse on already using a port for management by default is just a sign of bad design.
Using custom ports internally: heck yes it doesn’t matter. Using them for a service that should be always available on the internet… I’m sceptical.
It happened more than 2 years ago so I’m starting to doubt myself… I remember the installation process was smooth and almost painless, it was from 6.0 to 6.2 .
It’s a on premise install. But we use Microsoft intune to push the packets. I’m don’t remember the details on how it was pushed though.
What’s your biggest client with Fortinet vpn client install ? Besides the issues with the banner , how are you updating the vpn client if not using EMS server ? Ism still stock on initial deployment for this week of 100 users and them worried about updating later . We do have Datto Rmm but have not tried it with that .
You can choose to run Telemetry on a different port to avoid issues with blocked ports. You than embed this different port in your FortiClient package and it works
As mentioned in a previous post, at this point I am hesitant to move to the Fortinet SSLVPN solution. We are currently only supporting Cisco AnyConnect for larger clients. I have the same concern as you do keeping the free ForticlientVPN up to date without EMS. I may end up sticking with Cisco for remote access or find another solution if EMS is a hard requirement to support Fortinet SSLVPN properly. Still trying to figure out that part out…
Indeed, it’s configurable, but have you ever tried to put telemetry on port 443 and maintain your FortiEMS more or less up to date ? It’s painful, every upgrade breaks it (or at least broke it). I ended up switching back to the default port in order to avoid issues with the upgrades.
I think it’s safe to use whatever other port but not the 443 (can tell my exp up to 6.4.X).
I still think that it’s a bad application design to not rely on standard web protocols for services that have to be on the Internet all the time. But it seems I’m alone one, even though, I’m quite happy with my own logic.