Skip to content
Avanet

Configure and validate RIP on Sophos Firewall

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 unintentionally distribute Connected or Static routes throughout the RIP routing 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.

Routers exchange routing updates periodically. The receiving router incorporates the changes into its routing table, increases the path metric by 1, and uses the sender as the next hop.

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.

Under RIP version, SFOS provides these three settings:

  • 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 be useful during a controlled transition, but it continues to accept RIPv1 updates. As soon as all peers use RIPv2, set both the send and receive versions 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.

Planning the example topology

The end-to-end example connects two LANs:

  • Firewall A: Transit IP 198.51.100.1/30, local LAN 10.10.10.0/24
  • 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. Replace the transit network, transit IPs, LAN prefixes, and test hosts consistently with values from your own environment. Do not use the documentation addresses unchanged in production. 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 make a controlled rollback possible.

Allowing Dynamic Routing narrowly

Under Administration > Device access, first check the zones for which Dynamic Routing is currently allowed. In the example, allow Dynamic Routing only for the dedicated transit zone or through an ACL exception for the peer.

The Device Access matrix applies to the entire zone. For a dedicated, trusted transit zone, you can enable Dynamic Routing there. If access must be limited to a specific peer or transit network, leave the zone checkbox cleared and instead create a narrow allow exception for the source and service under Local service ACL exception rule. Enabling access for the whole zone at the same time would defeat that restriction. Device Access and Local Service ACL explains the distinction.

This permission concerns RIP packets to the firewall and cannot be replaced by a normal firewall rule. The data stream between 10.10.10.0/24 and 10.20.20.0/24, by contrast, still requires normal firewall rules. Dynamic Routing is not enabled in the LAN zone merely because the LAN is advertised as a RIP Network. Document the effective Device Access state before the change rather than assuming a blanket default.

If both firewalls send RIP updates through the transit interface, but incoming updates are allowed only on Firewall A, route learning becomes one-sided: A receives B’s updates and learns 10.20.20.0/24 through 198.51.100.2. B continues to send its updates, but drops incoming updates from A because permission for Dynamic Routing is missing on B. B therefore does not learn A’s advertised route to 10.10.10.0/24 through RIP.

This is an asymmetry in the exchange of routing information (the control plane), not proof of a particular data-traffic failure. Check both sides under Routing > Information > RIP > Routes and verify the effective permission to receive updates on the firewall that is not learning routes. Any correction remains limited to the actual peer zone or a narrow ACL exception; do not enable blanket WAN access. Then check Route Lookup, firewall rules, NAT, and the real forward and return paths separately.

Configuring RIPv2 in WebAdmin

The example uses a second Sophos Firewall on side B. With two Sophos Firewalls, mirror the configuration on the peer; only the transit IP and local LAN differ. For a router from another vendor, configure RIPv2, the transit network, local LAN, Passive Mode, and any authentication using that device’s corresponding features.

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. Select Apply to save the changes.

Default information originate generates and advertises a default route into the RIP domain and is disabled by default. 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.

The Default metric for redistributed routes defaults to 1; the permitted range is 1 to 16. Administrative distance defaults to 120 and accepts values from 1 to 255. Leave both values unchanged unless the routing design documents a reason to alter them.

Administrative distance helps the router choose the better route between competing routing sources; the RIP metric instead compares paths within RIP.

The defaults for Update, Timeout, and Garbage are 30, 180, and 120 seconds. Update determines the interval between two periodic routing updates. The official SFOS 22.0 documentation lists 5 to 2147483647 seconds for each of these three timers; the SFOS 23.0 documentation lists 1 to 32767 seconds for each and calls Timeout Time-out. These are version-specific documentation values, not a guarantee of input validation on a tested build. This example retains the defaults; choose different values only when both peers share a documented timer and failure-handling design.

If redistribution is deliberately required, enable only the planned sources under Routing > RIP: Redistribute connected for directly connected routes, Redistribute static for static routes, Redistribute OSPF for OSPF routes, and Redistribute BGP for BGP routes. Set the corresponding redistributed-route metric for each enabled source; all four fields allow 0 to 16, unlike the global Default metric. Choose values from the documented routing design rather than copying a blanket value. Save with Apply, then check expected and unexpected prefixes and the return path as described below. All four sources remain disabled in the example.

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, use Select interface to choose the participating interface.

Send and Receive each independently allow V1, V2, or both versions. Each interface selection overrides the global RIP version. Send defaults to V2; the receive version V2 chosen below is a deliberate example setting, not a claim about the Receive default. Passive mode is disabled by default and is deliberately enabled for the LAN.

For an intentionally authenticated RIPv2 connection, enable Authentication and enter a password; the configuration must match on both peers. If authentication is selected for an RIPv1 interface, it sends routing updates but does not accept routes. With both versions selected, RIPv2 continues to work with authentication. Sophos recommends configuring RIPv1 on a different interface from authenticated RIPv2.

For the transit interface:

  • Send version: V2
  • Receive version: V2
  • Passive mode: off
  • Split horizon: retain the documented previous state; SFOS disables this option by default
  • Poisoned reverse: available only when Split Horizon is enabled and disabled by default
  • Authentication: check the effective previous state and deliberately set both sides identically

For the LAN interface:

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

Save the selection with Save. 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. The public SFOS 22 CLI help and WebAdmin help disagree about the default authentication state. This guide therefore assumes no default: check both transit interfaces and then configure them deliberately and identically.

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 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 local-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.

Why this guide uses WebAdmin for changes

The documented CLI entry differs by version: The SFOS 22.0 help lists 3. Route Configuration > 1. Configure Unicast Routing > 1. Configure RIP, the rip> prompt, followed by enable. The SFOS 23.0 help instead lists 3. Route Configuration > 1. Configure Unicast Routing, the router# prompt, followed by router#configure terminal. The table entry router rip is a CLI command, not an additional menu selection. This compares the documented entry points; it is not an executable configuration sequence.

The public SFOS 22 CLI help contains incorrectly concatenated authentication commands and does not document every command required for saving and validation. The SFOS 23.0 help also remains ambiguous about the CLI contexts for authentication and the MD5 example. Corrected plaintext examples do not automatically make the remaining commands a reliable sequence. This guide infers neither unverified syntax nor context-switching or saving steps from that material.

Configuration and rollback therefore use the documented WebAdmin fields. Use the CLI only for read-only support diagnostics documented for the installed SFOS version.

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.

Within RIP, SFOS retains the route with the lowest hop metric for a destination. That alone does not prove that this path is also the active system-wide route. 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 treats three questions separately: Are routes exchanged, is the correct route selected, and does data traffic work?

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
  • route From, Tag, and Time
  • inbound and outbound update filters, if configured
  • Key-chain name, if configured
  • Bad Packets and Bad Routes

A visible RIP route confirms the routing exchange, but not that SFOS selects it or carries data over it. The status view does not prove which secret is in use; manage and verify that secret under controlled procedures on both peers.

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.

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.

If the Bad Packets or Bad Routes counters rise under Status, compare the version, authentication, subnet, and peer configuration. If the counters remain unchanged and the diagnostic views show no RIP traffic from the peer, check the interface assignment and Local Service ACL first. Change global RIP values only after those checks.

The route appears under RIP but is not used

The protocol exchange is then working. Route Lookup shows which path is actually active. The RIP metric compares RIP paths; by itself, it 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

If no updates arrive before the configured Timeout expires, the route becomes invalid; during the Garbage period, SFOS advertises it with metric 16 and then deletes it. Compare reachability, peer state, and the Update, Timeout, and Garbage values on both sides before changing any timer.

Unexpected networks are advertised

Check RIP Networks, Default information originate, and each redistribution option individually. Redistribution can include more Connected or Static routes than the LANs intended for this example. Leave it disabled until every prefix that should actually be distributed is known.

Reverting the change safely

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

Rollback starts with the replacement path, not by removing the active RIP routes:

  1. Enable the alternative static or dynamic route and validate it with Route Lookup, management access, and real bidirectional traffic.
  2. Disable newly enabled redistribution and Default information originate if they were deliberately part of the test; then check the expected prefixes again.
  3. Remove local RIP Networks one by one, checking the forward and return paths after each step.
  4. Return interface overrides and global RIP settings to their documented previous state.
  5. Remove Dynamic Routing from the transit zone or the ACL exception last, and only if no OSPF, BGP, or PIM neighbor also requires it.
  6. Finally, 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.

Approval check

  • Both firewalls show the expected RIP routes with the correct next hop and a plausible metric.
  • Route Lookup confirms the intended forward and return paths.
  • No unexpected prefixes or unintended redistribution appear.
  • Narrow, logged firewall rules apply without unintended SNAT.
  • A real service works bidirectionally.
  • The replacement path and rollback procedure are documented and executable.