Fortinet EMS design

[vinceneil666]

Hi,

Where do you guys place your EMS server ? From a security point of view I'm considering placing it on a dmz that I can make available for our clients (multi customer enviroment). And just put in some rules.... But it might be even better having it behind an F5 service or something other ? 

Any inputs ? tips ? :)

[ergotherego · Accepted solution]

We put ours in a DMZ, and use a directly-assigned public IP address to avoid any DNS split-horizon issues.

Permitting TCP-8013 inbound from the world, geofenced to NA, with UTM applied. We didn't start off permitting inbound from the Internet, and were initially restricting to on-net sources only. But it caused too many issues for remote clients so we opened it up.

[SteveG · Accepted solution]

Great question as I've recently been caught out by this! Here's what I've done. Originally access from the FortiClients to EMS was only available when 'on prem' or VPN'd in. This worked fine to begin with but more and more staff are working remotely and not VPNing as we're a GSuite organisation but I still wanted the ability to push FC config changes etc. This required me to redesign our EMS install. I wanted to expose it externally but when original rolled out I hadn't configure the 'FortiClient telemetry connection key' which is needed to stop unathorised FC's registering. 

If starting fresh I'd suggest you:

Give the EMS server an external name, ideally have the FQDN resolve to the internal IP when on the internal network to save unnecessary firewall traffic.

Enable the Connection Key!

We have a pair of FortiADC's so our EMS server is exposed to the internet via the ADC DMZ network. 

Externally is resolves to x.x.x.x Ports 8013 & 8014 are open to our specific country.

Password (Forticlient Connection Key) is a little more tricky. But here's the process to achieve if you've rolled out without one.

Create a Gateway List for ems.company.com that includes a Connection Key.

Apply this new Gateway list to all existing profiles that are applied to clients.

Clients receive new Gateway list that includes the Connection key.

Within the EMS GUI "system settings", "Endpoints" configure a Connection Key that matches the one used in the Gateway List.

Doing these things in this order means the FortiClients remain registered to EMS without the need to enter the key.

Should someone need to connect that hasn't previously registered then they will be prompted to enter the Connection Key (make sure the tick both save boxes).[/ul]

[ergotherego · Accepted solution]

We put ours in a DMZ, and use a directly-assigned public IP address to avoid any DNS split-horizon issues.

Permitting TCP-8013 inbound from the world, geofenced to NA, with UTM applied. We didn't start off permitting inbound from the Internet, and were initially restricting to on-net sources only. But it caused too many issues for remote clients so we opened it up.

[SteveG · Accepted solution]

Great question as I've recently been caught out by this! Here's what I've done. Originally access from the FortiClients to EMS was only available when 'on prem' or VPN'd in. This worked fine to begin with but more and more staff are working remotely and not VPNing as we're a GSuite organisation but I still wanted the ability to push FC config changes etc. This required me to redesign our EMS install. I wanted to expose it externally but when original rolled out I hadn't configure the 'FortiClient telemetry connection key' which is needed to stop unathorised FC's registering. 

If starting fresh I'd suggest you:

Give the EMS server an external name, ideally have the FQDN resolve to the internal IP when on the internal network to save unnecessary firewall traffic.

Enable the Connection Key!

We have a pair of FortiADC's so our EMS server is exposed to the internet via the ADC DMZ network. 

Externally is resolves to x.x.x.x Ports 8013 & 8014 are open to our specific country.

Password (Forticlient Connection Key) is a little more tricky. But here's the process to achieve if you've rolled out without one.

Create a Gateway List for ems.company.com that includes a Connection Key.

Apply this new Gateway list to all existing profiles that are applied to clients.

Clients receive new Gateway list that includes the Connection key.

Within the EMS GUI "system settings", "Endpoints" configure a Connection Key that matches the one used in the Gateway List.

Doing these things in this order means the FortiClients remain registered to EMS without the need to enter the key.

Should someone need to connect that hasn't previously registered then they will be prompted to enter the Connection Key (make sure the tick both save boxes).[/ul]

[Markus · Accepted solution]

Good point, we put ours also in a DMZ and we have a quite similar setup. Important is the Connection Key.

[vinceneil666]

This is great feedback guys, made my day - I will be sure to share my final design on this when done. 

[vinceneil666]

Ok - so I ended up putting the EMS on a internet facing DMZ (external fqdn to). I am going to run split tunnel, so I have all my vpn clients connecting to it over the internet and not the tunnel... I am considering, if I am forced to turn off split tunnel - that I could do some NAT and DNS stuff to get it to be available over the VPN tunnel to.. I hope I dont have to. :)

I did as suggested and had both the gateway list and the policy list added in the EMS. Then I did an export of that and used it to generate my MSI file (the new forticlientrepackager is only avail in the developer network of fortinet.. lost a lot of rebranding options??). So it looks fine - I have the sccm making the software availabel and it comes with the gateway list and config allready there so it pretty much just connects when onlin, and then syncs up.

I find the VPN settings in the EMS profile a bitt iffy... Lets say I put in a SSL VPN, and add the option for the vpn that certificate check is enabled. When I first enable it, making sure the client is synced up, I get the option to choose one of my local certificates.. but then.. the option just goes away. Im not sure if it a bug or just me messing it up testing lots of stuff.. But it will be there if I just re-create it ? .. Anyone else had that experience ? 

Ans also.. the whole "attach to OU" stuff. I was pretty sure I could create a group with machines in the AD and attach the profile there. But no go. :) .. You have to attach it to an OU and have the client put in there. Fine.! :) 

I would also like to add to suggestion and "good ideas" when setting this up.. Plan for a "Staging" OU in ad, you are going to need it. I had one created and added my test client into that. Just cloning and copying both ems and regular profile.

Also when testing, I spent a bit of time messing around withn "take out of management", "deregister" and "mark as uninstalled" - when testing it is nice to know what will make you client software able to uninstall.and how to test a client from scratch.

[bbrown]

We built an EMS network and have the EMS server behind a FGT 60E.

We then build out StoS VPNs from the customer's routers to ours.

For offnet customers we have allowed ports 8113 and 8114 to the EMS server.

Keep it simple. Keep it secure.