Configure and test an alias IP on Sophos Firewall

An alias IP binds an additional IPv4 or IPv6 address to an existing physical interface on Sophos Firewall. It is useful when a provider delivers several public addresses over the same WAN connection or when an internal interface must serve a second subnet during a migration.

The important distinction is that an alias is not a second internet connection, a separate zone, or an independent gateway path. The address uses the same physical parent interface. Routing, firewall rules, NAT, and Device Access must therefore still match the existing interface design.

⚠️ Before adding a public alias IP, document a current backup, an independent administrative connection, the provider allocation, the original ARP state, and the planned firewall and NAT rules. An additional address does not publish a server by itself, but it may make local firewall services reachable under the Device Access rules of the parent zone.

The example uses IPv4 on a WAN interface. SFOS also supports IPv6 aliases when the IP version matches the parent interface. IPv6 neighbor discovery and NAT66 are not part of this specific example.

Alias IP in eight steps

1. Confirm that the provider or internal network actually delivers the additional address over the same physical interface.
2. Document the parent interface, IP version, address, subnet mask, and purpose.
3. Check Device Access, existing rules, and an independent management path.
4. Bind the address to the parent interface under Network > Interfaces > Add interface > Add alias.
5. If required for rules and NAT, create a clearly named IP Host with exactly this address.
6. Configure DNAT or SNAT only for the intended flow; handle system traffic separately.
7. Verify the provider path, ARP, Firewall Rule ID, NAT Rule ID, and both directions with a new connection.
8. Test replacement hardware, HA failover, and rollback in a maintenance window with the same flow.

When an alias IP is suitable

An alias IP is suitable when multiple addresses must use the same physical Layer 2 and gateway path. Typical cases include:

• several public IPv4 addresses on one static WAN connection;
• a dedicated public address for DNAT, WAF, or a mail service;
• a fixed source address for selected forwarded traffic;
• a second internal subnet on the same physical segment during a controlled migration;
• several provider addresses in the same subnet, where separate WAN interfaces would cause ARP issues.

Multiple WAN interfaces in the same subnet are not a clean substitute. Sophos warns that this can make gateways unreachable because of ARP issues and lists an alias or LAG as the appropriate interface forms. Zones and interfaces on Sophos Firewall explains the basic choice between physical ports, VLAN, LAG, bridge, and XFRM.

An alias is not suitable when a second link, a separate gateway, independent link status, a different security zone, or real failover is required. These needs require a dedicated interface, VLAN, LAG, WAN, or routing design.

If the firewall should not own an additional IPv4 address locally but only answer its ARP request on a directly connected segment on its behalf, this is a different design. Configure Proxy ARP on Sophos Firewall explains the decision and the tightly scoped CLI and test workflow.

Example and replaceable values

The example publishes an internal HTTPS service through a second public address:

• Parent interface: Port2
• Parent zone: WAN
• Primary address: 203.0.113.9/29
• Provider gateway: 203.0.113.14
• Alias IP: 203.0.113.10/29
• Alias host object: WAN_ALIAS_APP_203.0.113.10
• Internal server: APP-DMZ_10.20.40.20
• Server IP: 10.20.40.20
• Service: HTTPS
• External test host: 198.51.100.25

203.0.113.0/24 and 198.51.100.0/24 are reserved for documentation. In production, replace them with the addresses allocated by the provider and an authorized external test host.

The /29 mask is only a realistic example. Do not copy it if the provider delivers a routed block, an individual /32 address, or another network size. The provider documentation, ARP or routing model, and the IP version used on the parent interface determine the correct value.

Add the alias to the physical interface

Under Network > Interfaces, bind the address directly to the existing interface:

1. Select Add interface > Add alias.
2. Under Physical interface, select Port2 or the actual parent interface.
3. Set IP version to IPv4.
4. Under IPv4/Netmask, enter 203.0.113.10 and the mask confirmed by the provider.
5. Select Save.

The additional address then appears on the parent interface. If more than three aliases exist, SFOS initially shows only the first three. Scroll within the visible address area to see the additional entries.

An alias cannot be turned on or off independently. If the physical parent interface is turned off or loses its link, its alias addresses also become unreachable. Conversely, saving an alias does not create a new gateway entry or a separate route.

The Add alias form does not have a separate zone field. The parent interface’s zone therefore remains relevant for local firewall services. Before adding a public alias IP, check which services are reachable from WAN under Administration > Device access and use a narrow Local Service ACL exception for fixed management sources. SSO or MFA does not justify broad WebAdmin access.

Use the alias in rules and NAT

The bound alias and an IP Host have different purposes:

• The alias makes the address locally present on the physical interface.
• The IP Host makes the same address clearly selectable in rule and NAT fields.

A host object alone does not bind an address to the interface. Conversely, an alias alone does not publish a server or allow forwarded traffic. Using IP hosts and services correctly explains these object boundaries in detail.

Publish an inbound service with DNAT

For this example, create WAN_ALIAS_APP_203.0.113.10 under Hosts and services > IP host as an object of type IP with address 203.0.113.10. Then create a narrow DNAT rule and a matching firewall rule:

• Original source: authorized external networks or deliberately Any
• Original destination: WAN_ALIAS_APP_203.0.113.10
• Original service: HTTPS
• Translated destination (DNAT): APP-DMZ_10.20.40.20
• Translated service (PAT): Original
• Inbound interface: Port2 or the confirmed ingress interface
• Translated source (SNAT): normally Original
• Log firewall traffic: turned on

The firewall rule allows the same external service from WAN to the internal server’s zone and uses the public alias address from Original destination as the Destination network. Keep the source, service, and protection features as narrow as possible. Publishing a server with DNAT provides the complete procedure for rule position, loopback, and hardening.

Send forwarded traffic through the alias IP

If only a specific internal server must appear externally as 203.0.113.10, create a dedicated SNAT rule for exactly this flow. Translated source (SNAT) then uses the IP Host for the alias address. Keep the source, destination, service, and interfaces as narrow as the use case allows.

The NAT rule does not replace a firewall rule. NAT rules are also evaluated only for the first packet of a new connection. After a change, open a new connection; an existing session does not prove the new NAT path. NAT on Sophos Firewall explains how SNAT, DNAT, and PAT are processed.

Handle firewall system traffic separately

DNS, authentication, mail, or other traffic generated by the firewall itself does not automatically follow an SNAT rule for forwarded clients. Sophos explicitly documents that routing configurations use the primary interface. If one specific and justified system-traffic flow must use the alias IP as its source, a separate CLI configuration is required.

Record the original state in the Device Console before the change:

show advanced-firewall

The following example translates only system traffic over Port2 to the single destination 198.51.100.25, using the alias IP 203.0.113.10:

set advanced-firewall sys-traffic-nat add destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10

⚠️ This command changes the source address of firewall traffic. It does not create a route and is not a general substitute for a NAT rule. The destination, /32 netmask, interface, and alias IP must match the actual application. Test exactly the affected service after the change and check the entry again with show advanced-firewall.

For rollback, remove the exact same entry with delete:

set advanced-firewall sys-traffic-nat delete destination 198.51.100.25 netmask 255.255.255.255 interface Port2 snatip 203.0.113.10

Broader netmasks translate traffic to an entire destination network. Use them only when this larger scope is intentional, documented, and tested.

Plan aliases from different subnets

Sophos allows several alias addresses from different subnets on the same physical interface, but specifies two conditions:

• Sophos Firewall must be the default gateway for internal hosts.
• Upstream devices acting as gateways for firewall traffic must have an appropriate address in every alias subnet used.

An alias does not automatically make a second subnet work end to end. The host gateway, peers, return route, ARP or Neighbor Discovery, firewall rules, and NAT must also be correct for that subnet.

For permanent segmentation, a separate VLAN or physical interface is usually easier to understand. A multi-subnet alias is more suitable for a consciously planned transition or a provider architecture where both networks really share the same Layer 2 path.

DHCP servers and DHCP Relay cannot be configured on an Interface Alias. An alias is also not a valid Dedicated HA link. These requirements belong on a supported physical or virtual interface.

Validate the traffic path and ARP

Validation must follow the actual task, not just a ping:

1. Under Network > Interfaces, check the parent interface, alias address, mask, and link status.
2. On the provider or upstream device, verify that the alias IP is reachable through the expected MAC address or neighbor.
3. From 198.51.100.25, open a new HTTPS connection to the alias IP.
4. In Log Viewer, check the expected Firewall Rule ID, NAT Rule ID, source, Original destination, and translated destination.
5. In the built-in Packet Capture, compare ingress on Port2 with egress to the server.
6. On the internal server, confirm that the connection arrives and the response returns through Sophos Firewall.
7. Negatively test an intentionally disallowed port and an unauthorized source.
8. In HA, repeat a controlled failover test with a new connection without assuming that an existing session continues without interruption.

A ping to the alias IP is meaningful only if Ping is intentionally allowed for the parent zone under Device Access. For a published HTTPS service, the real TCP and application test is the better proof of success. Packet Capture on Sophos Firewall explains filters, interface comparison, and export.

Troubleshoot systematically

The alias is visible but unreachable externally

• Confirm that the provider actually delivers the specific address over Port2.
• Compare the IP, mask, and parent interface with the provider allocation.
• Check the ARP or neighbor entry on the upstream device.
• Investigate Device Access only for access to the firewall itself.
• For forwarded services, check the Firewall Rule ID, NAT Rule ID, and server return path.

After replacing a firewall, the upstream router may still have the old MAC address stored for the alias IP. Sophos lists clearing the router cache or restarting the router in this case. In practice, first update only the affected ARP or neighbor entry using the documented procedure for the upstream device; a full restart belongs in a maintenance window.

Outbound traffic still uses the primary address

For forwarded traffic, check whether the expected SNAT rule matches a new connection. Source, destination, service, Inbound interface, Outbound interface, and NAT Rule ID must all match.

For firewall system traffic, a regular SNAT rule is not the correct proof. Check the specific sys-traffic-nat entry, route, destination, and actual packet flow instead. Do not add a broad translation on suspicion.

Only the second internal subnet does not work

Verify that Sophos Firewall really is the default gateway for the affected hosts and that the upstream device has a suitable address in this subnet. Then check the return route, host mask, ARP, firewall rule, and NAT separately. A visible alias does not prove these dependencies.

An IPsec tunnel over an alias is up but passes no traffic

First record the SFOS version, build, appliance model, PPPoE use, alias binding, IPsec Acceleration, and actual packet path. SFOS 22 has version-specific alias and acceleration edge cases that must not be applied to every alias issue. The bounded diagnostic procedure is in IPsec troubleshooting for alias interfaces.

Operations, replacement hardware, and rollback

Document alias addresses together with the provider allocation, DNS, certificates, NAT, firewall rules, and responsible service. Before replacing a firewall, include the public aliases and expected ARP or neighbor change in the acceptance test.

For rollback:

1. Document active uses of the alias and associated IP Host.
2. Remove published services from DNS, monitoring, or load balancing in a controlled manner.
3. First turn off the associated firewall and NAT rules and confirm that the intended flow stops.
4. Remove any sys-traffic-nat entry with the exact delete command.
5. Delete the alias and host object only when no production dependency remains.
6. Recheck the parent interface, primary address, gateway, and unaffected services.
7. In HA, repeat the same validation after a planned failover.

An alias cannot be used as a Dedicated HA link. HA on Sophos Firewall explains the required interfaces, peer administration addresses, and failover tests.

Checklist

• Provider allocation, parent interface, IP version, address, and mask are confirmed.
• A backup and independent administrative connection are available.
• Device Access and the Local Service ACL for the parent zone have been checked.
• The alias and same-named IP Host are not confused with each other.
• The firewall and NAT rules are limited to the intended flow.
• System traffic is translated separately only when there is a justified requirement.
• Firewall Rule ID, NAT Rule ID, ARP, and both directions are confirmed.
• An unauthorized source and disallowed service have been tested negatively.
• Replacement hardware, HA failover, and rollback are documented.

Frequently asked questions