What are the network requirements?

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

1. IP Connectivity

The Xona CSG/Gateway and XCM/Centralizer support up to two IP addresses, one for it's Trusted Interface, and one for it's Untrusted Interface.

A minimum of one IP address is required to access a Xona appliance.
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 provent 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.

2. 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 typicaly 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.

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

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

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 XCM/Centralizer, both users and administrators will need to access it over HTTPS. For CSGs/Gateways joined to the XCM/Centralizer, only administrators need to access it over HTTPS.

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

Xona CSG/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 CSG/Gateway if the environment requires it.

3. Xona Fabric UDP port 39251 from Xona CSGs/Gateways to Xona XCM/Centralizer

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

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 resiliency.
It is possible to operate a CSG without NTP, but it requires manually checking the clock on a regular basis, and so disabling NTP is discouraged.

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.

These firewall rules are only necessary for optional features.

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

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 XCM/Centralizer.

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

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

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

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 CSGs/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 CSGs/Gateways.

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