Configure and validate RIP on Sophos Firewall

RIP automatically distributes IPv4 routes between routers. On Sophos Firewall, the protocol is best suited to small or existing routing domains in which a few routers need to exchange networks without complex path selection.

The safe short procedure is:

1. Document the transit network, local LANs, peer, expected prefixes, and return path.
2. Prepare a configuration backup and independent management access.
3. Test direct IP reachability between the transit addresses.
4. Under Administration > Device access, allow Dynamic Routing only for the peer zone or a narrow exception.
5. Under Routing > RIP, select RIPv2 and initially leave the global timers unchanged.
6. Add the transit and local LAN networks under RIP Networks.
7. Set the LAN interfaces to Passive mode using Override interface configuration.
8. Match the version and authentication on the transit interface with the peer.
9. Under Routing > Information > RIP, check the status and learned routes.
10. Test Route Lookup, the Firewall Rule ID, and a real bidirectional service.

⚠️ Default information originate and redistribution of Connected, Static, OSPF, or BGP remain disabled until every advertised prefix and its return path are known. Broad redistribution can unexpectedly distribute management, transit, blackhole, or other internal routes throughout the RIP domain.

This procedure covers RIPv2 for IPv4 in Gateway Mode. RIPv1 is discussed only as a legacy interoperability case. Sophos Firewall does not support RIP in Transparent Mode.

When RIP fits and when it does not

RIP is a distance-vector protocol. It evaluates a path by the number of router hops. A route with a lower metric is preferred. A maximum of 15 hops is reachable; metric 16 means unreachable.

This simple model is an advantage when:

• only a few routers are involved,
• the topology is small and largely stable,
• an existing peer supports only RIP,
• automatic route maintenance is more important than fast convergence and complex policy.

For a single fixed path, a static route is often simpler. With multiple redundant paths, fast convergence, or larger internal networks, OSPF is usually the more suitable protocol. BGP belongs in designs with autonomous systems, providers, or deliberate routing policy.

RIP does not replace a firewall rule and does not monitor application quality. An SD-WAN route is the appropriate layer for selection by source, service, application, latency, jitter, or packet loss.

Distinguishing RIPv1 and RIPv2

Use RIPv2 for new configurations. It carries subnet masks and supports authentication. RIPv1 is classful, does not carry subnet masks, and does not support authentication on Sophos Firewall.

Among other options, SFOS provides these global choices:

• Send V2 and receive both: Send RIPv2 and receive RIPv1 and RIPv2
• V1: Send and receive RIPv1
• V2: Send and receive RIPv2

In the example, both peers use RIPv2. Send V2 and receive both can ease a controlled transition, but it broadens the accepted input. As soon as all peers speak RIPv2, both sending and receiving are limited to V2.

Understanding RIP Networks and Passive Mode

A RIP Network is not the remote destination network. The entry activates RIP on local interfaces whose IP address matches the specified network. This brings the directly connected network into the RIP process so it can be advertised.

For the example, both the transit network 198.51.100.0/30 and the local LAN 10.10.10.0/24 are entered on Firewall A:

• The transit network activates RIP on the peer-facing interface.
• The LAN is advertised as a reachable local network.
• Passive mode on the LAN interface prevents the firewall from sending RIP updates there.

Passive Mode does not remove the LAN from the routing process. It only prevents RIP advertisements from being sent through that interface. In addition, Dynamic Routing remains disabled in the client zone so that clients cannot send routing updates to the firewall.

The global Default metric is the starting metric for redistributed routes. The default value is 1. Administrative distance decides between competing routing sources; Sophos uses 120 for RIP by default. These values are not changed without a documented reason.

The default timers are:

• Update: 30 seconds
• Timeout: 180 seconds
• Garbage: 120 seconds

Timers are coordinated across all peers. Aggressively shortened values can cause routes to be unnecessarily removed and relearned during packet loss or high load.

Planning the example topology

The continuous example connects two LANs:

• Firewall A: Transit IP 198.51.100.1/30, local LAN 10.10.10.0/24
• Router or Firewall B: Transit IP 198.51.100.2/30, local LAN 10.20.20.0/24
• Transit network: 198.51.100.0/30
• Test client A: 10.10.10.10
• Test server B: 10.20.20.10

198.51.100.0/24 is reserved for documentation. In a real environment, replace the transit addresses, interfaces, zones, and LAN prefixes together. The two transit IPs must be directly reachable.

Firewall A must learn 10.20.20.0/24 through 198.51.100.2. The peer must learn 10.10.10.0/24 through 198.51.100.1. Only this forward and return path permits routed traffic without source NAT.

Before the change, document the interface, zone, existing routes, Route Precedence, expected metric, and a reachable test host. A current configuration backup and a management path independent of the new routing simplify recovery.

Allowing Dynamic Routing narrowly

Under Administration > Device access, Dynamic Routing is disabled for all zones by default. For the example, it is allowed only in the zone of the transit interface.

The Device Access matrix applies to the entire zone. If other untrusted interfaces share that zone, a narrow Local Service ACL Exception for the transit network and intended peer is better. Device Access and Local Service ACL explains the separation.

This permission concerns RIP packets to the firewall. The data stream between 10.10.10.0/24 and 10.20.20.0/24 still requires normal firewall rules. Dynamic Routing is not enabled in the LAN zone merely because the LAN is advertised as a RIP Network.

Configuring RIPv2 in WebAdmin

The configuration is mirrored on both peers. Only the transit IP and local LAN differ.

1. Set the global values

Open the global settings under Routing > RIP:

1. Set RIP version to V2.
2. Leave Default metric at its existing default of 1.
3. Leave Administrative distance at its existing default of 120.
4. Initially leave Update, Timeout, and Garbage at 30, 180, and 120 seconds.
5. Leave Default information originate disabled.
6. Do not enable redistribution.
7. Save the changes.

Default information originate advertises a default route into the RIP domain. This is appropriate only when this firewall is deliberately intended to be the exit for all unknown destinations and both the return path and failure case are planned.

2. Add RIP Networks

Under Routing > RIP > RIP Networks > Add, enter these local networks on Firewall A:

1. 198.51.100.0 with subnet mask 255.255.255.252
2. 10.10.10.0 with subnet mask 255.255.255.0

On peer B, enter the same transit network and 10.20.20.0/24.

Before saving, check which local interface each Network matches. An overly broad Network can activate RIP on additional interfaces and bring more directly connected networks into the process.

3. Set interface overrides

Under Routing > RIP > Override interface configuration, select the participating interfaces.

For the transit interface:

• Send version: V2
• Receive version: V2
• Passive mode: Off
• Split horizon: Appropriate for the peer and hub design
• Authentication: Identical on both sides when used

For the LAN interface:

• Send version: V2
• Receive version: V2
• Passive mode: On

RIPv2 supports plaintext and MD5 authentication. Plaintext does not protect the password. MD5 authenticates routing updates, but it encrypts neither prefixes nor metrics. Transit segments therefore remain limited to the intended routers. For new, more strongly protected, or larger designs, a more modern routing protocol over a controlled transport is usually more suitable.

Split horizon normally prevents a route learned through an interface from being advertised back through the same interface. Poisoned reverse can explicitly advertise it there with metric 16 as unreachable. Change these options only when required by the hub, spoke, or multi-access topology and test them together with the peer.

4. Mirror the peer

On Router or Firewall B, set the same version, timers, and authentication. Use 198.51.100.0/30 and 10.20.20.0/24 as Networks, and make the receiver-LAN interface passive.

A one-sided configuration is not sufficient. Without advertisement of the return network, Firewall A may learn the remote LAN, but replies have no path back.

Firewall rules, NAT, and Route Precedence

For the test, both firewalls need narrow, logged rules for the services actually required between 10.10.10.0/24 and 10.20.20.0/24. Create firewall rules correctly explains the rule mechanics.

In a normally routed site network, source NAT remains disabled. Both sides should see the real source address and know the return path through RIP. SNAT can hide missing return routes and complicate later analysis and access control.

A learned RIP route does not necessarily win automatically. Longer prefixes take precedence; routing source, Administrative Distance, and global Route Precedence then also matter. When a static, SD-WAN, or VPN route competes, use Diagnostics > Tools > Route lookup to check the path actually selected. Do not globally change Route Precedence for a single RIP test.

Validating RIP and the real data path

Validation separates routing exchange, selected route, and data flow.

Check Routes and Status

Under Routing > Information > RIP > Routes, Firewall A must show network 10.20.20.0/24 with next hop 198.51.100.2 and a plausible metric. Peer B must know 10.10.10.0/24 through 198.51.100.1.

Under Routing > Information > RIP > Status, compare:

• participating interfaces
• sent and received RIP versions
• Update, Timeout, and Garbage timers
• routing sources and redistribution
• Bad Packets and Bad Routes
• authentication or Key Chain in use

A visible entry confirms the RIP exchange, but not yet whether that route is selected or data traffic passes.

Test Route Lookup and traffic

1. On Firewall A, check destination 10.20.20.10 under Diagnostics > Tools > Route lookup. The next hop and interface must match the transit path.
2. On peer B, check destination 10.10.10.10.
3. From client 10.10.10.10, start a real permitted connection to server 10.20.20.10.
4. In Log viewer, check source, destination, service, Firewall Rule ID, Action, and any NAT Rule ID.
5. Under Diagnostics > Packet capture, confirm that request and reply traverse the expected interfaces.

The complete procedure is described in Test a firewall rule with Log Viewer and Packet Capture.

For a read-only control-plane test, briefly filter for RIP packets in Device Console:

tcpdump 'udp port 520'

Stop the output with Ctrl+C. Updates are expected between the two transit addresses. RIP packets from a client LAN, by contrast, indicate an incorrect interface or Device Access boundary in this example.

In Advanced Shell, the logs provide additional context:

cd /log
tail -f ripd.log

ripd.log shows protocol-specific events. zebra.log helps determine whether a dynamically learned route was installed in the routing stack. Stop the live output with Ctrl+C; tail -f zebra.log can then be used. Sophos Firewall service and log files maps additional files.

Troubleshooting systematically

No RIP route appears

First test direct reachability between the transit addresses. Next, Dynamic Routing must be enabled in the correct peer zone, a RIP Network must match the local interface, and compatible send and receive versions must be present. When authentication is used, the method and secret must match.

tcpdump 'udp port 520' separates missing packets from rejected or unusable updates. If the Bad Packets or Bad Routes counters rise under Status, compare version, authentication, subnet, and peer configuration.

The route appears under RIP but is not used

The protocol exchange is then working. Route Lookup shows whether a more specific prefix, static route, SD-WAN, VPN, or another Administrative Distance wins. The RIP metric alone does not decide between all routing sources.

Do not remove global Route Precedence or an existing production route before its effect on other networks is documented.

Traffic works in only one direction

The peer needs the return route, and both firewalls need matching rules. Also check NAT, asymmetric paths, and the host gateway. An existing forward path does not prove the return path.

The route disappears and reappears

An unstable transit link, packet loss, peer restarts, mismatched timers, or authentication errors can trigger the timeout. Compare Update, Timeout, and Garbage values on both sides. Do not shorten timers on suspicion; first prove the packet path and peer state.

Unexpected networks are advertised

Check RIP Networks, Default information originate, and each redistribution option individually. Redistribute connected can include more interfaces than the planned LAN alone. Redistribute static can also distribute blackhole or management routes. Leave the function disabled until a complete prefix list and filtering strategy are available.

Testing HA and failover in a controlled manner

In an HA cluster, after a planned failover check again on the current Primary:

• RIP Status and participating interfaces
• learned routes and their age
• Route Lookup for both LANs
• ripd.log and zebra.log on the node that processed the event
• a new bidirectional test connection

Perform the test in a maintenance window. This article promises neither uninterrupted RIP convergence nor preservation of existing sessions. Logs are stored per processing node and are therefore collected from both appliances when required.

Reverting the change safely

Before removing RIP, an alternative path or planned maintenance window must exist for every learned destination network.

Revert in the reverse order:

1. Disable newly enabled redistribution and Default information originate if they were deliberately part of the test.
2. Remove the local RIP Networks.
3. Return interface overrides to their documented previous state.
4. Revert the global RIP settings.
5. Remove Dynamic Routing from the transit zone or the ACL exception only if no OSPF, BGP, or PIM neighbor also requires it.
6. Enable the alternative static or dynamic route in a controlled manner.
7. Recheck Route Lookup, rules, management access, and real traffic.

Do not remove RIP and the replacement path at the same time. Keep an existing administrator session open until the return path is confirmed.

Checklist

• Gateway Mode, interfaces, zones, and transit addresses are documented.
• A backup and independent management access are available.
• Both transit IPs can reach each other directly.
• Dynamic Routing is permitted only for the peer zone or narrow exception.
• Both sides use compatible RIPv2 and authentication values.
• RIP Networks match only the intended local interfaces.
• Client-LAN interfaces use Passive Mode.
• Default Route Origination and redistribution are enabled only deliberately.
• Routes and Status show the expected prefixes, next hops, and timers.
• Route Lookup confirms the selected forward and return paths.
• Firewall rules are narrow, logged, and free of unintended SNAT.
• A real service works bidirectionally.
• Rollback and HA testing are documented.

FAQ