Skip to content
Avanet

Use Sophos Firewall IP Hosts, Services, and Groups Correctly

Sophos Firewall

IP hosts and services give addresses, networks, and ports meaningful names. A firewall rule can then show directly which source may communicate with which destination and service.

The important decision is the required scope: Create one address as IP, a subnet as Network, a contiguous address pool as IP range, and a small collection of individual addresses as IP list. For TCP and UDP, a service normally specifies the fixed Destination Port, while the dynamic Source Port remains unchanged.

For a new rule, the shortest safe path starts with the smallest suitable host object, continues with an existing or custom service, and ends with a narrowly scoped firewall rule. Only then should you consider special cases such as System Hosts, MAC Hosts, and reusable groups. Before any later change, Object Usage shows which rules and policies depend on the object.

Choose the appropriate host object

Four types are available under Hosts and services > IP host:

  • IP: Exactly one IPv4 or IPv6 address, such as a server, printer, or management system.
  • Network: A complete subnet with its network mask, such as 198.51.100.0/24.
  • IP range: A contiguous range, such as 203.0.113.10 to 203.0.113.20.
  • IP list: Several individual, noncontiguous addresses. A list supports up to 800 IP addresses and cannot be a member of an IP Host Group. The current SFOS 22 help includes the statement “For IP list, use only class B IP addresses.” Because Sophos does not explain this outdated classful-network wording any further, it must not be taken to mean that arbitrary IPv4 or IPv6 lists are supported.

An FQDN host is more suitable when the destination address changes and a stable DNS name exists. Resolution, wildcards, and limitations are explained in Use FQDN hosts and wildcard FQDNs correctly.

As a general rule, use the smallest stable object that completely describes the required traffic. An object of type IP covers only one address and is too narrow for an entire subnet; a /24 network would be unnecessarily broad for a single server.

Create an IP host step by step

The following example represents one test server:

  1. Open Hosts and services > IP host and select Add.
  2. Enter host_test_web as the Name.
  3. Set IP version to IPv4.
  4. Select IP as the Type.
  5. Enter 192.0.2.10 under IP address.
  6. Select Save.

The following addresses from 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 are reserved for documentation examples. In a production configuration, replace all names, addresses, and network sizes with values from the actual network.

Network, range, and IP list

The fields change with the selected type:

  • Network: net_test_branch with 198.51.100.0 and /24 represents the complete test network. Enter the network address, not the gateway address.
  • IP range: range_test_admins from 203.0.113.10 to 203.0.113.20 represents a contiguous pool.
  • IP list: For list_test_hosts, enter only comma-separated addresses from your own verified environment. Because the Class B statement in the current help is unclear, create the actual list on the SFOS build in use and validate it with a test rule. A list is suitable for a few fixed individual addresses, not for continuously changing indicators of compromise.

For dynamically maintained malicious IP addresses, domains, or URLs, Threat feeds on Sophos Firewall are the more suitable feature. A manual IP list is not updated automatically.

IP Host Groups

Under Hosts and services > IP host group, hosts with the same functional purpose can be grouped together. For example, a group can contain all approved management systems and then be used in several rules.

Alongside Custom IP Hosts, the default hosts for interfaces, cellular WAN, and the internet can also belong to a group. Group membership is separate from whether the host object can be edited: a system host that cannot be edited directly is not automatically excluded from groups. Dynamic remote access VPN system hosts remain excluded, however.

Three important restrictions apply:

  • IPv4 and IPv6 hosts cannot be in the same IP Host Group.
  • A regular host can be a member of several groups.
  • An object of type IP list cannot be added to an IP Host Group.

To create a small IPv4 test group containing the previously created host_test_web:

  1. Open Hosts and services > IP host group and select Add.
  2. Enter grp_test_servers as Name; adapt the name to the group’s purpose.
  3. Set IP version to IPv4 to match the existing test host.
  4. Use Add new item to select host_test_web. Additional members must share the same purpose and IP version.
  5. Select Save.

Reopen the group and check its IP version and members. If a required host is missing from the selection, first check its IP version and type; do not work around an IP list or remote access VPN system host restriction with an unnecessarily broad replacement object.

Groups should have one shared meaning. A collection of servers, clients, and temporary exceptions may save clicks, but it later makes it difficult to understand why a rule allows access.

Understand system and interface hosts

SFOS creates several host objects automatically. These objects should not be recreated as regular custom hosts or edited in the wrong place:

  • Interface Hosts follow the IP configuration under Network > Interfaces and are changed there. Zones and interfaces on Sophos Firewall explains the relationship between a connection, zone, and rule.
  • If an additional address must be bound locally to a physical interface according to the provider and network design, configure it as an alias IP on the physical interface. If a NAT field does not offer the corresponding Interface Host, also create a clearly named Custom IP Host with this address. Giving both the same name is merely a useful convention, not a technical requirement.
  • ##WWAN1 is created when cellular WAN is turned on, uses the WWAN interface’s IP address, and is maintained dynamically.
  • ##ALL_SSLVPN_RW, ##ALL_SSLVPN_RW6, ##ALL_IPSEC_RW, and ##ALL_RW represent dynamic remote access hosts.
  • ##ALL_SSLVPN_RW contains the IP addresses leased by the firewall to established remote access SSL VPN connections using Sophos Connect. ##ALL_IPSEC_RW contains the corresponding leased addresses for IPsec connections. ##ALL_RW combines the leased addresses for both connection types; SFOS adds them dynamically when the connections are established.
  • Other system hosts cannot be edited or deleted like custom objects.

The dynamic remote access hosts cannot be added to another IP Host Group. Physical Interface Hosts are not available in certain NAT fields, including Translated source and Translated destination. In that case, a separate IP host with the same address may be required. Its name should clearly show the relationship to the interface so it does not appear to be an unrelated address.

For internal hosts in the alias subnet, SFOS must be the default gateway. If an upstream device uses the firewall as its gateway, that device needs an IP address from each affected alias subnet. After replacing a firewall, stale ARP entries on upstream devices can temporarily make the alias IP unreachable. Check and update their ARP cache first instead of unnecessarily broadening the NAT rule.

For outbound internet SD-WAN routes, Sophos also recommends using Internet IPv4 group or the included default hosts as the destination instead of Any. This keeps the route limited to public IPv4 destinations and prevents internal traffic from entering the same path merely because the destination object is too broad.

Unlike system hosts that cannot be edited, the default internet hosts can be updated and deleted. Before doing so, refresh Object Usage as described below and check dependent rules and SD-WAN routes. This exception applies to internet hosts, not dynamic VPN/WWAN system hosts; interface addresses are still changed under Network > Interfaces.

Use MAC hosts for directly visible devices

A MAC host describes a device at Layer 2 and can contain a single address or a list. It only fits where the firewall sees the actual source MAC address. Behind a router, VPN, or NAT, it normally sees the MAC address of the next hop rather than that of the original client. An IP host or network is therefore usually the more stable object for routed rules.

Under Hosts and services > MAC host > Add, give the object a meaningful name and select MAC address or MAC list. An address can use colons, such as 00:16:76:49:33:CE, or hyphens, such as 00-16-76-49-33-CE; separate multiple entries with commas. A MAC list supports up to 1,000 MAC addresses.

A MAC host is not a device identity. A MAC address can be copied or spoofed and may change with docking stations, virtual machines, or private Wi-Fi addresses. The object is suitable as a restrictive match criterion in a controlled segment, but not as the only authentication or security boundary.

Example: Block a non-web flow by its source MAC

This SFOS 22/23 example blocks a new IPv4 iPerf3 TCP flow from a directly visible LAN test device to a controlled WAN test server. It is not a procedure for blocking all internet access: HTTP/HTTPS and Web Exceptions are outside this test. First use Packet Capture on the incoming interface to check the device’s actual source MAC. If only an upstream router is visible, this rule is unsuitable; a switch LAN port alone does not prove Layer 2 visibility. Before the change, check reachability of the WAN test server and TCP port 5201. It must actually run iPerf3, not a web service.

  1. Under Hosts and services > MAC host > Add, enter mac_test_client as Name, MAC address as Type, and 02:00:00:00:00:10 as MAC address, then select Save. The name and locally administered unicast address are examples; replace the address with the verified device MAC.
  2. Open Rules and policies > Firewall rules, select IPv4, and use Add firewall rule > New firewall rule to create drop_mac_test_wan. Set Action to Drop and enable Log firewall traffic.
  3. Set Source zones to LAN, Source networks and devices to mac_test_client, and Destination zones to WAN. Select the IP Host of the WAN test server under Destination networks and svc_iperf3_tcp under Services; create this TCP service with Destination Port 5201 as described in the next section. This keeps the destination and non-web test service narrowly scoped. Any is not required for this example.
  4. Set During scheduled time to All the time for a permanent block, otherwise choose the appropriate schedule. Place the rule above rules that would otherwise allow the same flow first, without displacing intentional higher-priority exceptions. Top is not a universal requirement. Rule group can remain None; a group does not replace correct positioning. Select Save and check the actual order.

Then initiate a new iPerf3 TCP connection attempt from the test device to the same WAN test server on port 5201, not a UDP or browser test. In Log Viewer, Drop and this blocking rule’s Rule ID must match the flow. Test the same non-web flow from a second, unblocked device: it should still match the intended Allow rule. Use fresh connections for both tests, not existing sessions. If the expected match is missing, check the source MAC in Packet Capture, zones, IP version, schedule, destination/service scope, and earlier rules.

This check establishes only the tested flows, not general web or internet blocking. IPv6, other destination zones, destinations, and services are not covered and need separate configuration and tests. To roll back, disable only the new blocking rule and check the previously allowed state with a fresh iPerf3 TCP flow. The spoofing and identity risk described above remains.

Create a service with the correct destination port

Before creating a service, check whether an appropriate default service already exists. A custom service is useful when an application requires a different port or a special protocol combination.

The following example creates the TCP service for iPerf3:

  1. Open Hosts and services > Services and select Add.
  2. Enter svc_iperf3_tcp as the Name.
  3. Set Type to TCP/UDP and Protocol to TCP.
  4. Leave the default Source Port of 1:65535 unchanged.
  5. Enter 5201 as the Destination Port.
  6. Select Save.

The client normally selects its source port dynamically. If the service also restricted the source port to 5201, a normal connection would no longer match. The fixed server port therefore belongs under Destination Port. A restricted source port is only correct when the protocol explicitly requires it and real traffic confirms the behavior.

For an iPerf3 UDP test, also create svc_iperf3_udp with protocol UDP and destination port 5201. Because iPerf3 still uses a TCP control connection for a UDP test, combine both services:

  1. Open Hosts and services > Service group and select Add.
  2. Enter grp_iperf3 as the Name.
  3. Select svc_iperf3_tcp and svc_iperf3_udp.
  4. Select Save.

The complete measurement procedure is described in iPerf3 speed test through Sophos Firewall.

A Service Group can combine default and custom services, and a service can be a member of several groups. Services and Service Groups do not distinguish between IPv4 and IPv6; the IP version is determined by the host objects and rule context. Default Service Groups cannot be edited or deleted, so create a new group for a custom combination.

Predefined services and services already used in Security Policies also cannot be edited or deleted. Rather than bypassing a dependency, create the required Custom Service, replace the old object methodically in the dependent policies, and then check the updated Usage display.

IP, ICMP, and ICMPv6

In addition to TCP and UDP, a custom service can specify an IP protocol number or ICMP/ICMPv6 types and codes. These types are intended for protocols that do not use a TCP or UDP port. Values should come from the application’s technical documentation rather than being guessed after a single failed test.

Under Hosts and services > Services > Add, a service can contain multiple entries of the same selected type. For ICMP or ICMPv6, first select the required type and code pair, use Add to include further type/code pairs, and Remove to delete unneeded entries. Then check all entries and select Save. This describes several required ICMP messages in one service without allowing every type indiscriminately. The separate TCP/UDP services and Service Group in the iPerf3 example remain a clear alternative when services need to be reused individually.

API documentation version note: In the saved Sophos “Add Service / Update Service” API table for SFOS 22, the Mandatory column labels both ICMPType and ICMPv6Type as No; for SFOS 23, both are labeled Yes. These are API documentation labels, not evidence of a GUI or runtime behavior change. They concern the ICMP/ICMPv6 fields and should not be read as a requirement to add both protocol families to TCP/UDP/IP services. The page does not define a conditional rule for when these fields may be omitted, so the labels do not establish specific payload or validation instructions.

Use objects in a firewall rule

A host or service object does not allow traffic on its own. It only takes effect when used as a match criterion in a rule. A restrictive example could look like this:

  • Source zones: LAN
  • Source networks and devices: net_test_branch
  • Destination zones: DMZ
  • Destination networks: host_test_web
  • Services: HTTPS
  • Log firewall traffic: Enabled

Adjust the zones, addresses, and service to the actual network. Return traffic for an allowed stateful connection is permitted automatically. However, this rule does not permit independent new connections from the DMZ to the LAN. A NAT rule alone does not grant permission either; a matching firewall rule is still required.

SFOS evaluates firewall rules from top to bottom and stops at the first match. Place the new, specific rule above a broader rule that would otherwise handle the same flow first. Understand and configure Sophos Firewall rules securely explains rule order, security features, and testing.

After saving, verify a real connection attempt in the Log Viewer. Use filters for the test address, port, and rule to isolate the correct flow, then check Rule ID, Source, Destination, and Service in the detail view. This distinguishes an incorrectly defined object from traffic being processed by a different rule. If a connection ends without a Destroy event recognized by the firewall, its final session entry may be missing; Packet Capture and Live Connections are then the better cross-check.

Refresh Object Usage before changes

An object can be used in firewall and NAT rules, VPNs, SD-WAN routes, or other configurations. Before changing or deleting it, first check its dependencies.

The Usage column in the object list shows the known number of references. This counter is refreshed automatically only once a day. Before making a change:

  1. Select Refresh next to Usage.
  2. Open the updated counter for the affected object.
  3. Expand the categories and inspect every dependent rule or policy.
  4. Only then decide whether the object can be changed, replaced, or deleted.

Not every dependency can be edited directly from the Usage view. Some dependencies, including WAN gateways and CLI configurations, must be opened separately at the indicated configuration location. A counter of zero is a reliable basis only after a manual refresh.

Operate objects safely

Avoid common mistakes

  • Host instead of Network: An individual IP address does not automatically cover the associated subnet.
  • Incorrect network address or mask: For a Network object, the network address and prefix must match the actual segmentation.
  • Restricted Source Port: For regular client-server connections, keep 1:65535; restrict the Destination Port.
  • Too much Any: A precise host object loses its security value if the source or service remains unnecessarily broad.
  • Duplicated system object: SFOS maintains interface and remote access hosts, so they should not be copied without a specific reason.
  • IP list used as a threat feed: An IP list remains static and is not a replacement for automatically updated threat indicators.
  • Dependencies not refreshed: Always select Refresh in Object Usage before editing or deleting an object.

Descriptive prefixes such as host_, net_, range_, svc_, and grp_ are not a technical requirement, but they make searches and reviews easier. More important than the exact naming scheme is consistent use of names, purposes, and scopes throughout the rule set.

Keep the object inventory small and traceable

SFOS supports up to 16,000 hosts across all host types. This is a platform limit, not a planning target. For day-to-day operations, a smaller, intelligible object inventory is more valuable than many barely distinguishable entries. Replace or remove objects that are no longer needed in a controlled manner, and only after refreshing and reviewing their Usage.