As we enter the embedded market, clients residing outside the firewall (“out in the cloud”) are becoming more prevalent with devices such as Digital Signs, ATMs and others.   This is a perfect environment for AMT with FCFH  capability to shine.


We know AMT can be complex and adding FCFH  on top does not help.  At the same time, BKMs are scarce.  This high level summary hits on some key points and Gotcha’s when developing a FCFH  based solution.  It also addresses some questions I’ve been getting on FCFH deployment.


The basic & simplified architecture of FCFH solution:

  1. Client calls vPro Enabled Gateway (aka MPS) to trigger a connection
  2. vPro Enabled Gateway authenticates with the client and creates a secure tunnel
  3. vPro Enabled Gateway  notifies Management Console that it holds active connection with the client
  4. Management Console connects to the client through the Gateway.




A key component in this solution is the vPro Enabled Gateway (aka MPS).

The vPro Enabled Gateway  has the following functions:

  1. Respond to client’s request and create secure tunnel
  2. Notify Management Console that connection has been opened (or closed)
  3. Act as a proxy to all ClientßàManagement Console traffic (forward traffic).

The vPro Enabled Gateway has no awareness of the content of the traffic it forwards, but it is aware of type of traffic (HTTP or SOAP) as it needs to route it to the correct service (see next item).


The vPro Enabled Gateway is comprised of three services:

  1. sTunnel – responsible for creating secure connection with the client
  2. MPS – responsible for all SOAP traffic
  3. Apache – Responsible for all HTTP traffic



For simplification, I will refer to the vPro Enabled Gateway as a Black Box and not worry about its internal communication.  I will only discuss its external interfaces:


     1.     Interface to the internet:

    Few conditions must be met for the client to find the vPro Enabled Gateway:

  1. sTunnel listening port:  FQDN:Port#  must be visible on the internet
  2. AMT is configured with Gateway’s FQDN:port# during provisioning
  3. FQDN of the vPro Enabled Gateway must be resolvable

-   Static IP of vPro Enabled Gateway can also be entered but requires additional info in the provisioning profile


     2.     Interface to the enterprise

               vPro Enabled Gateway has two separate connections for communicating with the Management Console

  1. SOAP traffic for  Re-direction & KVM
  2. HTTP for all web services traffic (all other AMT commands)
  3. Management Console listens on a single port for both types of traffic


FCFH  connection with TLS vs, Non-TLS

There is confusion about Non-TLS optoin is in the context of FCFH connection: namely: "How can a client on the internet connect over non-TLS connection? isn't that a serious breach of security"?


Here is clarification:

  1. The connection between the client and vPro Enabled Gateway is always TLS regardless of your TLS choice in the provisioning profile!  even you you choose "No-TLS" in the provisioning prfile.
  2. The Client/Gateway authetnication & encryption is done when the client established conneciton with sTunnel.  This is why we install a web server cert on sTunnel during environment setup and a trusted root cert on every client during provisioning.
  3. The entire connection link between Management Console and AMT client can be either TLS or non-TLS (as defined in the provisioning profile).  If TLS is selected, the Client/Gateway connection which is already TLS (as described above) will be encrypted twice! (TLS on top of TLS).


Certificate Authority Requirement

A FCFH  deployment must have CA in the env.  Reason being: As described above, client and vPro Enabled Gateway must authenticate before connection can be established.  This implies that a web server cert must be installed on the vPro Enabled Gateway, and a Trusted Root Certificate installed on every client.
If the env does not have a CA:  a potential workaround could be to temporarily create a CA, generate the required web server cert & trusted root cert and then shutdown the CA.  The trusted root cert must be available during provisioning.


Commercial Gateway vs SDK gateway

The configuration of SDK gateway is more complex and involved tinkering with three separate configuration files.  Although a configuration GUI based tool is provided, there is still significant learning curve and debugging is a non-trivial task.  Using Commercial product should make the process easier (although I never tried it myself).


Connection Time-Out
I’ve been getting questions about connection timeout.  Concern is “will connection timeoout and close while I am working on a client?”.  The answer is No.
Here is quick background and how connection timeout works:

MPS ability to handle large number of connections is limited (recommended not more than 250 concurrent active connections) which could be an issue in large scale deployments. To control the number of active connections, we define in the Provisioning Profile an ‘idle-timeout’ parameter.  When FCFH  connection is established, AMT timer starts counting down as long as no activity detected on that connection.  Once there is activity, the timer resets.  For example, if idle timeout is 30 minutes, and 25 minutes went by with no activity, then you run some command (ex. check AMT power state), the timer will re-set back to 0 and will start counting down from the moment there is no activity again.  So as long as there is SOME activity on that connection in this 30 minutes window, the connection will remain open.


Connection Notification

I’ve been asked if vPro Enabled Gateway can notify more then on Management Console about connection Opened or Closed.   The answer is yes.   A simple entry in a configuration file will direct connection notification up-to 8 different Management Consoles,  This is useful for development as well as support multiple operators.


Management Console.

Currently, only few management consoles support FCFH connection natively.  Most customers will need to develop some level of scripting to manage their clients over FCFH  connection.   With the introduction of FCFH  support in PowerShell 3.1, this has become a whole lot easier.

However, PowerShell support solves only the Use case implementation aspect.  There is still the issue of tracking connections status: in a large deployment, the operator needs to know which clients have active connections and when clients will re-connect.   A query to the gateway can be performed, but this is not practical and gives only a list of Active connections with no other information.


To address these shortcomings, a FCFH console solution is needed to complete the solution.  We are developing a sample application for demo purposes only (still in early beta, and not for customer use) that features the following capabilities:

  1. List all clients which has currently active connections
  2. When the connection will be timed out (idle-timeout for each connection)
  3. What triggered the connection (User/Event/Scheduler)
  4. Quick access to few use cases
  5. Which clients are currently disconnected
  6. Time left for scheduler to initiate a connection.