Using /31 network masks in cOS Core (RFC-3021)

Last modified on 1 Jun, 2022. Revision 6
This short guide goes through the scenario when we want to use a /31 network mask in cOS Core. Limitations and workaround.
Up to date for
cOS Core 14.00.04
Supported since
cOS Core 9.30.xx
Not valid for
cOS Core 8.xx
Status OK
Author
Peter Nilsson


Problem

Is it possible to configure cOS Core with a /31 network mask? We get an error when we try to add 192.168.1.175/31 to the address book, saying it’s invalid.

Description

It is possible but the correct (base) network address needs to be specified. If we look at the above IP example it looks like this if we use an IPv4 calculator on it:

Network:   192.168.1.174/31
Broadcast: 192.168.1.175
HostMin:   192.168.1.174
HostMax:   192.168.1.175

Just to clarify, 192.168.1.175/31 is by definition of RFC-1878/RFC-950 invalid. The reason for this is because the first address in a e.g. a /31 should be the starting number of the subnet. This varies of course depending on the size of the network, a /24 subnet mask for example the last number must be set to zero (may also vary between vendors/systems).

Note: On /31 network masks, no broadcast address is used. Both IP addresses will be treated as host addresses. The above calculator output does not reflect this.

Some systems accept e.g. 192.168.1.175/31 as valid because it automatically converts it to the correct network. When using e.g. an online IPv4 calculator it may also automatically convert 192.168.175/31 to the correct 192.168.1.174/31. Since cOS Core does not automatically convert it, it will instead report it as an error. This has both a advantage and a disadvantage, the advantage is that the administrator quickly will get feedback on an invalid network and the drawback is that the system could have handled this automatically.

But one question would be, how far should we go in modifying what a user types in? There may not be a correct answer to this question.

Limitation

There is a known limitation when using /31 networks and that appears when we are attempting to connect to the Firewall for remote management. It will not work and there will not be any log generated about it (Engineering report ID COP-21060)

Workaround

  1. Disable automatic route creation on the interface.
  2. Assign the IP you want to the interface but use a dummy network, e.g. 127.0.25.0/32
    1. Important: You can NOT set the /31 network on the interface as network as that could cause some traffic towards the assigned IP to not function as it should (incoming packets could vanish without any logs being generated). So very important to set a dummy network here.
  3. Create a manual route with the /31 network.

Question - What about the DHCP client in the Firewall?

What if an ISP hands out a /31 with e.g. 192.168.1.175/31?

Answer

At this time it is unconfirmed on how it would behave, there is a fairly good chance that the DHCP lease offer would be unable to update the cOS Core address book and it could generate a failure/error.



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
Automation of Lets Encrypt certificate updates
23 Jan, 2024 core howto certificate management letsencrypt
Changing the certificate used by cOS Core's SSL VPN client/server
25 Nov, 2022 core configuration sslvpn 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