Allowing RIPv2 traffic between cOS Core interfaces

Last modified on 6 Apr, 2023. Revision 9
This article will describe how cOS Core can be configured to allow the Routing Information Protocol (RIP) to pass through a NetWall firewall. RIP is an older protocol that may still be used in some smaller enterprise networks.
Up to date for
cOS Core 14.00.09
Supported since
cOS Core 9.30.xx
Status OK
Peter Nilsson


The Routing Information Protocol (RIP) is a distance-vector routing protocol, which employs the hop count as a routing metric. RIP prevents routing loops by implementing a limit on the number of hops allowed in a path from the source to a destination. It is an open standard routing protocol that is used in local area networks (LANs) and small to medium-sized enterprise networks. RIPv2 is defined in RFC-2453 and is an extension of the original Routing Information Protocol (RIP). RIPv2 was widely used in the past for small to medium-sized enterprise networks, but its popularity has decreased over time. This is because RIPv2 has some limitations compared to other routing protocols, such as OSPF and EIGRP, which offer more advanced features and better scalability for larger networks.

The maximum number of hops allowed for RIP is 15. This hop limit, however, also limits the size of networks that RIP can support. A hop count of 16 is considered an infinite distance and used to deprecate inaccessible, inoperable, or otherwise undesirable routes in the selection process. RIPv2 uses UDP destination port 520.

In an effort to avoid unnecessary load on hosts that do not participate in routing, RIPv2 multicasts the entire routing table to all adjacent routers at the address, as opposed to RIPv1 which uses broadcast. Unicast addressing is still allowed for special applications. You can use Clavister cOS Core to allow RIPv2 routers placed on separated physical interfaces to exchange multicast routing messages.

Note: Clavister cOS Core does not support RIP but can be configured to allow the needed traffic to pass through it.

Configuring cOS Core

IP settings

In order to allow multicast messages to be forwarded we must change the ‘Multicast TTL Min’ value in the Clavister security gateway. By default multicast messages with TTL values lower than 3 will be dropped. This needs to be changed to 1.


Before we start we create a service for the RIPv2 port needed as shown below.

IP policy setup

In this example we create two Multicast IP policies for the respective RIPv2 routers, in this example we have two RIPv2 routers placed behind the interfaces called WAN and LAN.

Let´s start by creating an IP policy for our primary router located on the “LAN” interface. The router sends multicast messages to which should be received by a router located on the WAN interface. The first IP policy in this example is a Multicast policy that forwards the router exchange traffic destined to address, which is the RIPv2 multicast address, to find adjacent routers and exchange routing tables. We create a multicast IP policy that will allow traffic from the router that sends the multicast messages. Follow the configuration image and make sure that the destination address is set to Change the interfaces and source IP to the corresponding router IP in your configuration when appropriate if we want to further restrict the IP policy to only allow RIPv2 from the actual router(s), in this example we leave things fairly open but it is recommended to restrict it more before going live (can be useful for testing purposes).

We need to make sure to tell the firewall where to forward the messages that we receive from the RIPv2 router on the LAN interface in this example, we do that by adding the WAN interface a under the destination translation option, we leave the IP address field blank (don’t forget to press the plus button when adding). Make sure to uncheck the “Require IGMP” check-box(1). We do not want to create additional IGMP rules in order to forward the RIPv2 traffic.

Create one more multicast IP policy for the opposite direction from the interface WAN to LAN (and change the destination translation interface to be LAN). When done the IP rule section should look like this.

Now our RIPv2 routers will be able to exchange their routing tables when they are located on separate interfaces in the Clavister firewall. The firewall will receive the multicast message and forward it to the corresponding interface.

Related articles

Setup of a Layer-3 bridge over IPsec in cOS Core
12 Apr, 2023 core proxyarp arp ipsec routing
cOS Core IKEv2 split tunneling with Windows and local user database.
28 Mar, 2023 ikev2 windows vpn routing splittunneling
Problem with auto-created Core routes
22 Mar, 2021 core ipsec routing
Setting up OSPF with IPsec in cOS Core
16 Apr, 2024 core routing ospf ipsec
Using /31 network masks in cOS Core (RFC-3021)
1 Jun, 2022 core routing management
The meaning of the Default_Access_Rule log entry
7 Nov, 2022 core arp log routing
Troubleshooting cOS Core rules/routes with ping simulation
17 Mar, 2023 core routing rules ping icmp cli
Is Statless (FwdFast) faster than a normal IP policy?
27 Jan, 2021 core stateless routing brokenlink
Route failover with IPsec tunnels in cOS Core
13 Feb, 2023 ipsec core routing failover
Public network transparency using cOS Core Proxy ARP instead of subnetting
18 Apr, 2023 core routing transparentmode proxyarp