Configure IPv6 Router Advertisement on Sophos Firewall

An IPv6 client can have an address and still lack a working network. On Sophos Firewall, Router Advertisement, or RA, provides the prefix, default router, and information about whether SLAAC or DHCPv6 is responsible for additional values. DHCPv6 alone does not provide a default gateway.

The most common error is therefore not an incorrect lease range, but an unsuitable combination of RA prefix, flags, and DHCPv6 role. A simple SLAAC network normally only needs an advertised /64 with Autonomous. If a DHCPv6 server is to assign addresses, Managed flag is also required. Other flag points clients to additional DHCPv6 parameters such as DNS or Domain Name.

⚠️ An incorrect Router Advertisement can change addresses or the default router across the entire Layer 2 segment. Document existing RA sources, IPv6 prefixes, and management access before saving. Test the change first in a pilot VLAN with a real client.

Router Advertisement in eight steps

1. Define the intended IPv6 /64, client segment, and the required roles of SLAAC and DHCPv6.
2. Check whether a router is already sending RA messages or Prefix Delegation has automatically created an RA configuration.
3. Open Network > IPv6 router advertisement and select Add.
4. Select the IPv6-enabled physical interface, LAG, VLAN, or bridge interface for the client segment.
5. Set the minimum and maximum advertisement intervals to suit the environment.
6. Enable Managed flag, Other flag, and Default gateway only in accordance with the planned client model.
7. Add the /64 with On-link, Autonomous, Preferred lifetime, and Valid lifetime.
8. Save and use a new client run to verify RS, RA, address, default gateway, DNS, and real IPv6 application traffic.

A visible RA entry is not yet proof of success. Only the client shows whether the operating system, prefix, DHCPv6, and default route implement the same plan.

Understand SLAAC, DHCPv6, and the two flags

Independently of this, an IPv6-enabled interface automatically creates a link-local address for communication on the local segment; no RA is required for this. This local address is distinct from the global SLAAC address and does not prove that global address configuration is working. A global address alone is not proof of internet access either.

With SLAAC, the client forms its global IPv6 address from the advertised prefix and its interface identifier. The prefix must allow Autonomous for this to work. The firewall also announces the default router through RA when Default gateway is enabled.

Managed flag means that clients should obtain their IPv6 address from a DHCPv6 server. Sophos explicitly states that this flag should only be used when a DHCPv6 server is available. The complete server procedure is described in Set up and test a DHCPv6 server on Sophos Firewall.

Other flag directs clients to DHCPv6 for additional network parameters. These can include DNS servers, Domain Name, NIS, NISP, SIP, SNTP, and BCMS. The flag does not provide these values itself; DHCPv6 must actually supply them and the client must support them.

Depending on the operating system, a client may create multiple addresses or interpret flags differently. The intended combination must therefore be verified with the client platforms actually in use, rather than inferred solely from the WebAdmin form.

Choose the address model deliberately

The three switches perform different jobs: Managed flag and Other flag are in the RA header, while Autonomous belongs to each advertised prefix. Default gateway is independent again. This supports the following common models:

• SLAAC only: Turn on Autonomous and Default gateway, and leave Managed flag off. Leave Other flag off if the client should not obtain additional values through DHCPv6.
• SLAAC plus stateless DHCPv6: Turn on Autonomous, Default gateway, and Other flag, and leave Managed flag off. SLAAC creates the address; DHCPv6 supplies values such as DNS.
• Stateful DHCPv6: Turn on Managed flag and Default gateway, and make sure a DHCPv6 server is reachable. Leave Autonomous off if the client should not also create a SLAAC address; turn on Other flag for additional DHCPv6 parameters.
• Coexistence: If Autonomous and Managed flag are on, clients can use SLAAC and DHCPv6 in parallel. Choose this only when multiple addresses are intentional and the deployed operating systems have been checked.

The documented SFOS 22 RA form has no RDNSS or DNSSL field. To distribute DNS through this Sophos workflow, therefore plan Other flag and a DHCPv6 server together. This doesn’t affect static client configuration.

Automatic RA with Prefix Delegation

When IPv6 prefix delegation is selected on an internal interface, SFOS automatically creates a Router Advertisement. The automatically assigned prefix of this RA server cannot be changed. To advertise an additional prefix, create another RA server with that prefix.

Automatic creation is convenient, but must not be overlooked. The SFOS 21.5 GA release notes also state that RA and the DHCPv6 server are enabled by default for DHCP Prefix Delegation. Before creating a manual RA entry, check the internal interface and Network > IPv6 router advertisement for configurations that actually exist and are active on the specific SFOS 22 system. Configure IPv6 Prefix Delegation on Sophos Firewall explains the complete provider, WAN, and delegated-interface procedure.

An important distinction for the address model: According to the SFOS 22 help, the DHCPv6 server option on an internal interface in Delegated mode only supplies additional parameters such as DNS; it doesn’t assign IPv6 addresses. Stateful DHCPv6 instead requires a separate address-assigning server under Network > DHCP.

Plan the example network

The following example uses 2001:db8::/32, which is reserved for documentation. It is not intended for production internet communication and must be replaced with the prefix actually assigned:

• Client segment: VLAN20
• Firewall address: 2001:db8:20::1/64
• Advertised prefix: 2001:db8:20::/64
• Operating mode: SLAAC with default gateway
• DHCPv6: only for additional DNS parameters, if required
• Test client: a managed device in VLAN20

The prefix, interface address, and client segment must belong together. An RA configuration copied from another VLAN can give clients a formally valid address that cannot be used by the local routing design.

Configure Router Advertisement

Select the interface and intervals

Under Network > IPv6 router advertisement > Add, first select the client interface. SFOS permits an IPv6-enabled physical interface, LAG, VLAN, or bridge interface. Do not select a WAN or transit interface simply because the provider prefix arrives there; the Layer 2 client segment is what matters.

Min advertisement interval and Max advertisement interval determine the gap between unsolicited RA messages. If the maximum interval is nine seconds or more, SFOS requires the minimum to be 75 percent of the maximum. There is no universal ideal value: changes affect discovery time and message density, so they must only be made with a documented baseline and a client test.

Set flags and the default gateway

For the SLAAC example, leave Managed flag off. Enable Other flag only if a reachable DHCPv6 server actually supplies additional values. Default gateway makes the firewall the advertised default router; the associated time is specified in seconds.

An enabled flag is not proof of functionality. If Managed flag is set but no DHCPv6 server responds, address configuration remains incomplete. If Default gateway is off, a client may still form a global address, but it does not receive a default route from this RA.

Enter the prefix and lifetimes

According to Sophos, an RA can contain zero or more prefix options. The default router, M/O flags, and advertised prefix are therefore separate decisions: An RA without a prefix can still provide router information, but it doesn’t create a SLAAC address for this segment.

For this example, enter 2001:db8:20::/64 in the prefix advertisement configuration. The field expects exactly one /64; first divide a larger delegated provider prefix into suitable /64 client networks. On-link tells the client that destinations within this prefix are reachable on the local segment without another router. Autonomous permits automatic address creation through SLAAC.

Preferred lifetime specifies in minutes how long an address is preferred for new connections. It then becomes deprecated but can continue to be used for existing communication. Valid lifetime specifies how long the address remains valid overall. After expiry, it can no longer send or receive. SFOS therefore requires a Valid lifetime that is at least as large as the Preferred lifetime.

With SLAAC, a subsequent RA containing a matching prefix eligible for SLAAC can refresh the Preferred lifetime based on the newly received value. An address assigned through DHCPv6 can be refreshed through DHCPv6 renewal. Continued RA reception alone does not guarantee a permanently preferred state: an advertised Preferred lifetime of zero causes deprecation, while one that is too short can expire before the next refresh.

For dynamic provider prefixes, these times must not be planned as though the prefix were guaranteed to remain unchanged. A prefix change must be tested with a fresh client run and both existing and new connections.

Handle MTU and neighbor parameters deliberately

The advanced fields control information for IPv6 Neighbor Discovery:

• Link MTU advertises the maximum packet size in bytes. At 0, the interface does not advertise MTU information.
• Reachable time determines how long a client considers a confirmed neighbor reachable.
• Retransmit time determines the wait before another Neighbor Solicitation.
• Hop limit limits the number of router hops; each router reduces the value.

Do not use these values as general performance-tuning controls. An MTU or neighbor change requires a concrete symptom, a recorded baseline, and renewed tests for large packets, Neighbor Discovery, and real applications.

API only: object name and status in SFOS 22/23

API automation must account for the SFOS version. These differences concern the API schema, not the WebAdmin steps above; they do not establish an additional GUI field.

For Add Router Advertisement and Update Router Advertisement, SFOS 23 requires a unique Name for the intended RA object in addition to the still-mandatory Interface. Name is documented as SCALAR with datatype STRING: at most 64 characters, no comma, UTF-8 characters allowed. The SFOS 22 schema has neither this parameter nor its corresponding sample element.

For Delete Router Advertisement, Interface is the mandatory selector in SFOS 22; SFOS 23 replaces it with Name, subject to the same naming rules. Before deleting, clearly identify the intended RA object, its name in SFOS 23, and its associated client interface, and record the working RA source and its configuration. Do not delete an existing working entry as a precaution. If the previous source was replaced, follow the recovery procedure below: restore the previous source first, then disable the new entry.

The SFOS 23 API status table newly lists 505 for both Add and Update with the symbolic message key Message.RouterAdvertisementNameRecordExists; SFOS 22 lists only 200 and 500 for these operations. The key points to an existing name. If this result occurs, check the intended object and the uniqueness of Name rather than blindly deleting and recreating it. Here, 505 is a documented API status, not a statement about an HTTP status. The table does not establish verified message wording, tested appliance behavior, update matching, renaming, or migration rules.

Verify RA and client behavior

After saving, reconnect the pilot client or renew its IPv6 configuration in a controlled manner. A packet capture using the BPF filter icmp6 must show the client’s Router Solicitation as ICMPv6 Type 133 and the firewall’s Router Advertisement as Type 134. Type 135 is a Neighbor Solicitation and must not be mistaken for an RS during analysis.

Then verify the layers separately:

1. The RA arrives on the expected interface and from the expected router.
2. The prefix, On-link, Autonomous, and flags match the plan.
3. The client has the expected global IPv6 address and a default gateway.
4. If Managed flag or Other flag is enabled, DHCPv6 supplies the intended values.
5. Internal and external DNS names resolve through the planned servers.
6. A real IPv6 flow matches the expected Firewall Rule ID and the negative test remains blocked.

Packet Capture in Sophos Firewall WebAdmin explains the WebAdmin capture and its fields. Sophos Firewall IPv6 support and limitations in SFOS 22 remains relevant for the general IPv6 firewall-rule, routing, and VPN matrix.

Troubleshoot systematically

The client sends RS, but the firewall does not respond

Check the interface, IPv6 address, RA status, and any existing automatic Prefix Delegation configuration. Then correlate radvd.log with the test time. A service restart is not the first diagnostic step; configuration, capture, and log evidence should establish the missing response path first.

RA arrives, but the client receives no global address

Compare the advertised /64, Autonomous, and the RA actually received. If Managed flag is enabled, also check DHCPv6 communication over UDP 546 and 547. A visible RA alone is not proof of a complete address assignment.

The client has an address but no default gateway

Check whether Default gateway is enabled and which router lifetime is received in the RA. DHCPv6 cannot replace this missing default route. If several Router Advertisements are visible, assign each source using its source address and incoming interface. Allowed RA servers under Network > Interfaces > [edit interface] > Advanced settings only restricts the RA servers from which the firewall itself accepts stateless configuration; it doesn’t filter RA messages for other clients on the Layer 2 segment.

Address and gateway are correct, but DNS is missing

When using Other flag or a DHCPv6 model, the DHCPv6 server must actually supply the intended DNS values. Then compare the client request, server response, and local resolver configuration. Setting the flag alone does not create a DNS server.

IPv6 only works partially

Check the route and return path first, followed by the IPv6 firewall rule and Rule ID. For large packets, also compare the Link MTU actually advertised with packet capture and an application test. IPv4 success is not proof of the separate IPv6 data path.

Prefix Delegation created a different prefix

The prefix of an RA configuration created automatically by Prefix Delegation cannot be replaced manually. Check the provider prefix, delegated interface, and existing RA entry together. An additional prefix requires its own RA server and a fully working routing path.

Check Sophos Firewall services and logs using the CLI lists the relevant services and log files, including radvd.log.

Roll back the change

For a state-preserving recovery path, record the interface, status, intervals, flags, default-gateway time, all prefix options, lifetimes, and advanced settings before the change. Do not delete an existing working RA entry as a precaution.

If the previous RA source remained active during the test, rollback only requires disabling or removing the new manual entry. If the previous source was replaced, restore it with the documented values first and only then disable the new entry so that there is no interval without the intended router. Do not treat a configuration created automatically through Prefix Delegation as an independent manual entry; return the documented interface and delegation setting to its previous state.

Then reconnect the client and verify the RA source, address, default gateway, DNS, and a real IPv6 data path again. Previously received addresses and routes can remain visible until their advertised lifetimes expire, so do not leave old and new RA sources active in parallel without control or rely only on the values already present on the client.

Frequently asked questions