FortiTelemetry for remote users

[Kenundrum]

What do people do for telemetry for remote users? Do you allow it to directly connect from the outside interface or do you require a VPN session?

For example- if you allow a direct EMS connection (through a port forward) and fortitelemetry to a fortigate on an external interface you could ensure that clients will always receive profile updates because they will always be phoning home when online. The issue is that you are opening potential holes for exploitation in the perimeter.

The other option i see is requiring a VPN connection to receive profile updates and dump cached logs. Then it's only internal traffic hitting the boxes, but you lose the near realtime functionality.

Is there some other method i'm not thinking of?

I'm working on deploying forticlient to remote devices (not internal ones) for VPN access and endpoint control/compliance and wondering what others are doing.

[ergotherego]

Currently we restrict access to EMS across the VPN. Which obviously poses some challenges, namely as we migrate our users from the old VPN to FortiClient. In some cases, we end up having the user manually configure one of the VPN profiles to get connected to EMS and receive the rest of the profiles.

My big concern is dealing with upgrades of FCT for users who are entirely remote - if something were to go wrong, I can't fix it remotely.

I asked FTAC about the communication between EMS and clients, and was told its all encrypted via SSL over TCP-8013, but I haven't been able to confirm that myself. If I am able to confirm all traffic is encrypted natively between EMS and client, we will probably open it up to the Internet at large.

[Kenundrum]

As far as the SSL question, it definitely does. My vulnerability scanner has detected that it's using the built-in Fortinet Factory cert on the firewall and another self signed one issued to support@fortinet.com in EMS.

There doesn't appear to be a way to change which cert is being used on the fortigate side and i haven't imported any valid certs to EMS to try it there yet.

I have the same concert with remote users, which is why i'm trying it with the external access on to start with. Unfortunately it seems flaky no matter what i do. Clients end up in a state that makes them unusable with relative ease. I've been working on making a rock solid setup for the past 2 weeks with versions 5.4.x and 5.6.x and haven't really been able to get anything to work correctly 100% of the time. I almost want to just dump the EMS and create the profiles manually using XML.

[Kenundrum]

So for anyone who tries this in the future- top tip!

DO NOT use the same IP address for telemetry and the VPN gateway. Actually, pretty much don't use the VPN gateway IP address for anything else external facing that a VPN user might want to use.

I was using the same IP for the EMS telemetry port forward as the VPN gateway. There is a quirk with the way that the ipsec client works where it creates a funky static route to the gateway to tunnel the traffic. This causes any traffic going to that address that is not explicitly ipsec traffic to get sent with the source address of your local network adapter with no NAT. The device on the other end won't know how to route back to the source IP and drop the traffic.

I see why this is designed that way- and I'm surprised I've never been in a situation where I run into this before.

[tanr]

I'm trying to understand what you're seeing.

The FortiClient VPN client is creating a static route on the users machine to the *public* IP of the VPN gateway?

[Kenundrum]

Here is an example routing table (obfuscated of course)

In this example, 1.2.3.4 is the external address of the VPN gateway (fortigate).

192.168.1.100 is the VPN client and 192.168.1.1 is its gateway to the internet.

172.16.254.10 is the VPN tunnel address handed out to the client, 172.16.254.11 is the tunnel gateway (from fortigate)

10.10.10.0 and 10.10.11.0 are accessible networks as defined in the VPN config in the split tunneling example

normal destination mask   gateway       interface          metric 0.0.0.0      0.0.0.0 192.168.1.1 192.168.1.100 10

no split tunneling (all traffic to VPN) destination mask                  gateway          interface          metric 0.0.0.0       0.0.0.0               192.168.1.1    192.168.1.100 11 0.0.0.0       0.0.0.0               172.16.254.11 172.16.254.10 1 1.2.3.4       255.255.255.255 192.168.1.1    192.168.1.100 10

with split tunneling (internet stays local, only remote traffic to VPN) destination mask                   gateway          interface          metric 0.0.0.0       0.0.0.0                192.168.1.1    192.168.1.100 10 1.2.3.4       255.255.255.255 192.168.1.1    192.168.1.100 10 10.10.10.0  255.255.255.0    172.16.254.11 172.16.254.10 1 10.10.11.0  255.255.255.0    172.16.254.11 172.16.254.10 1

As you can see- no matter which split tunneling config you choose, the vpn client throws a specific route to the VPN gateway (with an equal/better metric) to explicitly go out the local interface. There is something happening with the tunneling where if anything is destined for that address that isn't IPsec encapsulation, it will end up going through the tunnel but with an outgoing address of the local address instead of the VPN tunnel address. This makes it so that the return path for those packets doesn't work if the client is behind a NAT.

I may have some of the details wrong, but that is the observed behavior. I got the response that this is by design from TAC.

[ergotherego]

You were able to confirm that TCP-8013 is running inside of an SSL session? We scanned EMS with Nessus and get no info back for that port. I watched TCP-8013 traffic for awhile, and only see keep-alive type traffic, no actual data.

I am working on standing up a test client so I can connect fresh to EMS and watch that traffic, see if the payload is encrypted.

[Kenundrum]

I can now confirm that the fortitelemetry traffic (default on 8013) is inside an SSL session. I'm currently working on a ticket with TAC where the current theory is that there is some problem with the SSL communication between my clients and fortigate preventing telemetry from connecting.