Set up and verify Dynamic DNS on Sophos Firewall
Under Network > Dynamic DNS > Add, a hostname from the DDNS provider is associated with the corresponding WAN interface. Select Use port IP when the Sophos Firewall itself has the public IPv4 address. Select NATed public IP when it has a private WAN address behind a router.
Dynamic DNS only updates the DNS record. It does not open ports or create NAT or firewall rules. To make an internal server behind the firewall reachable, the additional steps in Publish a server using DNAT must also be configured correctly.
The same hostname can also represent a dynamic public WAN address for a Sophos DNS Protection Location. First, the external A-record query described below must return the current WAN IPv4 address; then verify the location-specific assignment as described in Manage Sophos DNS Protection Locations securely. The DDNS record alone does not assign a Filtering Policy or change the clients’ DNS path.
Configure Dynamic DNS
A hostname such as vpn.example.net must already be registered with the provider, and valid update credentials are required. The firewall must be able to resolve DNS and reach the internet and the provider. Dynamic DNS therefore does not work in an air-gapped environment.
- Go to Network > Dynamic DNS and click Add.
- Under Hostname, enter the name created with the provider, for example
vpn.example.net. Use the domain and subdomain syntax required by the provider; the format is not the same for every provider. Before saving, also check its sign-in name requirements. - Select the corresponding WAN Interface, for example
Port2 - WAN. - Under IPv4 address, select Use port IP or NATed public IP.
- Select the Service provider.
- Enter the Login name and Password or the provider-specific update key.
- Click Save and check the status.
The current SFOS dialog lists DynDNS, DynAccess, EasyDNS, ZoneEdit, Google DDNS, Namecheap, DNS-O-Matic, No-IP, FreeDNS and Cloudflare. The former Sophos service myfirewall.co has been discontinued. Depending on the provider, Password does not mean the normal account password: DynDNS uses the updater client key, while ZoneEdit and EasyDNS use a dynamic token. DynAccess, No-IP, DNS-O-Matic, Google DDNS and Namecheap use a username and password. If a provider does not require a username, Sophos instructs administrators to enter the domain as the Login name. For FreeDNS, the password in SFOS must not exceed 15 characters; Cloudflare is the exception that uses an email address and Global API Key.
Before step 6, prepare the hostname and update credentials in the provider account:
- DynDNS: In the DynDNS account, My Services > DynDNS Pro > Add New Hostname creates a hostname with the chosen provider domain. Find the update key under Account Settings > Updater Client Key. If the field is empty, use Generate Key. Warning: A newly generated key replaces the previous credentials of existing DDNS update clients; those clients must also receive the new key. In SFOS, enter the DynDNS username as Login name and the key as Password, not the account password.
- ZoneEdit: In the ZoneEdit control panel, open DNS and select the wrench icon for DYN RECORDS. Set HOST and TTL, click ENABLE for DYN AUTHENTICATION TOKEN, proceed with NEXT and confirm the changes. In SFOS, use the ZoneEdit username and the dynamic token instead of the account password.
- EasyDNS: In the EasyDNS control panel, open MANAGE > DNS SETTINGS > MODULAR EDITOR for the domain and edit DYNAMIC RECORDS. Set the hostname and TTL, create the Dynamic Authenticated Token with ENABLE, select NEXT and confirm the changes. The subscribed service must support Dynamic DNS. If an A record already exists, confirm its conversion only if it should actually become dynamic. In SFOS, use the EasyDNS username and the token instead of the account password.
- FreeDNS: Check the required hostnames under FreeDNS subdomains. The credentials listed above and the 15-character password limit still apply to SFOS.
Update keys and tokens, like passwords, must not appear in screenshots or tickets.
Use port IP or NATed public IP
- Use port IP: The selected WAN interface itself has the public IPv4 address.
- NATed public IP: The WAN interface has a private address and an upstream router performs NAT. To determine the public address, the firewall must also be able to reach
checkip.cyberoam.comover TCP80.
Bridge interfaces do not support Dynamic DNS. If WAN interfaces are modified or replaced, check the dependencies under Object usage and then verify the DDNS entry. Use zones and interfaces correctly explains further interface limitations.
Connect Cloudflare securely
The built-in Cloudflare provider requires the account email address and the Global API Key. The current Sophos documentation does not list a restricted API token as a compatible credential.
Cloudflare classifies the Global API Key as legacy: It has the same permissions as the user and access to that user’s resources. For the SFOS integration, use a separate Cloudflare user limited to the required zone and DNS role. The key must not appear in screenshots or tickets. If a Global API Key is not permitted by the security policy, use an external updater with a restricted API token or another supported provider instead.
For VPN and other services that connect clients directly to the firewall’s public IP address, the Cloudflare record must be set to DNS only. If the proxy is intentionally enabled, DNS queries return Cloudflare anycast addresses instead; in that case, check the DDNS origin IP in the Cloudflare dashboard.
Verify DDNS resolution and the service
SFOS checks every five minutes whether the public IP address has changed. After saving, check Last updated IP, Last updated status, Last updated time and, if an update failed, Failure reason under Network > Dynamic DNS. Last updated IP is the address most recently sent to the provider; only an external DNS query shows which address is being returned publicly.
Then query the hostname using a resolver outside the local DNS cache. On Linux and macOS:
dig @1.1.1.1 vpn.example.net A +short
On Windows:
nslookup vpn.example.net 1.1.1.1
The response must match the expected public IPv4 address. Immediately after a change, a resolver may still return the old address because of the DNS TTL and cache.
Finally, test the actual service from another network, such as a mobile connection. A correct DNS response proves only name resolution, not that the service is reachable.
Roll back a change
If the entry doesn’t work as expected, edit it under Network > Dynamic DNS using Manage and restore the previous interface, IP selection, provider and credentials. If DDNS is no longer required, delete the entry and manually restore the intended DNS value at the provider. Deleting the entry only stops future DDNS updates; it doesn’t remove DNAT or firewall rules, and it doesn’t automatically restore the DNS record published by the provider. Then verify the external DNS response and the service again.
Multi-WAN, HA and CGNAT
After a WAN or HA failover, always check the DDNS status, the external DNS response and the service.
- Multi-WAN: Each DDNS entry is bound to one selected interface. Do not assume that a single hostname automatically follows the active gateway. Plan a unique hostname for published services on each WAN.
- HA: Troubleshooting logs are not synchronized between the nodes. Set up Sophos Firewall High Availability explains the complete failover test.
- CGNAT: NATed public IP may publish the provider’s shared address, but it does not make the firewall reachable from the internet. This requires, for example, a genuine public IPv4 address, a separately maintained AAAA record with appropriate IPv6 firewall and service configuration, or an outbound tunnel or relay solution. The SFOS DDNS described here updates IPv4 only.
Troubleshooting
In Log Viewer, select Events and System, then search for the DDNS component. The technical field values are log_type=Event, log_subtype=System and log_component=DDNS; the relevant fields are Status, Message and Failure reason. Option 4 Device Console also shows the latest entries:
show logs ddc.log lines 100
For live analysis, use the following command from Device Management > Advanced Shell in the SSH menu and stop it with Ctrl+C:
tail -f /log/ddc.log
The commands and the association with ddc.log are documented for SFOS 22, but were not executed against a customer firewall for this article. Further log files and access methods are listed under Sophos Firewall service logs.
Invalid Configuration or bad authorization: Check the hostname, provider and credentials. Cloudflare requires the account email address and Global API Key.- Invalid IP: Check the interface and the Use port IP or NATed public IP selection.
- DNS Error or Connect Failed: Check DNS, the Default Route, internet access and provider reachability. For NATed public IP, also verify the check-IP connectivity described above.
- Invalid Response or Reported Abuse: Check the provider status, account, blocks and provider limits.
- Success, but wrong IP: Compare the provider dashboard, selected interface, IP option and external DNS response.
- FQDN is correct, but the service is unreachable: Check the upstream port forwarding, DNAT, firewall rule and the relevant VPN or service configuration.
If Cloudflare DDNS has failed only since upgrading to SFOS 22.0 MR1, update to SFOS 22.0 MR2 Build 546 or later and test again. Sophos fixes NC-180219 in this release; details are available in the SFOS 22 MR2 article.