Implementing a Tachyon DMZ Server
The process for installing a Tachyon DMZ Server to support Internet-facing 1E Client devices.
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 1E 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 Master Stack and 1E Client devices. The Background Channel and Switch components handle the direct communication with 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:
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
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 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 Tachyon reconfigures 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 the Tachyon Setup 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 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.
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). Client devices must have the appropriate certificates installed. Please refer to Certificate requirements 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. 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.
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 that 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 that 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 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 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)
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. The documentation below assumes this DNS Name exists, but it can alternatively be the server's computer name FQDN.
A DMZ Server external DNS Name so that Internet devices can connect to the DMZ Server, which is the name included in the 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 the 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 Service Principal Names for more details.
Network requirements (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 Configuring a persistent route for SQL traffic.
Certificate requirements (Web Server Certificate)
Each DMZ Server requires its own web server certificate. Please see Certificate requirements below for more information.
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 Master Stack is configured to use.
Test devices with the client installed.
At least one is connected to the internal network; another is connected to the external network.
Certificate requirements
Tachyon Server certificate requirements are defined in Certificate requirements.
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 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:
| 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 Consumer API client certificate | The client certificate on the Tachyon Master Stack has the following requirements:
NoteYou 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. NoteThis 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 |
|---|---|---|
The Certificate requirements 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:
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 clients. | |
The client certificate on the Tachyon DMZ Server has the following requirements:
| 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 the relevant internal server(s) into the CA stores on the DMZ Server.
The DMZ Server must also trust client 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 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:
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.
Run Setup to install the DMZ Server using the prepared ini file.
The two-stage process and its ini file are required because 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 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.
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 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. NoteYou must ensure the following before installation of Tachyon on a DMZ Server.
Expand to see guidance when DMZ Server is using different CA certificates to the internal Tachyon server or clients... NoteIf the certificates on the DMZ Server and the internal Tachyon servers are from different issuing CAs, then:
Similarly, if the certificates on the DMZ Server and client authentication certificates on external clients are from different issuing CAs, then:
| ||||||||||||||||||
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. TipRemember this binding for steps 5, 8 and 21.
| ||||||||||||||||||
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 successful validation, or warnings have been accepted. NoteAfter this moment, Tachyon will "think" that you have a DMZ Server, even though you have not yet installed it, this means:
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.
  | ||||||||||||||||||
5 | Internal Tachyon Server (Response Stack). | On the internal Tachyon Server (Response Stack), restart all Switches and confirm they are working.
| ||||||||||||||||||
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. NoteHowever, remember that Tachyon thinks your DMZ Server is live, although it is not. This means:
| ||||||||||||||||||
7 | DMZ Server. | On the Tachyon DMZ Server 3 | ||||||||||||||||||
8 | DMZ Server. | Use Services.msc to confirm 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 confirm the presence 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 configuration screen. TipIf 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:
NoteOnly the initial copy of the 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:
| ||||||||||||||||||
11 | DMZ Server and external Tachyon client(s). | Verify an external client can connect to the Tachyon DMZ Server Switch. Change the client configuration (1E Client configuration file) to point at both the internal Tachyon Server and the Tachyon DMZ Server. This assumes you want 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.
| ||||||||||||||||||
12 | Internal Tachyon portal and external client(s). | Run verification steps (Verifying) to verify an external Tachyon client can download content from the Tachyon DMZ Server Background Channel.
| ||||||||||||||||||
13 | Internal Tachyon portal and external client(s). | Verify the external client can receive Policy updates.
NoteYou 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 Tachyon |