Skip to content
English
  • There are no suggestions because the search field is empty.

What are the network requirements?

Understand what ports, protocols, sources, and destinations may be necessary for a successful Xona deployment.

Network changes may be required to successfully deploy Xona products in your environment.

Note: This KB article refers to the Xona Gateway and Centralizer. These are also referred to in the official documentation as the Xona Critical Systems Gateway (CSG) and Xona Central Manager (XCM). This KB artile also uses Xona in reference either the Gateway and/or Centralizer in places where the information applies equally to both products.

General Considerations

1. Xona Basics

  • Xona is a secure remote access solution designed for segmented OT networks where access from internal and external parties must be controlled and monitored.
  • The Xona Gateway provides a web interface over HTTPS that enables controlled and monitored access into systems using common remote access protocols, including Remote Desktop Protocol (RDP), Virtual Network Client (VNC), Secure Shell (SSH), and HTTP(S). No special remote access client is required for the user.The Gateway also supports moderated file transfer with optional malware scanning integrations, helping to fulfill the role of a data diode in controlled environments.
  • The Xona Centralizer is an optional product that can consolidate the secure remote access provided by multiple Gateways into a single portal. Gateways connect up to the Xona Centralizer so that organizations can maintain a minimal attack surface.
  • The user interface of the Gateway and Centralizer are very similar. Users who access Gateways directly will have no difficulty transitioning to a Centralizer whenever the need arises.
  • Both the Centralizer and Gateway can integrate with common services found in enterprise security architectures, including various authentication providers, log collection services, and malware detection platforms.

2. IP Connectivity

  • The Xona Gateway and Centralizer support up to two IP addresses:
    • One IP address for for the Trusted Interface.
    • One IP address for for the Untrusted Interface.
    • Note: An additional IP address may be assigned to the iDRAC port on Xona 1U hardware appliances, however, this management interface is completely independent of the Xona configuration. For more details, refer to the Out of Band Management (iDRAC) documentation section under Deployment > Hardware > Enterprise Appliance for Xona 5.4.3 and higher.
  • A minimum of one IP address is required to operate a Xona appliance. By default, virtual and cloud installations include only one network interface. If two network interfaces are desired, then both must be included on the VM before its first boot.
  • When using a Xona Centralizer, the Xona Gateways connect up to the Centralizer. This is described in more detail in the "Required Firewall Rules" section of this KB article.
  • If the Xona appliance is behind a proxy or if the gateway is performing Network Address Translation (NAT), then it may be necessary to set the "Trusted Proxies" setting to prevent clients from being locked out due to request throttling of the gateway.
  • If Active-Standby High Availability (HA) is being used, then a floating IP may be necessary to point clients to the current Xona Primary, depending on the features available on the network router, firewall, or load balancer.

3. Domain Name

  • A DNS record to access Xona is generally recommended and also required specifically for the use of hardware security keys (WebAuthn/FIDO2).
  • If Xona is being accessed using multiple IPs, either due to Trusted/Untrusted network interfaces, or through Network Address Translation (NAT) of the network gateway, then a split-horizon DNS setup can help clients reach the appropriate Xona IP. A split-horizon DNS setup is typically one where a DNS server for external users responds to queries with an external IP, while a DNS server for internal users responds to queries with an IP.
  • If Active-Standby High Availability (HA) is being used, then a DNS alias record (CNAME) can be used to point clients to the current Xona Primary. In most cases, this CNAME is what should be used in both the SSO and Primary Network Address settings.
4. HTTPS Certificate
  • A self-signed HTTPS certificate is auto-generated by Xona at first boot and can be regenerated as needed. The self-signed certificate can be manually imported into the trust stores of clients connecting to Xona. Using self-signed certificate can be sufficient for small deployments where there is no control over DNS servers or PKI access.
  • For production deployments, it is recommended to use a PKI certificate signed by a trusted certificate authority.
  • Only one certificate can be used for HTTPS. If different domain names are used to access the Trusted and Untrusted IPs of your Xona appliance, then the certificate may need both added to the Subject Alternative Name (SAN) field. Alternatively, use the same domain name and utilize split-horizon DNS to serve the correct IP depending on the location of the client.

Firewall Rules

The firewall rules listed below are split up into Required, Recommended, and Optional sections.

Required Firewall Rules

These firewall rules are the bare minimum for deploying Xona products.

1. HTTPS over TCP port 443 from clients to Xona.
  • The primary mode of interacting with Xona products.
  • For the Xona Centralizer, both users and administrators will need to access it over HTTPS. For Xona Gateways joined to the Centralizer, only administrators need to access it over HTTPS.

2. Remote access protocols from Xona Gateway to trusted assets.

  • Xona Gateway can connect to assets using the following remote access protocols RDP (TCP 3389), VNC (TCP 5900), SSH (TCP 22), HTTP (TCP 80), and HTTPS (TCP 443).
  • The remote access protocol ports can be customized on the Xona Gateway if the environment requires it.

3. Xona Fabric UDP port 39251 from Xona Gateways to Xona Centralizer

  • Only required if deploying Xona Centralizer.
  • Xona Fabric uses this port to establish a bi-directional Wireguard tunnel between the Gateway and Centralizer.
  • The firewall rule should have the Xona Gateway as the source and the Xona Centralizer as the destination.
  • The UDP firewall rule may need to be adjusted for 60 second Time to Live (TTL).
  • It is recommended to allow Xona Gateways to connect directly to the Xona Centralizer instead of through a VPN or MPLS, either of which might interfere with the MTU and QoS labels used in Wireguard communication.

Recommended Firewall Rules

These firewall rules are not technically required, but they are strongly recommended for the best experience.

4. NTP over UDP port 123 from Xona to one or more NTP servers.

  • Time synchronization over NTP results in an accurate system clock, which is required for multi-factor authentication, username / password sign-in, and HTTPS connections.
  • It is recommended to use multiple NTP servers to improve accuracy and resilience.
  • It is possible to operate a stand-alone Xona Gateway without NTP, but it requires manually checking the clock on a regular basis, and so disabling NTP is discouraged. The Xona Centralizer cannot function properly without NTP.

5. DNS over UDP port 53 from Xona to one or more DNS name servers.

  • Domain names must be resolved using a DNS name server.
  • The default NTP servers are specified using domain names and without DNS these NTP servers cannot be resolved for proper time synchronization.

Optional Firewall Rules

These firewall rules are only necessary for optional features.

6. SSH over TCP port 22 from admins to Xona.

  • Completely optional.
  • Provides access to the setup console for administrators.
  • Can be enabled or disabled per interface.

7. LDAPS over TCP port 636 from Xona to Microsoft Active Directory Domain Controller.

  • Only required if using domain authentication to login to Xona.
  • It is recommended to integrate identity providers like Active Directory at the Xona Centralizer.

8. SMTP over TCP ports 465 or 587 from Xona to email infrastructure.

  • Only required if using Email Alerts.
  • Port 465 is used for legacy SMTP TLS.
  • Port 587 is used for modern SMTP STARTTLS.

9. Syslog over TCP port 514 from Xona to log server.

  • Only required if using syslog for log forwarding.

10. HTTPS over TCP port 443 from Xona to Splunk.

  • Only required if using Splunk for log forwarding.

11. HTTP(S) over TCP port 80 or 443 from Xona to file reputation services.

  • Only required if using a file reputation service for detecting malware transmitted through file buckets in Xona Gateways.
  • Supported services are ICAP servers, Virus Total, and Palo Alto WildFire.

12. SMB over TCP port 445 from Xona to network file share server.

  • Only required if using the SMB integration feature for file buckets on Xona Gateways.