Unnumbered tunnels with legacy configuration and no VIP defined in SmartConsole

[zorolo]

Hi.

I have a cluster used by several site-to-site communities, route-based with VTI tunnels among them. Because VTIs need to use a Get Interfaces operation involving all interfaces in the cluster, not only the one to be created, I have two unnumbered tunnel interfaces appearing in the Network Management section. Those unnumbered VTIs were configured without using SmartConsole (R81 SMS) for cluster configuration, and had no VIP assigned (and both are working perfectly fine): they were just created by configuring the gateways (R80.30) to use the same physical interface as all the rest of VPN traffic as a proxy.

The interface has a /24 IP address, but when fetching the interfaces in SmartConsole, the system decides the unnumbered VTIs have a /32 instead. TAC advises not to delete the unnumbered interfaces from SmartConsole (which seems to have been what has been happening up until now whenever fetching interfaces was necessary to configure new numbered VTIs) and not to use the same IP address from the external interface (because of the different mask length).

TAC advises to use a loopback interfaces, which, aside being a bit of a hassle by itself, is not really an option for the previously configured interfaces.

Has anybody encountered a similar problem? Is TAC evaluation correct in that I have no other choice? It is true that getting rid of the unnumbered VTIs in SmartConsole will really be a problem, despite not being currently already there? Since I would really prefer to have them accounted for in SmartConsole, if not for any other reason to be able to configure Anti-Spoofing, how will the difference in mask length affect traffic, if I put the same address than the proxy interface's?  

[PhoneBoy]

VTIs are basically point-to-point interfaces, which means they'd have a /32 as the netmask.
You should be able to confirm this in ifconfig output.
As such, a "get interfaces" would get this netmask.

That said, I'm not entirely clear what the actual problem is and what you're trying to achieve. 
Are you just trying to get the interfaces represented in SmartConsole correctly?

[Angel_Parra]

I have to input a VIP for each interface. For both unnumbered vpnts, the proxy device is the same one. Let's say it is eth3 (all names and addresses are fictitious):

FW1 eth3: 100.1.1.1/24. FW2 eth3: 100.1.1.2/24.

That same interface is the one used to carry all VPN traffic. In the cluster object configuration, the VIP is 100.1.1.3/24:

VIP eth3: 100.1.1.3/24. FW1 eth3: 100.1.1.1/24. FW2 eth3: 100.1.1.2/24.

When fetching the interfaces, I get for those previously configured, already working, not-previously-appearing unnumbered VTIs members:

vpnt1 fw1: 100.1.1.1/32 vpnt1 fw2: 100.1.1.2/32

vpnt2 fw1: 100.1.1.1/32 vpnt2 fw2: 100.1.1.2/32

Apparently, as per the Check Point support case update, VIP for those interfaces should not be 100.1.1.3/32: "[c]onfiguring the VIP IP as [eth3] may cause traffic issues as the interface and the tunnel have different prefixes, for that we are able to configure the loopback interface as a proxy interface to the unnumbered VTI interface."

[zorolo]

The post by Angel_Parra contains the details. I had some trouble posting myself the first time around, but I got it sorted. I'll repeat the information here. I'm really sorry about the mess.

I have to input a VIP for each interface. For both unnumbered vpnts, the proxy device is the same one. Let's say it is eth3 (all names and addresses are fictitious):

FW1 eth3: 100.1.1.1/24. FW2 eth3: 100.1.1.2/24.

That same interface is the one used to carry all VPN traffic. In the cluster object configuration, the VIP is 100.1.1.3/24:

VIP eth3: 100.1.1.3/24. FW1 eth3: 100.1.1.1/24. FW2 eth3: 100.1.1.2/24.

When fetching the interfaces, I get for those previously configured, already working, not-previously-appearing unnumbered VTIs members:

vpnt1 fw1: 100.1.1.1/32 vpnt1 fw2: 100.1.1.2/32

vpnt2 fw1: 100.1.1.1/32 vpnt2 fw2: 100.1.1.2/32

Apparently, as per the Check Point support case update, VIP for those interfaces should not be 100.1.1.3/32: "[c]onfiguring the VIP IP as [eth3] may cause traffic issues as the interface and the tunnel have different prefixes, for that we are able to configure the loopback interface as a proxy interface to the unnumbered VTI interface."

[PhoneBoy]

Unless anyone has any specific experience otherwise, I would defer to the TAC's advice on this.

[Duane_Toler]

Did your unnumbered VPN tunnel interfaces work on the cluster without a VIP configured? Or were you required to use a loop1 interface in your CLISH configuration, and use that as the VIP?  

[zorolo]

The unnumbered interfaces are working without cluster configuration. An interesting thing I recently found checking log messages after a reboot is that it complained about not finding it, but would be using the proxy interface IP address (as intended).

[Duane_Toler]

Weird.  I setup a mini lab to test this.  Each gateway, in CLISH, has unnumbered interfaces (but I did choose "dev ethX" instead of "loopX").  In SmartConsole, I did "Get interface without topology" and it populated the vpnt1 interface as point-to-point (correct) but with IP of the "ethX" interface I chose in CLISH.  Plus, it demands me to configure a VIP for the vpnt1 interface (I can't close the interface list without doing so).

This is R80.40 HFA 158 everywhere (gateways and management).  I see yours is R81, tho, so... is this changed behavior?

I did get a successful VTI and IPsec session setup with an Libreswan gateway and its own VTI configuration (took some effort, but finally got it working).   I was able to ping across it, too.  Anyway, it works.  I did clusterXL_admin down on one gateway and watch the packets continue flowing.  Swapped active cluster members again, and the ping continues to flow.

The next question is:  what happens with multiple VTI interfaces on the same gateway, if they all get the same IP proxy interface?  Will that work, or do I need to have something else?  Loopback interfaces, then? 

[zorolo]

Having more than one VTI with the same physical proxy interface works fine (that is the scenario I described).

[CheckPointerXL]

Hello, 

In which setup Is suggested to use unnumbered vti?

[zorolo]

Sorry, I do not understand what you mean by setup.