topic Re: VPN redundancy (site-to-site) in Firewall and Security Management

VPN redundancy (site-to-site)

Heather_Lewis — Wed, 26 Oct 2022 21:58:25 GMT

For an environment with two geographically diverse hub sites with in excess of 50 internal VPNs, do you prefer MEP or VTI with dynamic routing?

Re: VPN redundancy (site-to-site)

PhoneBoy — Fri, 28 Oct 2022 22:35:29 GMT

VTI will likely be required if any of the VPN endpoints aren't Check Point devices.
Otherwise, it's likely a horses for courses argument as to which one is better.

Re: VPN redundancy (site-to-site)

Heather_Lewis — Fri, 28 Oct 2022 23:39:41 GMT

Thanks. Have you seen a vti deployment at hub sites for more than 50 branches? All are internally managed Check Point. Multi-point VTI is not supported, is that right?

Re: VPN redundancy (site-to-site)

Duane_Toler — Mon, 31 Oct 2022 16:35:44 GMT

Correct, no multipoint. However, you can do unnumbered VTIs and with BGP routing.

Topology:

# eth0 = external, internet

# eth1 = internal, interior network

# remote peer's eth1 interior interface is 192.168.100.1

# this local gateway's eth1 interior interface is 192.168.200.1

1. Create an unnumbered VTI:

add vpn tunnel 100 type unnumbered peer remote_peer dev eth1 #eth1 of local gateway for proxy interface

# (repeat for other peers; Ansible and/or Gaia API run-script can be your frie

2. Add static route to remote BGP peer across VTI

set static-route 192.168.100.1/32 nexthop gateway logical vpt100 on # VTIs are point-to-point after all

3. Configure eBGP with multihop

set bgp external-as 65001 on

set bgp external-as 65001 peer 192.168.100.1 on

set bgp external-as 65001 peer 192.168.100.1 multihop on #multihop for eBGP since VTI route is a second hop to the interior

4. Verify

show bgp peers

# 192.168.100.1 will become Established

You can add BFD as well with "set bgp external-as 65001 peer 192.168.100.1 ip-reachability-detection on"

I've done this a few times myself. This is also documented in sk138192. The SK is good, but it requires very careful reading. 🙂 It's a lot of (really good) info!

Re: VPN redundancy (site-to-site)

Greg_Harewood — Mon, 07 Nov 2022 22:11:46 GMT

What's multipoint vti?

Re: VPN redundancy (site-to-site)

Greg_Harewood — Mon, 07 Nov 2022 22:16:36 GMT

I have an opinion on this in concept. VTIs can become surprisingly hard to manage. They always ought to be more functional. But CP make MEP communities so EASY that you'd better have something you expect to gain from VTIs to offset the pain. THere is a lot you CAN gain.... all that routing integration with other links, other vendors, local networks... more future proof in some ways. But SO much extra work if you don't need it.

Re: VPN redundancy (site-to-site)

Duane_Toler — Tue, 08 Nov 2022 14:18:25 GMT

As you noted, this is for route advertisements between sites, (including support with 3rd party devices now that everyone does VTI and IKEv2 with Universal Traffic Selectors). You can use unnumbered VTIs and proxy off an internal interface (or loopback) and avoid subnet allocation management. You could also use the 169.254.1.0/24 subnet if you needed a numbered VTI (this is what Amazon AWS uses).

As for the "work", once you get the first one done, especially for unnumbered VTIs, you can either add more with Ansible or your own API script. It's largely a one-and-done, copy/paste/paste/paste, implementation. Routing policies with BGP route-maps gives you extensive control of traffic engineering. Lots of good reasons. 😀