Hot!FortiTelemetry for remote users

Author
Kenundrum
Silver Member
  • Total Posts : 110
  • Scores: 6
  • Reward points: 0
  • Joined: 2008/05/15 10:25:50
  • Location: Rhode Island, US
  • Status: offline
2017/11/14 06:47:40 (permalink)
0

FortiTelemetry for remote users

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.

NSE4 (at Accelerate2017!)
Some FGT500Ds, 60Ds at work
FWF60E, FWF80CM, FGT60C, and FWF60B at home
#1

6 Replies Related Threads

    ergotherego
    Silver Member
    • Total Posts : 80
    • Scores: 6
    • Reward points: 0
    • Status: offline
    Re: FortiTelemetry for remote users 2017/11/14 09:41:16 (permalink)
    0
    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.
    #2
    Kenundrum
    Silver Member
    • Total Posts : 110
    • Scores: 6
    • Reward points: 0
    • Joined: 2008/05/15 10:25:50
    • Location: Rhode Island, US
    • Status: offline
    Re: FortiTelemetry for remote users 2017/11/14 10:36:26 (permalink)
    0
    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.

    NSE4 (at Accelerate2017!)
    Some FGT500Ds, 60Ds at work
    FWF60E, FWF80CM, FGT60C, and FWF60B at home
    #3
    Kenundrum
    Silver Member
    • Total Posts : 110
    • Scores: 6
    • Reward points: 0
    • Joined: 2008/05/15 10:25:50
    • Location: Rhode Island, US
    • Status: offline
    Re: FortiTelemetry for remote users 2017/11/16 12:14:08 (permalink)
    0
    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.

    NSE4 (at Accelerate2017!)
    Some FGT500Ds, 60Ds at work
    FWF60E, FWF80CM, FGT60C, and FWF60B at home
    #4
    tanr
    Gold Member
    • Total Posts : 345
    • Scores: 12
    • Reward points: 0
    • Joined: 2016/05/09 17:09:43
    • Status: offline
    Re: FortiTelemetry for remote users 2017/11/16 13:38:36 (permalink)
    0
    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?
    #5
    Kenundrum
    Silver Member
    • Total Posts : 110
    • Scores: 6
    • Reward points: 0
    • Joined: 2008/05/15 10:25:50
    • Location: Rhode Island, US
    • Status: offline
    Re: FortiTelemetry for remote users 2017/11/17 08:35:37 (permalink)
    0
    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.
    post edited by Kenundrum - 2017/11/17 08:40:43

    NSE4 (at Accelerate2017!)
    Some FGT500Ds, 60Ds at work
    FWF60E, FWF80CM, FGT60C, and FWF60B at home
    #6
    ergotherego
    Silver Member
    • Total Posts : 80
    • Scores: 6
    • Reward points: 0
    • Status: offline
    Re: FortiTelemetry for remote users 2017/11/21 09:33:40 (permalink)
    0
    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.
    #7
    Jump to:
    © 2017 APG vNext Commercial Version 5.5