Contents

Implementing a Tachyon DMZ Server

Summary

The process for installing a Tachyon DMZ Server to support Internet-facing Tachyon clients.

Assumptions

The steps given on this page assume:

  • Tachyon is already installed on the internal (corporate) network
  • The Tachyon DMZ Server hosts only the Tachyon Switch and Background Channel components, and is installed in a DMZ
  • If the Tachyon DMZ Server is domain-joined, it is either in the same domain in which the internal Tachyon Server resides, or there is a two-way trust between domains

In our example, the DMZ Server has only one Switch, and the internal Tachyon Server is a single-server configuration with Master and Response Stacks. If your system has different requirements please contact 1E for advice.

Tachyon client devices will be configured to swap between being on the internal network and being external to the network, and therefore will communicate with the internal Tachyon Server when connected internally and the external Tachyon DMZ Server when accessing externally (for example Internet). Tachyon client devices must have the appropriate certificates installed. Please refer to Requirements: Tachyon client certificates for more details.

On this page:

Architecture

Enabling Tachyon to support devices that are external to your company network is done by slightly extending the default single-server architecture.

The Responses Stack handles communications between the Master Stack and the Tachyon clients. The Background Channel and Switches components handle the direct communication with the Tachyon clients, the Core processes the information in both directions between the Master Stack and the Switches.

To enable external Tachyon client devices to interact with Tachyon you need to put the Background Channel and at least one Switch into the DMZ.

Communications ports

The Tachyon communications ports between the Tachyon Master Server and the Tachyon DMZ Server must be opened, as illustrated in the picture shown opposite. Please refer to the Communication Ports page for more details.

Preparation

In the following summary and configuration steps, the following terminology is used:

  • Relevant internal servers
    • Any internal server which hosts a Tachyon Server component which communicates with any DMZ Server
    • Typically this will include the servers which host the Coordinator, the Consumer API, and any Core bound to a DMZ switch that is registered in the dbo.SwitchToCoreApi table in the TachyonMaster database
    • The example diagrams and steps refer to only one internal server, but there may be separate servers for Master Stack (with Coordinator and Consumer API) and Response Stack (with Core). 
  • DMZ Server
    • Any server that has Tachyon Server components installed which is not on the internal network (that is, outside of the corporate network) 
    • This includes a Tachyon DMZ Server (which has one or more Switches and a Background Channel)

You must ensure the following before installation of Tachyon on a DMZ Server.

  • The Tachyon Master Server is installed and verified with internal Tachyon clients. 
    • Please refer to Implementing Tachyon for more details
    • The documentation below assumes this has a Master Stack and Response Stack on the same server. 
    • A Response Stack is required in order to provide the Core component that will be used by the remote DMZ Server. Internal clients are not required to use the Switch and Background Channel of this Response Stack.
  • The DMZ internal and external firewall are configured correctly. Please refer to the Communication Ports page for more details.
  • The Tachyon DMZ Server is provisioned. Although a DMZ Server does not have all Tachyon components, all prerequisites must be met in order for Tachyon Setup to run. In particular, the following must be prepared before installation. For more detail about each requirement, click on the relevant link.
    • Requirements: DNS Names (Preparation: DNS Names)
      • The DMZ Server requires two DNS Names, even if the DMZ Server is configured with one network interface. Two network interfaces are required to prevent response traffic from clients to server, and from server to Core, using the same network interface.
      • A DMZ Server internal DNS Name so that the internal Tachyon Server can connect to the DMZ Server. Documentation below assumes this DNS Name exists, but it can alternatively be the server's hostname FQDN.
      • A DMZ Server external DNS Name so that Internet devices can connect to the DMZ Server, which is the name included in the Tachyon client configuration for Switch and Background Channel settings (1E Client configuration file). This DNS Name is not necessarily for the actual IP Address(es) of the external network interfaces if DMZ firewall, Network Address Translation (NAT) or other routing is employed.
      • Both DNS Names must be included in the Web server certificate. Please see Certificate requirements below for more information on certificate DNS Name requirements.
      • If DMZ Server is domain-joined, both DNS Names require an HTTP class Service Principal Name (SPN) registered on the DMZ Server's computer$ account. Please refer to Preparation: Service Principal Names for more details.
    • Requirements: Network interfaces (Preparation: Network interfaces)
      • The DMZ Server should have an internal network interface, and an external network interface for each Switch, in order to keep Core and Switch traffic apart. This recommendation is for performance reasons when supporting over 500 devices.
      • If an internal interface is not used, then the external interface will use both DNS Names.
      • If using two interfaces...
        • the internal interface will use the internal DNS Name, and the external interface(s) will use the external DNS Name. This is the assumption made in the configuration steps below.
        • internal and external interfaces will typically be on different subnets.
        • ensure your network routing is configured to route outgoing traffic using the internal interface. You may need to configure a persistent route, for example using the same steps described in Preparation: Configuring a persistent route for SQL traffic.
    • Requirements: Tachyon Server Certificates (Preparation: Web server certificate)
      • Each DMZ Server requires its own web server certificate. Please see Certificate requirements below for more information.
    • Requirements: Windows Server roles and features (Preparation: Windows Server roles and features)
      • IIS to host the Background Channel application.
      • Windows Authentication role if the server is domain joined and has a trust relationship with the domain that the Master Stack is configured to use.
  • Test devices with the Tachyon client installed.
    • At least one connected to the internal network; another connected to the external network.

Certificate requirements

Tachyon Server certificate requirements are defined in Requirements: Tachyon Server certificates.

 Click here to expand details of Tachyon Server certificate requirements...

Each server that has Tachyon Server components installed requires its own Web Server certificate (except for a remote SQL Server). This certificate is also used by the Tachyon Switch and the Tachyon Coordinator. Therefore, a single-server installation requires only one Web Server certificate. This certificate must be provided prior to installation of Tachyon on the server.

Certificate requirements for standard servers

The Web Server certificate requires the minimum of the following:

  1. Issued by a trusted Certificate Authority (CA)
    • The certificate for the Root CA in the Certification Path must exist in the Trusted Root CA store of the server
    • If the issuing CA is not the Root CA then the certificate for the issuing CA and any intermediate CA in the Certification Path must exist in the Intermediate CA store of the server
    • The above CA certificates must exist on the Tachyon Web Server and Windows client devices
    • Most organizations have automated distribution of these CA certificates to servers and clients, using Group Policy for example.
  2. Has at least the following Key Usage:
    • Digital signature
    • Key encipherment
  3. Has at least the following Enhanced Key Usages:
    • Server Authentication
  4. Revocation information is included
    • References at least one CRL Distribution point that uses HTTP
  5. Must have a private key available

The default template Web Server available with a Microsoft PKI is suitable for requesting a Tachyon Web Server certificate.

Tachyon systems that have DMZ Servers may have additional requirements, please refer to Implementing a Tachyon DMZ Server.

Tachyon clients and Switches use OpenSSL and its validation process to verify certificates.

Web Server certificates used by a Tachyon Servers must be issued with their fields set as follows:

FieldsExample
Subject Alternative Name Extension (extensions:subjectAltName), type dnsName

The Tachyon Server DNS Name FQDN (DNS Alias) of the server.

Example: DNS Name=TACHYON.ACME.LOCAL

On a Master Stack, this is used by browsers, consumers, remote Tachyon Servers, and clients using ActiveEfficiency, Application Migration, or AppClarity Software Reclaimer.

On a Response Stack or DMZ Server, this is used by Tachyon clients.

Subject Alternative Name Extension (extensions:subjectAltName), type dnsName

An Alternate DNS Name FQDN (DNS Alias) of the server.

Example: DNS Name=TACHYONALT.ACME.LOCAL

An Alternate DNS Name is required for any server hosting a Switch (Response Stack or DMZ Server) if the server has multiple IP Addresses. It is used for internal Tachyon communications between Switches and other Tachyon components.

An Alternate DNS Name is optional for a server hosting a Master Stack if you want an alternate DNS Name for clients using ActiveEfficiency, Application Migration, or AppClarity Software Reclaimer.

For more detail about setting up a DMZ Server, please refer to Implementing a Tachyon DMZ Server .

Example

Earlier versions of Tachyon required the certificate to have a CN and used SAN fields differently. If you are upgrading your Tachyon server from an earlier version it may still be using this type of certificate. When upgrading Tachyon, you can issue a replacement certificate, or continue using the old style certificate (because the new-style certificate requires only a SAN DNS Name that matches the DNS Alias, which are provided by the old style certificates).
 Click here to see examples of old-style certificates...
FieldsExample old Option 2 type certificate
Subject Common Name Field (subject:commonName)

The hostname FQDN of the server

Example: CN=ACME-TCN01.ACME.LOCAL

Subject Alternative Name Extension (extensions:subjectAltName), type dnsName

The DNS Alias FQDN of the server

Example: DNS Name=TACHYON.ACME.LOCAL

Add any additional DNS Names here.
Example certificate request

Option 2 type certificates required the CN to be the hostname FQDN, and the list of Subject Alternate Names (SAN) to contain the DNS Alias.

Also, prior to Tachyon 5.0 the certificate required its private key to be exportable.

Tachyon 5.0 is able to use this type of certificate when upgrading from an earlier version of Tachyon.

FieldsExample of old Option 1 type certificate
Subject Common Name Field (subject:commonName)

The DNS Alias FQDN of the server

Example: CN=TACHYON.ACME.LOCAL

Subject Alternative Name Extension (extensions:subjectAltName), type dnsName

The DNS Alias FQDN of the server

Example: DNS Name=TACHYON.ACME.LOCAL

The hostname FQDN of the server

Example: DNS Name=ACME-TCN01.ACME.LOCAL

Example certificate request

Option 1 type certificates required the CN to be the DNS Alias, and the list of Subject Alternate Names (SAN) to contain the hostname FQDN.

Also, prior to Tachyon 5.0 the certificate required its private key to be exportable.

Tachyon 5.0 is able to use this type of certificate when upgrading from an earlier version of Tachyon.

Tachyon DMZ Server installations have additional requirements for its certificates.

Relevant internal servers

TypeAdditional certificate requirementsWhere used
Tachyon Server certificate

The server certificate must comply with certificate requirements for standard servers (see above) with the additional requirement of two DNS Names to be present in the certificate to support a remote DMZ Server.

  • A Subject Alternative Name Extension (extensions:subjectAltName), of type dnsName, which must contain:
    • Tachyon Server DNS Name FQDN - in our example tachyon.acme.local
    • Alternate DNS Name FQDN - in our example tachyonalt.acme.local

This is the usual Tachyon website certificate.

A DMZ Server installation has additional needs to allow Switches on the DMZ Server to communicate with:

  • Tachyon Master Stack (Coordinator)
  • Tachyon Response Stack (Core)
Tachyon Consumer API client certificate

The client certificate on the Tachyon Master Stack has the following requirements:

  1. Issued by a trusted Certificate Authority (CA)
    • The certificate for the Root CA in the Certification Path must exist in the Trusted Root CA store of the server
    • If the issuing CA is not the Root CA then the certificate for the issuing CA and any intermediate CA in the Certification Path must exist in the Intermediate CA store of the server
    • If the above CA certificates are different to those used by the DMZ Server, they will need to be exported and then imported on the DMZ Server
  2. Has at least the following Enhanced Key Usage
    • Client Authentication (OID 1.3.6.1.5.5.7.3.2)
  3. Has a private key
  4. Revocation information is included.
    • References at least one CRL Distribution point that uses HTTP.
  5. A Subject Alternative Name Extension (extensions:subjectAltName), of type dnsName, which must contain at least one of the following:
    • Tachyon Server DNS Name FQDN - in our example tachyon.acme.local
    • Alternate DNS Name FQDN - in our example tachyonalt.acme.local
    • Tachyon Server Hostname FQDN - in our example ACME-TCNMST.acme.local

You will need the thumbprint for this certificate. In our example, this is 545EF2AF74201A8CFAE0F0CEFE2D987237AEC176.

Used by the Tachyon Master Stack (Consumer API) to perform client authentication with the Background Channel on the DMZ Server.

Required only if certificate authentication is used instead of domain authentication.

This certificate is only used if your DMZ Server is not domain-joined, or does not have a two-way trust between your internal domain and your DMZ domain.




DMZ Server

TypeAdditional certificate requirementsWhere used
DMZ Server certificate

The Certificate requirements for standard servers (see above) requires two DNS Names which must be present in the certificate if the server has multiple IP Addresses. This is a requirement for a DMZ Server. theefore the However, a DMZ Server requires an additional DNS Name separate communications between internal and external Switches:

The Certificate requirements for standard servers are valid with regard to trust, usage, enhanced key usage, the private key, and revocation. However, as this is an externally reachable certificate, it is not recommended that the hostname FQDN is present in the certificate. As such, the certificate must meet the following requirements:

  • A Subject Alternative Name Extension (extensions:subjectAltName), of type dnsName, which must contain:
    • DMZ Server external DNS Name FQDN - in our example: tachyon.acme.com
    • DMZ Server internal DNS Name FQDN - in our example  tachyondmz.acme.local

Optionally, it may also contain a Subject Common Name Field (subject:commonName) that is unique within the organization that identifies the certificate (https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf#page=54). 

Used by the Switch(es) and Background Channel to secure communication to Tachyon clients.
DMZ Server client certificate

The client certificate on the Tachyon DMZ Server has the following requirements:

  1. Issued by a trusted Certificate Authority (CA)
    • The certificate for the Root CA in the Certification Path must exist in the Trusted Root CA store
    • If the issuing CA is not the Root CA then the certificate for the issuing CA and any intermediate CA in the Certification Path must exist in the Intermediate CA store
    • If the above CA certificates are different to those used by the Tachyon Master Stack server, they will need to be exported and then imported on the Tachyon Web Server
  2. Has at least the following Enhanced Key Usage
    • Client Authentication (OID 1.3.6.1.5.5.7.3.2)
  3. Has a private key
  4. Revocation information is included.
    • References at least one CRL Distribution point that uses HTTP.
  5. A Subject Alternative Name Extension (extensions:subjectAltName), of type dnsName, which must contain:
    • DMZ Server internal DNS Name FQDN - in our example tachyondmz.acme.local
Used by Switch(es) to perform client certificate authentication with its assigned Response Stack (Core).

Certificate trust

The relevant internal servers must trust the DMZ Server certificate(s). In order to do so, ensure the DMZ Server certificate(s)' issuing chain is imported into the Local Machine's Trusted Root Certification Authority or Intermediate Certification Authorities stores (as appropriate) on each relevant internal server.

The DMZ server must trust the relevant internal servers' certificate(s). In order to do so, ensure the relevant internal servers' certificate(s) issuing chain is imported into the Local Machine's Trusted Root Certification Authority and Intermediate Certification Authorities (as appropriate) stores on the DMZ Servers.

The DMZ server must also trust the Tachyon clients' certificates. In order to do so, ensure the relevant clients' certificate(s) issuing chain is imported into the Local Machine's Trusted Root Certification Authority and Intermediate Certification Authorities (as appropriate) stores on the DMZ Servers.

Please note that if any certification authority in this file have a HTTP CDP they must be reachable by the DMZ Server. Further information on this can be found in the note below.

If the certificates on the DMZ Server and the internal Tachyon servers are from different issuing CAs, then:

  • Obtain the certificates (public keys only) for all the intermediate CAs, up to and including the Root CA of the internal Tachyon Server's Web Server Certificate, and add them to the corresponding CA stores on the DMZ Server. If you do not do this, the Switch on the DMZ Server will not be able to start because it won't be able to trust the Core API on the relevant internal server.

Similarly, if the certificates on the DMZ Server and client authentication certificates on external Tachyon clients are from different issuing CAs, then:

  • Obtain the device's intermediate and root CA certificates, and add them to the corresponding CA stores on the DMZ Server.
  • Windows devices will need the Tachyon DMZ Server's intermediate and root CA certificates to be added to their CA stores
  • Non-windows devices will need the Tachyon DMZ Server's intermediate and root CA certificates to be added to their cacert.pem file

The installation process for a Tachyon DMZ Server

Overview

The process requires several manual steps before and after running Tachyon Setup, because the automated process is prevented by the DMZ Server not having access to the Tachyon Master database on the internal server. These steps include defining the cfgName used in the SwitchCommandLine for each Switch, which maps to a new row created in the SwitchConfiguration table in the Tachyon Master database. For more details about cfgName please refer to the Switch Command Lines page. In addition, the steps include increasing the level of security by changing the system so that all Switches connect to the Core API using HTTPS instead of HTTP (a remote Core is only accessible via HTTPS). The Background Channel is then initialized before finally carrying out verification steps to ensure everything is working.

One of the steps involves adding a new Background Channel. From that point onwards, you will not be able to update existing Background Channels until you have completed all steps. This means you cannot add or remove any instructions that use resources.

To illustrate the following detailed steps we use the ACME network with two servers.


DNS Names

Use the following table to help map the DNS Names used in your environment with the name used in the steps below.

ServerDNS Name referencesDNS Name examplesDNS Names used in your environment

The internal Tachyon Server

The diagram shows only relevant components of the Master Stack and Response Stack

Tachyon Server hostname FQDNACME-TCNMST.acme.local
Tachyon Server DNS Name FQDNtachyon.acme.local
Alternate DNS Name FQDNtachyonalt.acme.local
The external Tachyon DMZ ServerDMZ Server hostname FQDNACME-TCNDMZ
DMZ Server internal DNS Name FQDNtachyondmz.acme.local

DMZ Server external DNS Name FQDN

(this name is only used by clients and only mentioned in the instructions below when configuring the bindings on the DMZ Server)

tachyon.acme.com

Detailed steps

Do all the steps if your DMZ Server is not domain-joined, or does not have a two-way trust between your internal domain and your DMZ domain.

Skip the highlighted steps if your DMZ server is domain joined and has a two-way trust between your internal domain and your DMZ domain.


LocationDetailed steps
1Internal Tachyon Server (Master and Response Stacks) and internal Tachyon client(s).

Install the internal Tachyon Server, with Master and Response Stacks, and ensure it works by  running the tests described in Verifying.


2DMZ Server.

Ensure Preparation steps are complete for the Tachyon DMZ Server.

 Expand to see overview of preparation steps...

You must ensure the following before installation of Tachyon on a DMZ Server.

  • The Tachyon Master Server is installed and verified with internal Tachyon clients. 
    • Please refer to Implementing Tachyon for more details
    • The documentation below assumes this has a Master Stack and Response Stack on the same server. 
    • A Response Stack is required in order to provide the Core component that will be used by the remote DMZ Server. Internal clients are not required to use the Switch and Background Channel of this Response Stack.
  • The DMZ internal and external firewall are configured correctly. Please refer to the Communication Ports page for more details.
  • The Tachyon DMZ Server is provisioned. Although a DMZ Server does not have all Tachyon components, all prerequisites must be met in order for Tachyon Setup to run. In particular, the following must be prepared before installation. For more detail about each requirement, click on the relevant link.
    • Requirements: DNS Names (Preparation: DNS Names)
      • The DMZ Server requires two DNS Names, even if the DMZ Server is configured with one network interface. Two network interfaces are required to prevent response traffic from clients to server, and from server to Core, using the same network interface.
      • A DMZ Server internal DNS Name so that the internal Tachyon Server can connect to the DMZ Server. Documentation below assumes this DNS Name exists, but it can alternatively be the server's hostname FQDN.
      • A DMZ Server external DNS Name so that Internet devices can connect to the DMZ Server, which is the name included in the Tachyon client configuration for Switch and Background Channel settings (1E Client configuration file). This DNS Name is not necessarily for the actual IP Address(es) of the external network interfaces if DMZ firewall, Network Address Translation (NAT) or other routing is employed.
      • Both DNS Names must be included in the Web server certificate. Please see Certificate requirements below for more information on certificate DNS Name requirements.
      • If DMZ Server is domain-joined, both DNS Names require an HTTP class Service Principal Name (SPN) registered on the DMZ Server's computer$ account. Please refer to Preparation: Service Principal Names for more details.
    • Requirements: Network interfaces (Preparation: Network interfaces)
      • The DMZ Server should have an internal network interface, and an external network interface for each Switch, in order to keep Core and Switch traffic apart. This recommendation is for performance reasons when supporting over 500 devices.
      • If an internal interface is not used, then the external interface will use both DNS Names.
      • If using two interfaces...
        • the internal interface will use the internal DNS Name, and the external interface(s) will use the external DNS Name. This is the assumption made in the configuration steps below.
        • internal and external interfaces will typically be on different subnets.
        • ensure your network routing is configured to route outgoing traffic using the internal interface. You may need to configure a persistent route, for example using the same steps described in Preparation: Configuring a persistent route for SQL traffic.
    • Requirements: Tachyon Server Certificates (Preparation: Web server certificate)
      • Each DMZ Server requires its own web server certificate. Please see Certificate requirements below for more information.
    • Requirements: Windows Server roles and features (Preparation: Windows Server roles and features)
      • IIS to host the Background Channel application.
      • Windows Authentication role if the server is domain joined and has a trust relationship with the domain that the Master Stack is configured to use.
  • Test devices with the Tachyon client installed.
    • At least one connected to the internal network; another connected to the external network.

 Expand to see guidance when DMZ Server is using different CA certificates to the internal Tachyon server or clients...

If the certificates on the DMZ Server and the internal Tachyon servers are from different issuing CAs, then:

  • Obtain the certificates (public keys only) for all the intermediate CAs, up to and including the Root CA of the internal Tachyon Server's Web Server Certificate, and add them to the corresponding CA stores on the DMZ Server. If you do not do this, the Switch on the DMZ Server will not be able to start because it won't be able to trust the Core API on the relevant internal server.

Similarly, if the certificates on the DMZ Server and client authentication certificates on external Tachyon clients are from different issuing CAs, then:

  • Obtain the device's intermediate and root CA certificates, and add them to the corresponding CA stores on the DMZ Server.
  • Windows devices will need the Tachyon DMZ Server's intermediate and root CA certificates to be added to their CA stores
  • Non-windows devices will need the Tachyon DMZ Server's intermediate and root CA certificates to be added to their cacert.pem file

3

Internal Tachyon Server (Master Stack).

On the internal Tachyon Server (Master Stack)

Add another HTTPS binding to the Tachyon website. In our example this is https://tachyonalt.acme.local:443

Remember this binding for steps 5, 8 and 21.
  1. On the internal Tachyon Server, open IIS Management Console 
  2. Expand Sites and right-click on the Tachyon website
  3. Under the Edit Site actions, click on Bindings...
  4. Click Add...
  5. Select type https
  6. Set the Host name to the Alternate DNS Name - see table above
  7. Enable Require Server Name Indication
  8. Select the SSL certificate to be the same certificate as the existing HTTPS binding, ensuring it is the certificate with SAN entries for Tachyon Server DNS Name FQDN and Alternate DNS Name FQDN
  9. Click OK to save, and Close
4

Internal Tachyon Server (Master Stack).

Only when not domain-joined, or is untrusted.

Skip this step if domain-joined and trusted.

On the internal Tachyon Server (Master Stack)

Ensure the service account used by the Consumer API web application pool has read permission for the Tachyon Consumer API client certificate. By default the service account is Network Service.

  1. Start certlm.msc
  2. Expand the Personal folder, and then select Certificates
  3. Right-click on your Tachyon Consumer API client certificate and select All Tasks, then click Manage Private Keys
  4. Click Add, and type in NT AUTHORITY\Network Service into the Enter the object names to select box
  5. Click OK, and ensure the newly added Network Service has read permission
  6. Click OK.
  7. Remember this certificate's thumbprint (without hidden characters or spaces), it will used be in steps 7 and 15. For example: 545EF2AF74201A8CFAE0F0CEFE2D987237AEC176
5

Internal TachyonMaster database.

In the TachyonMaster database, modify the CoreApiConfiguration table to use HTTPS Core instead of the default HTTP CoreInternal.
  1. Change BaseURL to point to the Core web application using the new HTTPS binding created in step 3. In our example this would change the value
    • from  http://ACME-TCNMST.acme.local:80/CoreInternal/
    • to https://tachyonalt.acme.local:443/Core/
  2. Remember the Id of this row (normally 1)
6

Internal TachyonMaster database.

In the TachyonMaster database, register each Switch planned for the DMZ Server, even though you have not yet installed the DMZ Server. One Switch will be required for every 50,000 clients connected to the DMZ Server at any one time, up to a maximum of 5 Switches.

  1. For each Switch on the Tachyon DMZ Server, create a new row in the SwitchConfiguration table by copying the * (asterisk) row.

    1. Remember the Id of each new row

    2. Change Name to <SwitchHostname>-SWn where SWn is the Switch suffix number 1 to 5. In our example this should be changed:

      • from * (asterisk)
      • to  ACME-TCNDMZ-SW1 (this name will be used in step 19 as the -cfgName you will add to the SwitchCommandLine of the Tachyon.Switch.Host.exe.Config file on the DMZ Server)

    3. Change IpAddress to the IP address of the external network interface on which this Switch should listen for connections from the Clients. In our example, this would match the IP address assigned in DNS to tachyon.acme.com . 

      If you leave this field set to its default value of NULL, it will cause each Switch to listen on all the addresses available to the DMZ server. You must specify an ipAddress if you have more than one Switch. You must also specify an ipAddress for the Switch if you are using a seperate interface to communiacte with internal Tachyon servers as shown in the DNS Names picture above.

       Expand to see DNS Names picture...

    4. Change InstrumentationUrl to the hostname FQDN or alternate DNS Name of the internal server hosting the Tachyon Coordinator (typically the Master Stack). In our example this should be changed:
      • from  http://localhost:3901/SwitchInstrumentation
      • to      https://tachyonalt.acme.local:3901/SwitchInstrumentation
    5. Change InstructionsUrl
      • from  https://tachyon.acme.local:443/Consumer/Instructions
      • to      https://tachyonalt.acme.local:443/Consumer/Instructions
    6. Do not change SummmaryUrl
      • Leave as: http://localhost:3902/ (not used - only required if using the 1E Summarizer testing tool)
  2. For each Switch on the Tachyon DMZ Server, create a new row in the SwitchToCoreApi table that maps the DMZ Switch to the internal Core.
    • Set SwitchConfigurationId to the Id of the new entry in the SwitchConfiguration table
    • Set CoreApiConfigurationId to the Id of the existing entry in the CoreApiConfiguration table (normally 1)
7

Internal TachyonMaster database.

In the TachyonMaster database, register the name of each new Background Channel.

  1. For the Background Channel on the DMZ Server, create a new row in the BackgroundChannelApiConfiguration table:
    • Set ResourceDirectory as 'Placeholder.Field.Not.Currently.Used'
    • Set ResourceUrl as the DMZ Server internal DNS Name FQDN. In our example is: https://tachyondmz.acme.local:443/Background/
    • If you completed step 4 (for non-domain-joined) then set UseCertificateForAuthentication (default NULL) as the thumbprint of the Tachyon Consumer API client certificate. For example: 545EF2AF74201A8CFAE0F0CEFE2D987237AEC176
8

Internal Tachyon Server (Response Stack).

On the internal Tachyon Server (Response Stack)

Modify the existing Switch host configuration file to use the HTTPS binding set up step 3.

  1. In the Tachyon installation Switch folder, locate and edit the Tachyon.Switch.Host.exe.config file
  2. Modify the CoreUrl key to use HTTPS and the internal Tachyon DNS Name FQDN, in our example the change would be:
    • from <add key="CoreUrl" value="http://ACME-TCNMST.acme.local:80/CoreInternal"/>
    • to     <add key="CoreUrl" value="https://tachyonalt.acme.local:443/Core"/>
  3. For each internal Switch, modify its SwitchCommandLine.n to change the -config to use HTTPS and the internal Tachyon Server DNS Name FQDN, and Core instead of CoreInternal. In our example the change would be:
    • from <add key="SwitchCommandLine.1" value="-cfgName=ACME-TCNMST-SW1 -config=ACME-TCNMST.acme.local:80/CoreInternal -NoStdOut -NoSumm -NoSw2Sw -Log=INFO" />

    • to     <add key="SwitchCommandLine.1" value="-cfgName=ACME-TCNMST-SW1 -config=https://tachyonalt.acme.local:443/Core -NoStdOut -NoSumm -NoSw2Sw -Log=INFO" />

If -cfgName is not already present in the SwitchCommandLine, then do not add it, you only need to change the -config value.

If you have multiple switches, ensure you modify each SwitchCommandLine.n entry in the configuration file.

The command-line will include -IgnoreClientCerts if you unchecked Switches require client certificates to be presented by Tachyon Agents in Tachyon Setup.

9

Internal Tachyon Server (Response Stack).

On the internal Tachyon Server (Response Stack) that the DMZ Server will be communicating with, modify the IP Address and Domain Restrictions module in the Tachyon Core web application to enable the IP Address of the DMZ Server internal DNS Name to access the internal Core.

  1. On the internal Tachyon Server (Response Stack), open IIS Management Console
  2. Expand Sites and navigate to and expand the Tachyon website
  3. Click on the Core application and double-click on IP Address and Domain Restrictions
  4. Add the IP address of the DMZ Server internal DNS Name to the IP Address and Domain Restrictions (including IPv6 address if used)

Please refer to Implementation issues: IP address and domain restrictions for more details. This step is only required on the Core web application. It not required on other web applications because they allow communication from any exernal device, by default.

On the internal Tachyon Server (Response Stack) open a command prompt and ping the DMZ Server internal DNS Name. In our example this is tachyondmz.acme.local . This should prove that the name is resolved and provide the IP Address, even if you do not get a response because the firewall is blocking ICMP.

10

Internal Tachyon Server (Response Stack).

On the internal Tachyon Server (Response Stack), restart all Switches and confirm they are working.

  1. Restart the 1E Tachyon Switch Host service
  2. Ensure all internal Switches are running
  3. In Tachyon Explorer, confirm that at least one internal Tachyon client is connected.
11

Internal Tachyon Server (Master and Response Stacks) and internal Tachyon client(s).

Ensure that everything is still working by running the tests described in Verifying.

12

DMZ Server.

On the Tachyon DMZ Server

On the Tachyon DMZ Server, run Tachyon Setup and complete the installation using the configuration option DMZ Server.

If you are using internal and external network interfaces on the DMZ Server, then ensure you select an external interface IP Address for each Switch in the Switch Configuration screen. 

 Expand to see Tachyon Setup Switch Configuration...


Switch configuration

This screen displays a list of IP Addresses that can be assigned to each Switch in your configuration. Tachyon Setup will estimate how many Switches are required for the number of devices selected in the earlier setup screen and try to assign an IP Address for each. You will need to confirm or change which IP Address is used by each Switch.

IPv6

The screen only displays a list of IPv4 IP Addresses available on the server. If you need to use IPv6 and have a functioning IPv6 network infrastructure then please contact 1E for further advice on how to use this screen.

Ideally to maximize the performance of Tachyon you should have the following configuration:

  • You have enough Switches configured to support the selected number of devices. You can add additional Switches by clicking extra checkboxes, if you have enough IP Addresses configured.
  • One interface per Switch (interfaces may have more than one associated IP Address, so you'll need to check the MAC Addresses to make sure that the IP Addresses are on different interfaces).
  • An additional interface if you have a remote SQL Server and a dedicated connection to the SQL instance.

However in a lab or other environment which has less than 500 devices, you can have all components using a single IP Address.

If you have a local installation of SQL Server, then Used for SQL will show No for all IP Addresses, and you can select whichever IP Address you wish to for each Switch.

If you are using a remote SQL Server, then Used for SQL will show Yes for the IP Address which was used in the earlier screen to validate connection to the SQL Server you selected for the Responses database. If you have configured a dedicated network interface for your SQL connection and Setup has not selected it, then you will need to change the IP Routing table on the server, or reconfigure the connection so that your selected IP Address is used by SQL.

For an installation with multiple Switches, aside from each selected IP Address, all Switches will have an identical configuration.

Click Validate to check that your selection conforms to the best practice rules for configuring switches.

Once the selection has been validated, click Next to continue.

The workflow in Tachyon Setup has not yet been optimized for installing just the Switch and Background Channel components (selectable as DMZ Server). Specifically:

  • In the Database servers screen - options on this screen are greyed out - configuration settings are not required 
  • In the Website configuration screen - specify the HTTPS Host Header as the Internal DNS Name of the DMZ Server: tachyondmz.acme.local

You will manually add the binding for the client (external) DNS Name in the next step.

13

DMZ Server.

After installation, on the Tachyon DMZ Server, add an additional HTTPS binding for external client devices to use.

  1. On the Tachyon DMZ Server, open IIS Management Console
  2. Expand Sites and navigate to and expand the Tachyon  website
  3. Under the Edit Site actions, click on Bindings...
  4. Click Add...
  5. Select type https
  6. Set the Host name to the DMZ Server external DNS FQDN. In our example his would be: tachyon.acme.com
  7. Enable Require Server Name Indication
  8. Select the SSL certificate to be the DMZ Server certificate (described above, in DMZ Server certificate)
  9. Click OK to save, and Close
14

DMZ Server.

Allow the internal Master Stack server to use domain credentials to access the DMZ Server's Background Channel.

Only do this step if the DMZ Server is domain joined and there is two-way trust between your internal domain and your DMZ domain, otherwise do all the steps highlighted below to use certificates instead of domain credentials.

On the DMZ Server, configure AllowedUsers on the Background Channel web application.

  1. Expand Sites then navigate to and expand the Tachyon website
  2. Click on Background and double-click on the Application Settings icon
  3. In the Application Settings view, double-click on the AllowedUsers value
  4. In the Edit dialog, append to the list the domain computer account of the internal Tachyon Server, and click OK. In our example this would be: 
    • from NT AUTHORITY\Network Service;ACME\ACME-TCNDMZ$
    • to     NT AUTHORITY\Network Service;ACME\ACME-TCNDMZ$;ACME\ACME-TCNMST$
15

DMZ Server

Only when not domain-joined, or is untrusted.

Skip this step if domain-joined and trusted.

Allow the internal Master Stack server to use certificates to access the DMZ Server's Background Channel. You will use the thumbprint from step 4.

On the DMZ Server, configure AllowedUsers on the Background Channel web application.

  1. Expand Sites then navigate to and expand the Tachyon website
  2. Click on Background and double-click on the Application Settings icon
  3. In the Application Settings view, double-click on the AllowedUsers value
  4. In the Edit dialog, append to the list the Tachyon Consumer API client certificate thumbprint from step 4, and click OK. In our example this would be: 
    • from NT AUTHORITY\Network Service;
    • to     NT AUTHORITY\Network Service;545EF2AF74201A8CFAE0F0CEFE2D987237AEC176
16

DMZ Server

Only when not domain-joined, or is untrusted.

Skip this step if domain-joined and trusted.

Enable Require client authentication on the Background Channel web application.

This step changes SSL Settings for the parent, and the next step will change the same setting for specific child directories. 

  1. On the Tachyon DMZ Server, open IIS Management Console 
  2. Expand Sites and navigate to and expand the Tachyon website
  3. Click on Background and double-click on the SSL Settings feature
  4. Ensure the Require SSL box is checked and that the Require radio button is selected
  5. In the Actions pane, click Apply
17

DMZ Server

Only when not domain-joined, or is untrusted.

Skip this step if domain-joined and trusted.

For the Background Channel web application, enable Ignore client authentication on virtual directories: Content, Installers, PolicyDocuments and Updates.

  1. On the Tachyon DMZ Server, open IIS Management Console
  2. Expand the Tachyon website, and expand Background application
  3. Repeat the following steps for each of the virtual directories: Content, Installers, PolicyDocuments and Updates:
    1. Double-click on the SSL Settings feature
    2. Ensure the Require SSL box is checked and that the Ignore radio button is selected
    3. In the Actions pane, click Apply

Do not change any settings for the bin directory.

18

DMZ Server

Only when not domain-joined, or is untrusted.

Skip this step if domain-joined and trusted.

Increase the uploadReadAheadSize setting for the Background Channel.

On a DMZ Server that is not domain-joined, Background Channel requires this to support certificate authentication, which is not required for a domain-joined server which uses Windows Integrated Authentication.

  1. On the Tachyon DMZ Server, open IIS Management Console 
  2. Expand Sites and navigate to and expand the Tachyon website
  3. Click on Background and double-click on the Configuration Editor icon
  4. In the Section drop-down, select system.web/httpRuntime and make a note of maxRequestLength value (the default is 262144 Kbytes but it may have been changed since installation)
  5. In the Section drop-down, select system.webServer/serverRuntime and change the uploadReadAheadSize setting from the default 49152 to 268435456 (this is maxRequestLength in bytes = 262144 x 1024)
  6. In the Actions pane, click Apply
19

DMZ Server

Only when not domain-joined, or is untrusted.

Skip this step if domain-joined and trusted.

Create a Policy virtual directory for the Background Channel.

  1. On the Tachyon DMZ Server, open IIS Management Console
  2. Expand Sites and navigate to and click on the Tachyon website
  3. Right click on Background and select Add Virtual Directory...
  4. Set the Alias to Policy and the Physical Path to the Background Channel folder, by default this is C:\ProgramData\1E\Tachyon\PolicyDocuments
  5. Click OK
  6. Click on the newly created Policy virtual directory in the Connections pane
  7. Double-click on the SSL Settings icon
  8. Ensure Require SSL is checked and that the Ignore radio button is selected under Client certificates
20

DMZ Server.

Perform an IIS Reset on the DMZ Server.
21

DMZ Server.

Modify the Switch host configuration file on the Tachyon DMZ Server to use the HTTPS binding set up in step 3.

On the Tachyon DMZ Server, in the Tachyon installation directory Switch folder, modify the Tachyon.Switch.Host.exe.config file:

  1. Locate and edit the Tachyon.Switch.Host.exe.config file
  2. Modify the CoreUrl key to use HTTPS with the new HTTPS binding created for the Response Stack in step 3. In our example the change would be:
    • from <add key="CoreUrl" value="http://ACME-TCNDMZ/CoreInternal"/>

    • to     <add key="CoreUrl" value="https://tachyonalt.acme.local:443/Core"/>

      Before editing, the values for CoreURL and SwitchCommandLine may include a FQDN such as .acme.local  and a port number such as :80. You do not need to include standard port number 443 if that is what you are using.

  3. For each external Switch, modify its SwitchCommandLine.n to change the -config to use HTTPS and the new HTTPS binding created in step 3, and Core instead of CoreInternal. In our example the change would be:
    • from <add key="SwitchCommandLine.1" value="-cfgName=ACME-TCNDMZ-SW1 -config=ACME-TCNDMZ:80/CoreInternal -NoStdOut -NoSumm -NoSw2Sw -Log=INFO" />

    • to     <add key="SwitchCommandLine.1" value="-cfgName=ACME-TCNDMZ-SW1 -config=https://tachyonalt.acme.local:443/Core -NoStdOut -NoSumm -NoSw2Sw -Log=INFO" />

      Confirm the cfgName is the same name you registered in step 6.1.b

      By default, Tachyon Setup uses the naming convention -cfgName=<ServerHostname-SWn>. You must add the equivalent of -cfgName=ACME-TCNDMZ-SW1 if it is not already present in the SwitchCommandLine.

      The command-line will include -IgnoreClientCerts if you unchecked Switches require client certificates to be presented by Tachyon Agents in Tachyon Setup.

      If SwitchCommandLine.n is commented out in the XML file, uncomment it and fill-in the content by copying from SwitchCommandLine and making the changes indicated above. In our example the change would be:

    •  from <!-- <add key="SwitchCommandLine.1" value="-example"/> -->

    • to <add key="SwitchCommandLine.1" value="-cfgName=ACME-TCNDMZ-SW1 -config=https://tachyonalt.acme.local:443/Core -NoStdOut -NoSumm -NoSw2Sw -Log=INFO" />
  4. Repeat the above step for each additional Switch.
22

DMZ Server.

Restart the 1E Tachyon Switch Host service on the DMZ Server, and then ensure all DMZ Switches are running.

Review the Switch.Host.log files.

23

Internal Tachyon Server (Response Stack) and DMZ Server.

Copy existing Background Channel content from the internal Tachyon Server to the Tachyon DMZ Server:

  1. On the DMZ Server, verify that NETWORK SERVICE has Modify rights on the %PROGRAMDATA%\1E folder, and this is inherited by each of its subfolders.
  2. Copy the content (minus the web.config file) from each of the following directories on the internal Tachyon Server (Response Stack) to the equivalent directory on the DMZ Server. This is the default location.
    • %PROGRAMDATA%\1E\Tachyon\Content 
    • %PROGRAMDATA%\1E\Tachyon\Installers
    • %PROGRAMDATA%\1E\Tachyon\PolicyDocuments
    • %PROGRAMDATA%\1E\Tachyon\Updates

Only the initial copy of content is required. From this point on, the Consumer API will maintain the content of the Background Channel on the Tachyon DMZ Server.

PolicyDocuments can be omitted. When you click on the Deploy button in Guaranteed State (in step 27), then all policies will be regenerated and automatically copied to all registered Background Channels (see step 7 for registration of DMZ Server).

If any source directory is empty then it means you have not tested that feature when verifying the internal Tachyon system in Step 1. This is not critical at this stage, but you should re-check later.

24

Internal Tachyon Portal,  Tachyon Server (Response Stack) and DMZ Server.

Verify that the internal Tachyon Server can upload content to the Background Channel on the Tachyon DMZ Server:

  1. Connect to the Tachyon website and open the Settings application and navigate to Instruction sets
  2. Delete the Verification instructions.
  3. Verify that %PROGRAMDATA%\1E\Tachyon\Content\1E-TachyonPlatform-VerificationStage2 is removed from the internal Response Stack and DMZ servers.
  4. Upload the Verification Instructions.
  5. Verify that %PROGRAMDATA%\1E\Tachyon\Content\1E-TachyonPlatform-VerificationStage2 is re-created on the internal Response Stack and DMZ servers.
25

DMZ Server and external Tachyon client(s).

Verify an external Tachyon client can connect to the Tachyon DMZ Server Switch.

Change the Tachyon client configuration (1E Client configuration file) to point at both the internal Tachyon Server and the Tachyon DMZ Server. This assumes you want Tachyon client devices to be able to switch between internal and external access. If you prefer, you can simply enter details only for the Tachyon DMZ Server.

  1. Edit the %PROGRAMFILES%\1E\Client\1E.Client.conf file
  2. Modify the Switch configuration property.
    • In our example this would be: Switch=tachyon.acme.local:4000;tachyon.acme.com:4000
  3. Modify the BackgroundChannelUrl configuration property.
    • In our example this would be: BackgroundChannelUrl=https://tachyon.acme.local:443/Background/;https://tachyon.acme.com:443/Background/
  4. Ensure the test device is connected to the external network and not the internal network, then review the 1E.Client.log to confirm the Tachyon client connects
  5. Browse to the Tachyon website and start the Explorer application, and confirm the external test device is online.
26

Internal Tachyon Portal and external Tachyon client(s).

Run verification steps to verify an external Tachyon client can download content from the Tachyon DMZ Server Background Channel.

  1. Browse to the Tachyon website and open the Explorer application

  2. Run the verification stage 1 and 2 and confirm a successful response is received from the external Tachyon client

    The Stage 2 Action confirms that content can be downloaded by the Tachyon client

27

Internal Tachyon Portal and external Tachyon client(s).

Verify the external client can receive Policy updates.

  1. Open the Guaranteed State application in a browser
  2. Click Administration, then click Policies
  3. Select an existing enabled policy that will affect the Tachyon client and then click Disable
  4. Click Deploy
  5. Check the 1E Client log on the external Tachyon client to verify that it has successfully received a message to fetch new policy, and that the policy download from the Background Channel has been successful

You do not need any policies defined in Guaranteed State for this step to take effect. Pressing Deploy will create an empty policy. This step is required if you are making use of Guaranteed State