Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Ben_Dunkley
Contributor

/31 interfaces

Jump to solution

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

0 Kudos
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin

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.

View solution in original post

18 Replies
Wolfgang
Leader
Leader

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
Advisor

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

Magnus-Holmberg
Advisor
/31 is very common at service providers for p2p links.
https://www.youtube.com/c/MagnusHolmberg-NetSec
0 Kudos
Bob_Zimmerman
Advisor

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.

0 Kudos
RKinsp
Contributor

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!

0 Kudos
Bob_Zimmerman
Advisor

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.

0 Kudos
HeikoAnkenbrand
Champion
Champion

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

 

0 Kudos
Bob_Zimmerman
Advisor

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
Employee
Employee

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.

0 Kudos
Maarten_Sjouw
Champion
Champion
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.
Regards, Maarten
0 Kudos
PhoneBoy
Admin
Admin

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.

View solution in original post

Ben_Dunkley
Contributor

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!

0 Kudos
Wolfgang
Leader
Leader

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

0 Kudos
Ben_Dunkley
Contributor

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.

0 Kudos
Bob_Zimmerman
Advisor

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.

0 Kudos
Duane_Toler
Collaborator

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.

0 Kudos
Duane_Toler
Collaborator

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!

 

0 Kudos
the_rock
Mentor
Mentor

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.

0 Kudos