ElasticXL and VIP not belonging on an interface

[Alex-]

One of our customers wants to move from ClusterXL to ElasticXL/VSNext and they have an ISP which only provides private addresses for interconnection, and routes the public range over them.

With ClusterXL, an easy, documented approach is to use static routes with local scope to the interfaces and define the VIP of the cluster to an IP in that scope.

I'm wondering if there's a supported approach with ElasticXL, or if we need a trick like assigning the public IP to the VIP and proxy arp the private next hop or something similar.

[Bob_Zimmerman]

Looks like VSNext supports it. Pretty sure vanilla ElasticXL would, too:

[Global] DallasticXL-s01-01:0> set static-route 10.20.30.0/24 nexthop gateway logical wrp0 on          
1_01:
success

1_02:
success

[Global] DallasticXL-s01-01:0> exit

[Expert@DallasticXL-s01-01:0]# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.1.1        0.0.0.0         UG        0 0          0 wrp0
10.0.1.0        0.0.0.0         255.255.255.0   U         0 0          0 wrp0
10.20.30.0      0.0.0.0         255.255.255.0   U         0 0          0 wrp0
172.16.100.0    0.0.0.0         255.255.255.0   U         0 0          0 bond2.100
172.16.101.0    0.0.0.0         255.255.255.0   U         0 0          0 bond2.101
172.16.102.0    0.0.0.0         255.255.255.0   U         0 0          0 bond2.102
172.16.103.0    0.0.0.0         255.255.255.0   U         0 0          0 bond2.103
172.16.104.0    0.0.0.0         255.255.255.0   U         0 0          0 bond2.104
192.0.2.0       0.0.0.0         255.255.255.0   U         0 0          0 Sync

With that config, if the firewall wants to send traffic to an address in 10.20.30/24, it will ARP for the destination out the interface wrp0. It's the same mechanism as off-net VIPs in ClusterXL, which is also how VSX handles VIPs on networks separate from the interfaces' real IPs (what people often call the "funny IPs").

Though if the ISP is routing the public range to you, you shouldn't need to do this. You just build NAT rules or route the IPs wherever you want internally, right?

[Alex-]

Yes, it worked with NAT. But to resolve interoperability with VPN S2S/C2S, we needed to switch from that approach to the local scope in order to have a VIP with the public IP to use for link selection and not just NAT rules.

If we can't do this like in ClusterXL, maybe creating a loopback interface would do.

[Bob_Zimmerman]

You could give the firewall the real public address you want it to have, add an interface route like above so it can ARP for its default gateway, and add an alias for the private address the ISP routes your traffic to:

[Global] DallasticXL-s01-01:0> add interface wrp0 alias 2.3.4.5/32
1_01:
success

1_02:
success

[Global] DallasticXL-s01-01:0> exit

[Expert@DallasticXL-s01-01:0]# g_ifconfig wrp0:1
1_01:
wrp0:1      Link encap:Ethernet  HWaddr 00:12:C1:10:00:FC  
            inet addr:2.3.4.5  Bcast:2.3.4.5  Mask:255.255.255.255
            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

1_02:
wrp0:1      Link encap:Ethernet  HWaddr 00:12:C1:20:00:FC  
            inet addr:2.3.4.5  Bcast:2.3.4.5  Mask:255.255.255.255
            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

Or a proxy ARP entry for the address the telco wants. Either way should work as long as they only want it as a gateway and don't actually expect it to terminate traffic with them.

[Alex-]

That seems a reasonable approach, thanks.

We have this going to be done in the next few days, I will update on how it went.

[Alex-]

Adding an alias on a VSNext interface works, the routing table shows the private network in its routing table but sending default traffic to their next hop on that private range didn't work. We couldn't check if the router saw the FW as it's externally managed.

So the leading interface was set to the private network like in the ClusterXL, we created a loopback interface with the public IP and its subnet mask, added it in the topology, set in in the properties of the VPN link selection and source interface for outgoing VPN traffic, general NAT and all worked afterwards.

A word of caution, "Get interfaces without topology" doesn't include the loopback, so after creating all the VSW covering the bonded VLAN's, we had to ensure to add it again and everything was functional.