Skip to main content

1E 8.1 (on-premises)

Implementing a Tachyon DMZ Server

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

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

To enable external Tachyon client devices to interact with Tachyon, the DMZ requires at least one Background Channel and at least one Switch.

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

Tip

Tachyon Setup provides a two-stage process to install a new DMZ Server:

  1. run Setup Maintenance on the Response Stack server (specifically the server that hosts the Core which the DMZ Server will connect to) to prepare the Response server and its database, and store details in an ini file

  2. run Setup to install the DMZ Server using the prepared ini file

The two-stage process and its ini file are required, because Tachyon Setup is unable to communicate through the DMZ firewall. In previous versions of Tachyon, the first stage required complex manual configuration.

To upgrade a DMZ Server, you only need to run Tachyon Setup on the DMZ Server, you do not require the ini file.

Note

You should not start Stage 1 until you are also prepared to complete Stage 2. This is because Stage 1 reconfigures Tachyon to think the DMZ Server already exists and is working, before Stage 2 completes the process. This may cause the following problems:

  • Tachyon will attempt to send instructions to the Switch in the DMZ, and will log an error because such Switch is not yet installed. The error is harmless and will not prevent the instruction from being sent to other existing Switches, but you should be prepared to see the error message in the Log without being alarmed.

  • You will not be able to upload any new instructions which contain resources. If you try to upload an instruction definition that contains resources, the Consumer API will try to upload the resources to all Background Channels, including the one in the DMZ. This will, of course, fail, and it will cause the Consumer API to revert the changes made to all other Background Channels and return an error result.

  • You will not be able to deploy a Policy, because Policies also require one or more files to be uploaded to all Background Channels, which will be reverted when the DMZ Server fails to update.

If for any reason you are unable to complete Stage 2, you can revert the Stage 1 changes by using the Undo button in DMZ Server form in Tachyon Setup's Maintenance screen.

Assumptions

The steps given on this page assume:

  • 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

  • The Tachyon DMZ Server will host only Tachyon Switch and Background Channel components, and is installed in a DMZ

  • Tachyon is already installed on the internal (corporate) network, with Tachyon clients successfully using the internal Response Stack Switch and Background Channel, which the DMZ Server will connect to

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 Certificate requirements: Tachyon client certificates for more details.

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.

Warning

The web server certificate on the DMZ Server needs to reference at least one CRL Distribution point that uses HTTP. These CRL DPs are likely to be in the internal network, and the firewall will need to allow the DMZ server to access these internal servers.

Tachyon Setup will warn you if the certificate does not reference a CRL Distribution point that uses HTTP, but does not tell you if it cannot connect to the CRL DP, and will allow installation to proceed.

232785427.png
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.

    • Ensure the certificate(s) used on the internal server(s) already meet the additional requirements for implementing a DMZ Server. Tachyon Setup does not check these requirements.

    • 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.

    • Network 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 computername 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.

    • Network 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.

    • Certificate 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.

    • Windows Server 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 Certificate requirements: Tachyon Server certificates.

Implementing a Tachyon DMZ Server installation has the following additional certificate requirements for the internal server(s) as well as the Tachyon DMZ Server itself.

Relevant internal servers

Type

Additional certificate requirements

Where used

Tachyon Server certificate

The Certificate requirements for standard servers require the Tachyon Server DNS Name FQDN and computername FQDN to be present in the certificate. However, it has an additional requirement to separate communications between internal and external Switches:

  • A Subject Alternative Name Extension (extensions:subjectAltName), of type dnsName, which must contain:

    • Alternate DNS Name FQDN - for 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 one of the following:

    • Tachyon Server DNS Name FQDN - in our example tachyon.acme.local

    • Alternate DNS Name FQDN - as specified above - for example tachyonalt.acme.local

    • Tachyon Server computername FQDN - in our example ACME-TCNMST.acme.local

  6. The client authentication certificate, used by the Consumer API to communicate with the DMZ Background Channel, must have a subject.

Note

You will need the thumbprint for this certificate. In our example, this is 95dfcc47c31c8bf201104da27ba8a6d792e83665.

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.

Note

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

Type

Additional certificate requirements

Where used

DMZ Server certificate

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 computername 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

For each of the following scenarios, ensure you import the CA certificate(s) of the trust chain into the server's Local Machine's Trusted Root Certification Authority or Intermediate Certification Authorities stores (as appropriate).

  • Relevant internal servers must trust the DMZ Server certificate therefore you must import the CA certificates used by the DMZ Server into the CA stores on the relevant internal servers.

  • DMZ Server must trust the relevant internal server certificate(s), therefore you must import the CA certificates used by relevant internal server(s) into the CA stores on the DMZ Server.

  • The DMZ Server must also trust the Tachyon clients' certificates, therefore you import the CA certificates used by clients into the CA stores on the DMZ Server.

Note

The HTTP CDP referenced in any certificate, including imported CA certificates, must be reachable by the DMZ Server.

Note

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 certificate store (that is either KeyStore or cacert.pem file, depending on the method used to store certificates).

The installation process for a Tachyon DMZ Server
Overview

Tachyon Setup provides a two-stage process to install a new DMZ Server:

  1. run Setup Maintenance on the Response Stack server (specifically the server that hosts the Core which the DMZ Server will connect to) to prepare the Response server and its database, and store details in an ini file

  2. run Setup to install the DMZ Server using the prepared ini file

The two-stage process and its ini file are required, because Tachyon Setup is unable to communicate through the DMZ firewall. In previous versions of Tachyon, the first stage required complex manual configuration.

To upgrade a DMZ Server, you only need to run Tachyon Setup on the DMZ Server, you do not require the ini file.

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

232785638.png
DNS Names

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

Server

DNS Name references

DNS Name examples

DNS Names used in your environment

The internal Tachyon Server

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

Tachyon Server computername FQDN

ACME-TCNMST.acme.local

Tachyon Server DNS Name FQDN

tachyon.acme.local

Tachyon Server Alternate DNS Name FQDN

tachyonalt.acme.local

The external Tachyon DMZ Server

DMZ Server computername FQDN

ACME-TCNDMZ

DMZ Server internal DNS Name FQDN

tachyondmz.acme.local

DMZ Server external DNS Name FQDN (Internet)

tachyon.acme.com

Detailed steps

Location

Detailed steps

1

Internal 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.

2

DMZ Server.

Ensure Preparation steps are complete for the Tachyon DMZ Server.

Note

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.

    • Ensure the certificate(s) used on the internal server(s) already meet the additional requirements for implementing a DMZ Server. Tachyon Setup does not check these requirements.

    • 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.

    • Network 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 computername 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 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.

    • Network 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.

    • Certificate requirements: Tachyon Web Server Certificate (Preparation: Web server certificate)

      • Each DMZ Server requires its own web server certificate. Please see Certificate requirements below for more information.

    • Windows Server 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...

Note

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 certificate store (that is either KeyStore or cacert.pem file, depending on the method used to store certificates).

3

Internal Tachyon Server (Response Stack).

On the internal Tachyon Server (Response Stack)

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

You may have already created an alternate HTTPS binding when installing the Response Stack server. The Response Stack server is the server you have already installed that hosts the Core component. This will have been installed when installing a Single-Server with all components, or a dedicated Response Stack server. If you need to add the binding, then use the manual steps below.

Tip

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 Tachyon Server 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 Tachyon Server Alternate DNS Name FQDN

  9. Click OK to save, and Close

4

Internal Tachyon Server (Response Stack).

On the internal Tachyon Server (Response Stack)

On the server that hosts the Core component - which the DMZ Server will connect to - run Tachyon Setup and go to the Maintenance screen, and click on Add DMZ Server...

This is the first stage of using Tachyon Setup to install a DMZ Server. It prepares the Response server and its database, and stores configuration details in a <DMZ Server computername>.ini file in the Setup folder. You will need to copy this file to the DMZ Server.

When you click on Ok, Setup validates the configuration details. Any serious errors will prevent Setup from going ahead, and any warnings will cause a dialog to be presented to ask for confirmation about whether you want to continue. The ini file is only saved or updated after a succesful validation, or warnings have been accepted.

Note

After this moment, Tachyon will "think" that you have a DMZ Server, even though you have not yet installed it. This means:

  • Tachyon will attempt to send instructions to the Switch in the DMZ, and will log an error because such Switch is not yet installed. The error is harmless and will not prevent the instruction from being sent to other existing Switches, but you should be prepared to see the error message in the Log without being alarmed.

  • You will not be able to upload any new instructions which contain resources. If you try to upload an instruction definition that contains resources, the Consumer API will try to upload the resources to all Background Channels, including the one in the DMZ. This will, of course, fail, and it will cause the Consumer API to revert the changes made to all other Background Channels and return an error result.

  • You will not be able to deploy a Policy, because Policies also require one or more files to be uploaded to all Background Channels, which will be reverted when the DMZ Server fails to update.

The Undo button will allow you to undo the changes written to the database, so that your server will not think anymore that you have a DMZ Switch and Background Channel. This can be useful if you find an error in your configuration or if you need to revert the changes to avoid the errors mentioned above or if you wish to uninstall your DMZ Server. If you need to do this after you have already closed the form, you can re-open it and reload the information by using the Import button.

Parameter

Description

DMZ Server computername

The computername of the DMZ Server. It is used to ensure you are preparing the correct DMZ Server, and prepare the Switch configuration in the TachyonMaster database.

Tip

The computername is the value returned when you run the command cmd /k hostname on the DMZ Server.

DMZ Server internal DNS Name FQDN - reachable from internal network

The DNS Name FQDN and port that the internal Tachyon servers will use to connect to the DMZ Server through the DMZ firewall. In our example this is tachyondmz.acme.local and default port 443.

Tip

In most cases, your DMZ Server will have dual network connections, one for your intranet and another for the Internet. Here, you need to provide a DNS Name that resolves to the IP address of the internal network connection. It will be used by the Consumer API for posting information to the Background Channel in the DMZ, and the Core connecting to the DMZ Switch(es).

When you install the DMZ Server, this DNS Name FQDN will be used for the alternate HTTPS binding and exist as a SAN in the binding certificate.

DMZ Server external DNS Name FQDN - reachable from the Internet

The DNS Name FQDN and port that clients will use to connect to the DMZ Server, and the port used by the Background Channel. In our example this is tachyon.acme.com and default port 443.

This DNS Name FQDN should be the one that the clients on the Internet use for connecting to the DMZ server. The DMZ Tool will save it to the .ini file; when the file is read by Setup in the DMZ, it will be used for pre-configuring the corresponding entry in the Web configuration page.

Note

The Tachyon installer only configures a single address in IIS. If your DMZ server is dual-ported, meaning that it uses a different address for the internal network and the external network, only the latter will be automatically configured in IIS during installation in the DMZ. You will need to manually add the internal address in the IIS configuration.

Tip

In most cases, your DMZ Server will have dual network connections, one for your intranet and another for the Internet. Here, you need to provide a DNS Name FQDN that clients use to connect to the Background Channel using the external network connection.

When you install the DMZ Server, this DNS Name FQDN will be used for the main HTTPS binding, and exist as a SAN in the binding certificate.

Number of Switches to install in the DMZ

The number of Switches you will install on the DMZ Server.

By default it will be 1, but you need to increase the value if you expect to have more than 50,000 clients connecting to this DMZ server. Add one Switch for every 50,000 clients.

Comma-deimited list of Switch IP Addresses

Enter as many IP Addresses as the number of Switches that you specified above. In our example we have one Switch which has an IP Address 10.10.200.2

Tip

Each Switch listens for clients on its own network interface with its own IP Address. Each IP Address is for an external connection of the Switch to the Internet. If you are using reverse-NAT in your external router, then this is the IP Address as seen by the DMZ Server, not as seen from the Internet. By default each Switch listens on port 4000. If you need to change the port, you must do this manually after installation - please contact 1E for guidance.

Note

When you later run Setup on the DMZ Server to complete Stage 2, the Switch configuration allows you to select the IP Addresses for the Switches, and you must visually verify that the addresses match the ones that you selected here, and in the same order as they appear on the screen. The order is important because each Setup stage independantly assigns a numeric name to each Switch, Setup stage 1 stores names in the database, and Setup stage 2 stores the same names in the Switch Host configuration file on the DMZ Server.

This information is stored in the SwitchConfiguration table of the TachyonMaster database, and is read by the Switches on the DMZ Server when they start up. Therefore, a Switch will fail to start if the DMZ Server does not actually have a network interface with the expected IP Address.

Authentication - DMZ Server is member of a domain that trust the internal Master Stack server

Check this checkbox if your DMZ Server will be a "member of a trusted domain" - that is, it will be joined to a domain that has a two-way trust with the domain of your internal Tachyon servers.

Note

If the DMZ Server and internal servers trust each other, then Setup will configure them both to use Windows Authentication for incoming and outgoing connections. If you do not select the option, then Setup will configure the servers to authenticate to each other by means of certificates, and you will need to provide thumbprints below.

Thumbprint of client certificate sent by the Consumer API on Master to Background Channel on DMZ Server

This text box is enabled if you did not select "member of a trusted domain". You should enter here the thumbprint of a certificate that is installed in the Master Stack server. It should be enabled for Client Authentication, contain a private key, and be accessible to the Consumer API. This certificate will be presented by the Consumer API to the Background Channel in the DMZ when the Consumer API sends any changes to the Background Channel.

In our examle, this is 95dfcc47c31c8bf201104da27ba8a6d792e83665.

Note

The service account under which the Consumer API is running (by default, NT Authority\Network Service) will need to have read access on the private key of this certificate. The DMZ configuration tool will automatically grant this permission if you are running it on the same machine where the Consumer API is installed. If you are running it in a remote Response Stack, you will need to grant this permission manually at the Master Stack.

Thumbprint of client certificate sent by Background Channel on DMZ Server to ContentDistribution service.

This text box will only be enabled if you did not select "Member of a trusted domain". This field is optional.

You only need to enter this value if you are installing the ContentDistribution service (Nomad) in your internal network, and you want the Background Channel in the DMZ to act as a Proxy so that external clients can reach the internal server.

In our examle, this is 25fe00fce6240c9260e614eb95680fb6f3ddf06a.

If you are using this feature, then you should enter here the thumbprint of a certificate that is installed in the DMZ server. It should be enabled for Client Authentication, contain a private key, and be accessible to the Background Channel. This certificate will be presented by the Background Channel to the ContentDistribution service in the intranet when its internal Proxy needs to forward any packets to the internal server.

232785644.png
232785639.png

5

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.

6

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.

Note

However, remember that Tachyon thinks your DMZ Server is live, although it is not. This means:

  • Tachyon will attempt to send instructions to the Switch in the DMZ, and will log an error because such Switch is not yet installed. The error is harmless and will not prevent the instruction from being sent to other existing Switches, but you should be prepared to see the error message in the Log without being alarmed.

  • You will not be able to upload any new instructions which contain resources. If you try to upload an instruction definition that contains resources, the Consumer API will try to upload the resources to all Background Channels, including the one in the DMZ. This will, of course, fail, and it will cause the Consumer API to revert the changes made to all other Background Channels and return an error result.

  • You will not be able to deploy a Policy, because Policies also require one or more files to be uploaded to all Background Channels, which will be reverted when the DMZ Server fails to update.

7

DMZ Server.

On the Tachyon DMZ Server

1

Extract the TachyonPlatform download zip as described in Tachyon Setup: Required installation files, or copy a previous extract from an internal server.

2

Copy the ini file that you created earlier, into the folder containing Tachyon Setup.

3

Run Tachyon Setup.

Tip

You can follow the screens in Tachyon Setup documentation. A summary is provided below, with a link to each screen.

4

On the Welcome screen, click Next.

5

On the Documentation screen, click Next.

6

On the License agreement screen, you must read and then accept the license information by checking the I accept the terms in the license agreement checkbox, then click Next .

7

On the License File screen, only if you see the message A DMZ Server installation does not require a license file then you can click Next .

Note

If you do not see the message A DMZ Server installation does not require a license file it is because the name of the ini file is not the same as the computername of the DMZ Server. The name of the ini file should also be the same as the DMZ_MachineName setting in the ini file.

If you have got the name of the DMZ Server wrong, then you must stop Setup, and start all over again, by undoing the previous configuration and creating a new configuration and ini file.

8

On the Select configuration screen, the DMZ Server option will be automatically selected.

You can optionally change the install location. Click Next.

9

On the Check prerequisites screen, click the Start checking button. When the checks are complete, click Next.

Note

You may see a "Missing" error for the check "A suitable certificate is available". The most likely reason for this error is because the server is unable to validate the CRL when the DMZ Server is not domain joined. If so, then you can ignore this error, and click Next.

10

On the Server certificate screen, select the certificate that includes the DNS Name for the external Internet binding. In our example, this is tachyon.acme.com. Then click Next.

This certificate may also contain the DNS name for the internal binding. In our example this is tachyondmz.acme.local.

Note

You may see a "RevocationStatsuUnknown" error for the check "CRL Status". The reason for this error is because the server is unable to validate the CRL when the DMZ Server is not domain joined. If so, then you can ignore this error, and click Next.

11

On the Client certificates screen, ensure the checkbox is checked for Switches require client certificates to be presented by Tachyon client features of the 1E Client, and click Next.

Internet-based client are usually required to present certificates.

12

Click Next on each of the following screens, which are not used when setting up a DMZ Server. On some screens, you will need to scroll down before you are able to click Next.

13

On the Number of devices screen, enter the number of client devices you expect will be served by this DMZ Server, and click Next.

For every 50,000 clients (or less) you will need one Tachyon Switch. During Stage 1, you already specified the number of Switches you want, therefore the number you enter here will be a cross-checked on the next screen.

14

On the Switch configuration screen, select an interface for each Tachyon Switch you specified in Stage 1, by checking Use for Switches, ensuring each one has the same IP Address that you specified in Stage 1. Each interface is listed with its IP Address and MAC Address displayed.

If you have more then one Switch, ensure the order of IP Addresses is the same order you specified in the comma-delimited list of Stage 1.

You must have one spare interface (IP Address) which is the internal interface used by the DMZ Server to communicate with internal Tachyon servers.

Click Validate. If the validation passes then click Next.

Amongst other things, validation will validate whether you have the correct number of Switches to support the number of client devices you specified in the previous screen. It does not validate that the number of Switches matches the number you previously specified.

If you see an warning for "The firewall does not block access to the Switch ports" it is probably because you need to create a firewall rule to allow Switches to use port 4000. After installation you can create a rule for the the Switch executable.

232785640.png

15

On the Website configuration screen, confirm that the two DNS Names you specified in Stage 1 match the two HTTPS Host Header names, and that the port numbers also match. Then click Next.

Tip

After installation, you can use IIS Manager to manually delete the default HTTP binding.

232785641.png

16

Click Next on each of the following screens, which are not used when setting up a DMZ Server.

17

On the Nomad screen, confirm the following have been automatically selected, then click Validate, then click Next.

  • Certificate to be used by the Background Channel Proxy when conneting to Content Distribution - this certifictae should match the 2nd thumbprint specified in Stage 1

  • Type of authentication used by Nomad clients connecting to the Proxy - should be set to Client certificates

232785642.png

18

On the Ready to Install screen, review the summary, and click Install!

After installation, review the Installation results.

19

On the Post-Installation checks, click Start checking, and when the checks are complete, review the results, and finally click Close.

232785643.png

8

DMZ Server.

Use Services.msc to confirm 1E Tachyon Switch Host service is running. If it is stopped then there is an issue with all the Switches.

Check the number of Switch log files, and review their contents. There should be one log file for each Switch, plus Switch.Host.log

Use IIS Manager to cofirm the presences of the Tachyon website, which contains only the Background web application. Check the binding to confirm all the bindings exist that were specified in the Website cofiguration screen.

Tip

If you wish, you can manually delete the default HTTP binding.

9

Internal Tachyon Server (Response Stack) and DMZ Server.

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

  • 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

Note

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.

10

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.

11

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.

12

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

    Note

    The verification stage 2 Action confirms that content can be downloaded by the Tachyon client.

13

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

Note

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