Plan and create Sophos ZTNA Gateway
A Sophos ZTNA Gateway connects users to internal applications without the need for classic full-tunnel VPN access. However, the actual benefit only arises when the gateway mode, DNS, certificate, firewall rules and internal accessibility are properly planned.
This guide describes how to plan and create a ZTNA gateway in Sophos Central. The focus is on the gateway part. For the basic decision between VPN, ZTNA and other remote access variants, Sophos Connect or SSL VPN: Which remote access solution is right? also fits.
For the vendor-neutral basics of Zero Trust, ZTNA and the distinction from VPN, start with Zero Trust explained simply: ZTNA instead of classic VPN.
Understand the gateway modes
Sophos ZTNA can be operated with an On-premise Gateway or a Sophos Cloud Gateway. Both variants provide access to internal resources, but differ significantly in Internet exposure, DNS, operations and troubleshooting.
- On-premise Gateway: Gateway VM is located in your own data center or site network own VM, own public DNS, DNAT on port 443, more direct control.
- Sophos Cloud Gateway: Users connect via Sophos Cloud Points of Presence. less direct internet exposure, different DNS CNAMEs, point-of-presence selection.
- Sophos Firewall as a cloud gateway: Sophos Firewall assumes the gateway role for ZTNA Cloud Gateway. no separate gateway VM, but dependency on SFOS, Central and firewall operation.
The mode is not just a technical checkbox. It determines where traffic enters, who operates the data path, which DNS entries are necessary and whether a DNAT rule is needed on the firewall.
On-premise gateway
With an on-premise gateway, a gateway VM is deployed on VMware ESXi or Microsoft Hyper-V. The gateway can be reached from the Internet and accepts ZTNA access. In practice, a public DNS name points to the firewall and a DNAT rule forwards HTTPS to the gateway.
Advantages:
- direct data path to your own location,
- full control over gateway, segment, DNS and firewall rules,
- no dependency on the Sophos Cloud Data Plane for the actual entry point.
Disadvantages:
- Gateway VM must be operated and updated,
- Port 443 must be accessible from outside,
- Certificate, DNS, DNAT and internal routing must be correct,
- Availability depends on your location, internet connection and hypervisor.
When publishing an on-premise gateway via DNAT, the rule should be planned as carefully as other publications. The basics can be found in Publish servers with DNAT to Sophos Firewall.
Sophos Cloud Gateway
With the Sophos Cloud Gateway, access is managed via Sophos Cloud Points of Presence. The internal gateway component connects Sophos Cloud to the internal resources. This eliminates the need for users to access their own public gateway IP directly.
This reduces direct internet exposure but moves parts of the data path to the Sophos cloud. The following are therefore important:
- suitable point of presence close to the data center,
- correct public CNAME records,
- working internal DNS resolution,
- clear expectations regarding latency, availability and traffic profiles,
- Checking license, product and traffic limits for the specific environment.
For very data-intensive applications such as large file storage, CAD files or mass downloads, you should not just test ZTNA Cloud Gateway based on registration. What matters is how real usage, latency and data volume behave in everyday life.
Sophos Firewall as ZTNA Cloud Gateway
A Sophos Cloud Gateway can also be set up on centrally managed Sophos firewall devices. This is interesting if there is already a Sophos firewall at the location and no separate gateway VM is to be operated.
However, this variant should not be activated as a secondary function. The following should be checked:
- Supported SFOS version and central management status.
- ZTNA licensing and user mapping.
- Accessibility of internal resources from the firewall perspective.
- Impact on maintenance windows, firmware updates and firewall operation.
- Logging and responsibility for disruptions. If the firewall is the central remote access node anyway, this variant can be elegant. On the other hand, if you want ZTNA to run independently of firewall maintenance, a dedicated gateway VM or another design is sometimes cleaner.
Requirements
Before deployment, these points should be clarified:
- Sophos Central Tenant with ZTNA license.
- Synchronized users and groups.
- Identity provider, for example Microsoft Entra ID.
- Decide on On-premise Gateway or Sophos Cloud Gateway.
- Hypervisor or supported Sophos Firewall, depending on mode.
- Public DNS for gateway and resources.
- Wildcard certificate or suitable certificate concept.
- Internal DNS resolution of target applications.
- Network segment for the gateway.
- Firewall rules from the gateway to the applications.
- Owner for operations, logs, certificates and subsequent changes.
For certificates, a wildcard certificate is often the most practical option. Obtaining a wildcard certificate is described in Let’s Encrypt create wildcard certificate. If certificates are managed directly on the Sophos Firewall, Manage Let’s Encrypt certificates on Sophos Firewall also fits.
Platform and sizing
For gateway VMs, VMware ESXi and Microsoft Hyper-V are the typical platforms. Depending on the mode and Sophos status, other options may be relevant. It is crucial that the platform is officially supported, up-to-date and properly monitored.
For small to medium setups, a gateway VM with 2 vCPU and 4 GB RAM is a realistic starting point. But this does not replace operational planning. The decisive factors are the number of users, resources, traffic profile, TLS, latency and availability.
For productive environments you should also plan:
- Is there a gateway cluster?
- Does the gateway run in its own VLAN?
- How is the VM backed up or restored?
- Is there hypervisor monitoring?
- Who updates the gateway?
- Is there a maintenance window for reboots?
Network and subnet
The ZTNA Gateway should be operated in its own subnet or VLAN. It should not simply be placed on a client or server network. A separate segment makes firewall rules, logging, packet capture and later troubleshooting easier.
These networks should not be used for the gateway:
10.42.0.0/1610.43.0.0/1610.108.0.0/16
For an on-premise gateway, a public DNS name, for example ztna.example.com, points to the firewall’s public IP. The firewall forwards port 443 to the gateway via DNAT. The gateway then requires access to the Internet and access to the VLANs or server networks in which the published applications are located.
The DNS entries are different for a Sophos Cloud Gateway. There, CNAMEs become relevant for domain validation, gateway aliases and, depending on the access type, resource aliases. The public DNS entries should therefore be checked as a separate step before the rollout.
Decide before deployment
Before clicking on Add gateway, these questions should be answered:
- Which applications are published?: Web app, TCP app and file storage have different requirements.
- Agentless or agent-based access?: DNS, CNAMEs and user experience differ.
- On-premise or cloud gateway?: Decides on DNAT, data path and operational responsibility.
- Which user groups are allowed access?: ZTNA thrives on close association, not on broad groups.
- How is DNS resolved internally and externally?: Incorrect DNS destinations are one of the most common sources of errors.
- Which certificate is used?: Certificate errors act like a ZTNA failure for users.
- Who reviews logs and changes?: Without an owner, ZTNA quickly becomes difficult to support.
Download ZTNA Gateway
In Sophos Central, the files for the virtual machine can be downloaded under Protect Devices in the main menu.
Deploy VM on Hyper-V or ESXi
For an on-premise gateway or gateway VM, the virtual machine is created first.
Typical settings:
- Generation 1 for Hyper-V.
- 2 virtual processors as a starting value.
- 4 GB RAM as a starting value.
- Network in its own VLAN or gateway segment.
- Hyper-V: use downloaded
.vhdxfiles. - ESXi: Use OVA file.
The VM should not be started until the ISO image is created with the gateway settings. This ISO later connects the VM to the Sophos Central Tenant and the gateway settings.
Gateway settings in Sophos Central
The gateway is then added and configured in Sophos Central.
Important fields:
- Fashion: Choose on-premise gateway or Sophos cloud gateway consciously.
- Name: Use location, purpose or hostname.
- Location: Optional, but helpful with multiple gateways.
- FQDN: For the on-premise gateway, the public DNS name pointing to the firewall or gateway IP.
- Domain: Domain matching the certificate and resources.
- Platform type: VMware ESXi, Hyper-V, AWS or supported Sophos firewall variant depending on mode.
- Identity provider: Select previously set up identity provider.
- Gateway Instance Deployment mode: One-arm for simple DNAT scenarios, two-arm for separate WAN/LAN design.
- IP address: Prefer static or reserved IP address for productive gateways.
- Certificate: Use wildcard or appropriate gateway certificate.
One-arm is often simpler because one interface is used for incoming and outgoing traffic. Two-arm separates the WAN and LAN sides, but requires two interfaces and a clearer network design.
After saving, Sophos Central creates an ISO image with the gateway information. This ISO is assigned to the VM as the boot ISO.
Depending on host performance and environment, initial startup and registration with Sophos Central may take some time. As soon as the gateway responds, it can be accepted in Central.
Check after startup
After registration, the gateway is not automatically ready for production. Only these tests show whether the design works:
- Gateway status: Gateway is online in Sophos Central and shows a plausible version.
- Public DNS: Gateway FQDN or CNAMEs point to the expected destination.
- Certificate: Browser and ZTNA client trust the certificate.
- Internal DNS resolution: Gateway can correctly resolve internal resources.
- Firewall rules: Gateway only reaches the applications and ports it needs.
- DNAT on-premise: Port 443 hits the expected NAT and firewall rule.
- Test user: A pilot group can achieve exactly the planned resources.
- Logs: Gateway, central and firewall logs show traceable events.
If ZTNA is introduced as an alternative to VPN, a pilot should not be tested with just a sample website. Real target applications are better: internal web portal, RDP/SSH jump, specialist application or file access, depending on the planned use.
Typical errors
- Public DNS shows false: Users cannot reach the gateway. A/CNAME, TTL, check external resolution.
- Internal DNS resolution missing: Login works, resource doesn’t open. Check Private DNS, Resource FQDN or Destination IP.
- Certificate does not fit: Browser or client warning. Check Wildcard, SAN, Chain and Domain.
- DNAT is missing from the on-premise gateway: Gateway remains inaccessible from outside. Check NAT rule, port 443, WAN IP and log viewer.
- Gateway is not allowed to reach application: Resource remains offline or times out. Check firewall rules from gateway segment to destination.
- DHCP address changes: ZTNA fails after restart. Use reserved or static IP address.
- User group too broad: Too many resources visible. Allocate groups, policies and resources more closely.
- Cloud Gateway with incorrect PoP: noticeable latency. Choose a point of presence close to the data center.
For rule and NAT analysis on Sophos Firewall, Test firewall rules with Log Viewer, Policy Test and Packet Capture and Understanding NAT on Sophos Firewall will help.
Operational checklist
- Gateway mode documented.
- Public DNS and private DNS tested.
- Certificate valid and renewable.
- Gateway operated in its own segment.
- DNAT only set up for the on-premise gateway.
- Gateway rules for internal resources are strictly limited.
- Pilot users and pilot resources defined.
- Logs, owner and support process clarified.
- Gateway update and maintenance windows scheduled.
- Dismantling plan in place if Pilot does not work.