How do I set up Sophos VPN behind CGNAT?

First decide whether you need the firewall admin console or access to the private LAN. Use Sophos Central for administration. For LAN access, deploy a public server hub, connect an on-site gateway to it outbound, add the remote routes and narrow Sophos rules, then enroll remote peers.

How do I connect to Sophos VPN when the firewall is behind CGNAT?

A remote client cannot start a native inbound Sophos SSL or IPsec session through ISP CGNAT. Give both sides a public meeting point instead: the client connects to the server, and the gateway behind Sophos maintains its own outbound tunnel to that server.

Where do I get the Sophos VPN configuration file?

For a native Sophos Connect deployment, allowed users can download the client and .ovpn configuration from the VPN portal, or an administrator can distribute a supported provisioning file. If the endpoint hostname, certificate, or port changes, generate and import the updated configuration again.

How do I find the VPN portal and SSL VPN ports in Sophos?

Current Sophos Firewall versions show portal ports under Administration > Admin and user settings and the SSL listener under Remote access VPN > SSL VPN global settings. Defaults can vary by version and upgrade history, so verify the live settings before creating a rule or configuration file.

Which certificate should Sophos use for remote access?

Use a certificate whose identity matches the public hostname clients connect to and whose chain the clients trust. After changing the SSL VPN certificate or public endpoint, have users download and import a fresh configuration when Sophos documentation requires it.

How do I check Sophos VPN speed and performance?

Measure the same transfer or iperf path before and after the tunnel, then compare latency, loss, CPU use, and throughput. Test to a nearby public hub first. A distant server, packet loss, full-tunnel internet routing, or an undersized gateway can each reduce performance.

Why can the tunnel connect but not access a private IP address?

A handshake only proves that the peers authenticated. Check AllowedIPs, IP forwarding, the Sophos return route, zone and firewall rules, overlapping subnets, and the target host firewall. Test the tunnel gateway before the final LAN address to isolate the missing hop.

Where should I look when Sophos remote access fails?

Start at the public listener with a packet capture and handshake status. Then check the on-site gateway service, Sophos route and policy logs, internal DNS, and the destination service. Follow the first layer without evidence instead of changing every setting at once.

Guide

16 min readAug 11, 2026

How to Access Sophos Remotely Over a CGNAT Network

Choose the correct path for Sophos administration, remote users, or a remote site—then verify the CGNAT layer, tunnel, route, firewall rule, DNS, and target service in order.

Quick Answer

For the web admin console, register the firewall with Sophos Central and open it from Firewall Management. For staff or site access to the LAN, place a public Vultr server in the middle and keep an outbound tunnel from a gateway behind Sophos. The public server becomes the stable meeting point while CGNAT remains unchanged.

Choose my access path Compare public servers Open the verification ladder

Choose the access path

What do you need to reach through Sophos?

Start with the job, then prove where the public connection ends. This avoids publishing an admin port or rebuilding a VPN policy that CGNAT can never receive.

Compare the Sophos WAN IPv4 with the public IPv4

Read the WAN address from Network > Interfaces on Sophos. Detect the public IPv4 from the same internet connection, with other VPNs disconnected.

Sophos WAN IPv4Public IPv4 seen online

Run the two-address check

The right setup depends on whether Sophos owns the public address or sits behind an upstream translation layer.

Next: Enter the WAN IPv4 from Sophos and detect or enter the public IPv4 seen on the same connection.

Run the full CGNAT check Rule out Double NAT

Two remote-access jobs need two different paths

Sophos administration and private-LAN access are separate outcomes. Pick the shortest secure route for each one.

Fastest for administrators

Sophos Central management

Register the firewall, approve Central management, and open the web admin console from My Products > Firewall Management. Current Sophos documentation uses role-based access and a reverse-proxy path for supported versions.

Use it for: configuration, monitoring, diagnostics, logs, and policy work.

Security value: the local HTTPS admin service stays off the public WAN.

Open the official setup steps

Best for users and sites

Public server hub

The server supplies the fixed public endpoint. A gateway behind Sophos initiates and maintains the outbound tunnel, while remote peers connect to the same hub.

Use it for: private applications, RDP, SSH, file shares, internal DNS, or a routed remote subnet.

Business value: one controlled public meeting point replaces an ISP change and keeps the LAN behind Sophos policy.

Review the server option

Recommended public hub

Choose a server that makes the Sophos network reachable

A small public Linux VM gives the tunnel a fixed IPv4 and an always-on UDP listener. Because the Sophos-side gateway initiates outward, CGNAT no longer controls the entry path. Staff gain a stable private route, and you keep ownership of keys, subnets, and access rules. Vultr publishes a complete Ubuntu WireGuard guide for this setup.

Vultr for the public tunnel hub

Vultr is the recommended public hub because it combines broad location choice with a documented WireGuard setup path.

Vultr

New users get $300

Fixed public IPv4 and UDP rules give the tunnel one stable rendezvous point.
Official Ubuntu WireGuard documentation shortens deployment and recovery work.
New users can receive a $300 promotional credit through this offer.
Vultr reports more than 80 million cloud instances launched worldwide.

The connection path that works through CGNAT

Both private sides start outbound sessions. Only the cloud server accepts a public listener.

Remote user or site

Starts an authenticated tunnel to the server public IPv4.

Vultr hub

Owns the fixed IPv4, UDP listener, peer keys, and private routes.

Gateway behind Sophos

Keeps an outbound tunnel alive, then passes approved traffic through Sophos policy to the LAN.

Keep the Sophos admin console on Sophos Central

Use the routed hub for private services and remote users. Avoid turning the local web admin port into a general internet listener.

Implementation plan

Set up Sophos remote access over CGNAT

Use a dedicated DMZ or transit VLAN for the on-site gateway so the tunnel-to-LAN flow crosses Sophos rules and remains easy to audit.

Step 1

Deploy the public hub

Create a small Ubuntu server with a public IPv4 near your users. Use SSH keys, update the OS, and allow the WireGuard listener (commonly UDP 51820) in the cloud firewall.

Step 2

Build the private tunnel network

Install WireGuard on the server and assign a dedicated tunnel range such as 10.77.0.0/24. Enable IPv4 forwarding and keep management access restricted.

Step 3

Add an outbound gateway behind Sophos

Place a small Linux VM or device in a Sophos DMZ or transit VLAN. Configure it as a WireGuard peer that initiates to the server, and set PersistentKeepalive to keep the CGNAT mapping active.

Step 4

Route through Sophos policy

Add the remote tunnel subnet to the required Sophos routes and create narrow rules from the tunnel gateway zone to the approved LAN resources. Keep the web admin console on Sophos Central.

Step 5

Enroll remote users or the second site

Create a separate peer and key pair for each user or gateway. Route only the private destinations they need instead of sending all internet traffic through the business LAN.

Step 6

Verify one hop at a time

Confirm both handshakes on the server, ping tunnel addresses, test a private IP, test internal DNS, and finally open the target application. Each result identifies the next layer to fix.

CGNAT-side WireGuard peer

Keep the connection active and advertise only the LAN routes this gateway owns.

[Peer]
PublicKey = <VPS_PUBLIC_KEY>
Endpoint = <VPS_PUBLIC_IP>:51820
AllowedIPs = 10.77.0.0/24
PersistentKeepalive = 25

Server route for the Sophos LAN

Bind the private LAN to the on-site peer, then enforce resource access in Sophos.

[Peer]
PublicKey = <SITE_GATEWAY_PUBLIC_KEY>
AllowedIPs = 10.77.0.2/32, 192.168.20.0/24

Change the example subnets

Choose tunnel and LAN ranges that do not overlap with home Wi-Fi, the remote site, or existing Sophos networks. Overlap is a common reason a healthy tunnel cannot reach its destination.

Connection and port verification

Find the first broken hop

A WireGuard listener is UDP, so a generic open-port result is not enough. A recent authenticated handshake is the strongest proof; packet capture shows whether traffic reaches the server before authentication.

Listener

sudo ss -lunp | grep 51820

Confirms the UDP socket is bound on the server.

Handshake

sudo wg show

Shows the latest handshake, endpoint, and transfer counters for each peer.

Packet path

sudo tcpdump -ni any udp port 51820

Proves whether packets arrive before keys and routes are evaluated.

What you see	What it proves	Next check
No handshake from the remote user	No new packet on the server listener	Check the server public IP, UDP 51820 rule, client network, and client key.
User connects, CGNAT site is offline	Remote peer has a handshake; site peer does not	Check the on-site gateway service, endpoint, keys, DNS, clock, and PersistentKeepalive.
Both peers connect, tunnel IP fails	Recent handshakes but no tunnel ping	Correct AllowedIPs, peer addresses, forwarding, and return routes.
Tunnel works, private LAN IP fails	Tunnel gateway answers; a LAN resource does not	Check the Sophos static route, zone rule, gateway firewall, and target host firewall.
Private IP works, hostname fails	Application opens by IP only	Push or route the internal DNS server and verify the search suffix.
Only one application fails	Other LAN services are reachable	Check the service listener, application ACL, protocol, and host firewall port.

For more tunnel patterns and single-service alternatives, see remote access without port forwarding. For a broader method comparison, use the CGNAT bypass decision guide.

Questions people ask

Sophos remote access over CGNAT FAQ

Official references

Share this article