/31 interfaces

[Ben_Dunkley]

Hi all,

Are there any known issues with using interfaces with /31 IPv4 subnets on Gaia?

Or things to be aware of or careful with?

(On a single gateway, not clustered - I'm assuming clustering would bring in sk32073 related shenanigans).

(Fairly short question!)

Regards,

Ben

[Wolfgang]

Hi Ben,

it‘s more a question of how IP subnetting works.

mask /31 means you have one address as the network address and another one as broadcast address. There are no IPs available for hosts in this small subnet. Better solution will be /30 mask, two host IPs available, one for your gateway another one for the router.

Wolfgang

[Bob_Zimmerman]

/31 network masks are explicitly allowed in IPv4. See RFC 3021, though their use predates that document by several years.

[Magnus-Holmberg]

/31 is very common at service providers for p2p links.

[Bob_Zimmerman]

I know VSX won't let you provision an interface with a /31 mask. I've brought this up as a bug, but I think you and I are probably the only people trying to use network blocks that small. 😉

Somewhat related, VSX actually works like sk32073 describes internally. The members get off-net IP addresses.

[RKinsp]

Hi Bob, did you ever get a response on this "bug"? We are also trying to use /31 in a VSX environment, seems R81 won't let it either. Thanks!

[Bob_Zimmerman]

I didn't, no. It wouldn't have been ready in the time I had, so I had to redesign the environment where I was trying to do it.

Based on sk91020, I think it would now be a bug rather than an RFE.

[HeikoAnkenbrand]

Hi @Ben_Dunkley,

Why do you want to use a 31 network mask?

This is a basic discussion and @Wolfgang  has already answered it correctly. I would not build in any problem cases, if there is another good solution.

BFS

- Use a 30 network mask with GAIA

- In the rules set you can use a 31 mask

[Bob_Zimmerman]

The answer is pretty simple. We want to use them because the IPv4 specification supports them, and they're useful for point-to-point links (for example, a cable connected directly to a router's interface).

They would also work for directly-cabled sync interfaces on clusters. While running a cable directly from cluster member to cluster member for sync is a terrible idea, a lot of people do it. This would let them do it with two addresses instead of four.

[Chris_Atkinson]

To be fair I don't think the sync interface is a good example of such a requirement.

/31 are also about address conservation, hence most relevant to unique public network address space.

[Maarten_Sjouw]

They have been supported on Cisco routers for a long time now and I was really happy to see in R80.30 at least GAIA allows you to use it.
Have not checked on the SmartConsole front, but as @Bob_Zimmerman says, the IP space for point to point connections for ISP's has been an issue for a long time. Wasting about 50% of the IP's with /30 on these connections where only 2 devices are in.

[PhoneBoy · Accepted solution]

It wasn't possible in Gaia versions prior to R80.
It should be now, per: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
And no, I'm not aware of any specific issues doing so.

[Ben_Dunkley]

Aha! Perfect - that's exactly what I was looking for, and my sk searching hadn't managed to turn that one up. (I'm assuming the search is interpreting the slash in a funny fashion).

Thanks!

[Wolfgang]

Really interesting to hear there are use cases for this.

I'm not aware of this requirements for small subnets, but for providers it makes sense.

Wolfgang

[Ben_Dunkley]

Regarding the use case, in this instance it is the IP addressing that a service provider has assigned for a connection.

So if it was going to be a problem, the earlier that it gets kicked back to the provider the better.

(Perhaps unsurprising given IPv4 address space shortages).

As other folk had mentioned in the thread, I'm familiar with /31 masks in Cisco environments (RFC3021 is almost twenty years old now, so it's not exactly a new concept), but just hadn't encountered them in connection with Checkpoint before.

[Bob_Zimmerman]

A provider could just give you a 32-bit mask and a private IP to route everything through.

Let's say the provider has a router with ge-0/1/2 set to the IP 10.20.30.40. They give you the IP 2.3.4.5.

They tell their router 2.3.4.5 is local on ge-0/1/2, so it ARPs for the IP out that interface. You tell your firewall 10.20.30.40 is out eth0, and you set your default route as 10.20.30.40, so your firewall ARPs out the proper interface and uses that MAC address for everything it sends upstream. Done.

I have a similar setup running in production to meet some truly awful requirements. It's weird, but it works, and it means the provider side doesn't need to consume any public IPs for the last-mile connections to customers.

[Duane_Toler]

So how about this idea, taking it one step further.. 

ClusterXL with cluster members on private underlay and VIP on public /31 subnet? (Members addresses and VIP on different subnets), and site-to-site IPSec VPNs to the VIP (IKEv1 and IKEv2).  R80.20 JHF 202. No VPN clients, tho.

[Duane_Toler]

Ok.  I configured this in the home lab.  ClusterXL with VIP on different subnet; the physical interfaces were an arbitrary subnet and I configured the VIP with a /31.  As documented in sk32073 I had to do the static route for the VIP's subnet (the /31 and real functional subnet) with the "scopelocal" option.

I applied Jumbo HFA 202 to address sk173048 with IKEv2.  I had to configure IPsec VPN - Link Selection with:

* Always use:  Main Address

* Outgoing Route Selection - When Initiating: use Operating System routing table

  - [Setup] button for Responding Traffic: Reply from same interface

* [Source IP address settings] button: Manual - IP of chosen interface

That last one was the magic key.

In my topology, I have 2 external interfaces as I need for this scenario; no ISP redundancy for this.  In CLISH, I can set static-routes for my VPN peer out whichever external interface I want to use.  I used StrongSwan (or is it Libreswan now? meh...) and configured IKEv2 for AES-256 SHA-384 DH 20 (I couldn't get exactly VPN-Suite-B happy with the Swan; annoying but whatever, that wasn't the point anyway).  I used my own Linux home router VM as the next-hop between all this, just so I'm using IPsec tunnel mode and not transport mode. 

IPsec connection comes up, packets (finally!) flow between them.  In CLISH, for the static-route, just use the typical next-hop address as you normally would.  No need for 'scopelocal' on those routes like you did for the VIP subnet on different interface.  Since the VIP here is an external interface, I didn't have to deal with the anti-spoofing and special grouping (per the SK and ClusterXL Admin guide).  I later tested with both IKEv1 and IKEv2 (separately, of course).

Not that it matters, but this was just a pair of ClusterXL HA gateways and not VSX, but I did manage them from an MDS management domain, since I had it already available.  I'm not doing anything SmartCenter couldn't do (I know, duh, but just stating the test environment).

Wow... complex, almost circular, but it works!  I was hoping it would, but I half-expected it to be buggy and fail.  You MUST use JHF 202 tho!  Anything else absolutely is guaranteed to fail.  I opened an SR about the IKEv2 SK above and they confirmed the hotfix was in JHF 202 (and now you notice that SK was updated "30-Jul-2021" which is the day I opened the SR 🙂 haha; thanks folks!).  The SK now states "R80.20 JHF 202"; it didn't say that before 30-Jul tho.

So there ya have it folks... /31 subnet on ClusterXL with VIP on different subnet!

[the_rock]

Wolfgang gave you really good answer.../30 is probably way more advisable in this case. Yes, you can use /31, but maybe not the best idea.

[Michael_Menen]

Hi all,

trying to configure /31 on external Interface will cause Remote Access to stop.

Site-2-Site-VPN is still working without any issue.

When using /31 on external Interface access via Web to public IP is no longer possible and Check Point Remote Secure Client cannot establish connection to Check Point.

On the Clish you can see incomming traffic on port 443 (tcpdump) but Gateway is not responding.

Quite sure that using a /31 is possible on internal network but on the external one not.