In the previous two blogs, we have discussed about the VMware Cloud Foundation as a Service concepts and VDC networking in general and public networking. This blog will focus on IPsec VPNs with VCFaaS. The included VPN services offer site-to-site connectivity, which provide a fast and an easy way to connect a VDC to your on-premises networks, or other clouds.

Site-to-site VPN types

With VCFaaS, you can use either policy-based or route-based IPsec. While these two VPNs provide similar functionality, they behave somewhat differently - how the traffic is encrypted and routed.

• Policy-based VPNs are defined by a combination of network prefixes from local and remote networks to define how traffic is protected through IPsec tunnels, typically defined as rules. These rules define how the traffic is not just encrypted but also routed in the kernel. Typically policy based IPsec tunnels are handled before the routing decision, but this may differ from vendor to vendor. Policy based VPNs are also very static and they require manual configuration to accommodate network topology changes (e.g. routing related).
• Route-based VPN use any-to-any (wildcard) encryption and uses the system’s routing table to direct traffic to different IPsec tunnels. Route based VPNs are built on router platforms in a way where each IPsec tunnel is modeled as a network interface or virtual tunnel interface (VTI). As traffic is directed to the tunnels using routing tables, you can also use dynamic routing protocols with route-based IPsec VPNs. This capability is very welcome especially when IPsec is used as a backup connection.

VPN in Provider or Edge gateways?

In a VCFaaS VDC, both Edge and Provider Gateways support IPsec VPNs, as shown in the following diagram. So, this might make you wonder, which option to choose? Or are there any differences between these two? Or what is the best practice? 

As discussed in the previous blog with NAT rules, the similar characteristics apply for this. Having all FW rules, NATs and IPsec VPNs in Edge Gateway is simple. But if you use other IBM Cloud Services in IBM Cloud Interconnectivity services, it might be better to use VPNs in the Provider Gateway. While Edge Gateway provides support for both VPN types, Provider Gateway only supports route-based VPNs. Note that, this selection affects how you should then configure the NAT and FW rules (remember the traffic flows). Most firewall vendors and also most customers prefer route-based IPsec tunnels over policy-based as that is simpler to manage and topology changes only require a routing change, using either static or dynamic routing. Edge Gateway does not support dynamic routing (e.g. BGP), which might be needed if you used the VPN as a backup for the private interconnectivity (like MPLS though IBM Cloud Transit Gateway and Direct Links). And here comes the next decision point for route-based IPSec - Edge Gateways support only static routing and Provider Gateways support only dynamic routing with BGP. When it comes to design aspects, I think these should give you enough criteria to choose from. In the examples in this blog, I focus only on route based tunnels – mostly because many customers are asking this, and secondly there is a pretty good example how to configure policy based tunnels in IBM Cloud Docs.

VPN on Edge gateway

Let’s start with the IPsec VPNs on Edge gateways. In this option, you can use either policy-based or route-based IPsec, and the route-based IPsec uses static routes only. 

Configuring this option is pretty simple. Navigate to your Edge Gateway > Services > IPsec VPN. Then click NEW. First, you will be asked to provide general information and select the VPN type. We use type route-based here.

Then provide peer authentication information, where we use Pre-Shared-Key (PSK). The PSK must match on both sides, so use a secure method to tell this PSK to the other side.

Then provide endpoint information. Obtain a new local IP address from the menu option using your Public IP Space. You will be allocated a new floating IP from the Public IP Space, or you can pick an existing if you happen to have one. Provide a subnet for the VTI interface. In route based IPsec tunnels, the VTI is the logical interface for the tunnel and its IPs are used for routing (defining the next-hop for static routes). For this, we use a subnet 192.168.201.0/30 in this example, but you could use a link local IP, too. We configure the .1 to be the local IP of the VTI, and then .2 is the remote side. Note this example IP (192.168.201.2), as we will need it later.

Finish the configuration and check that all information is correct. For VPN tunnels, the most typical mistake is mismatching parameters. It could be IKE or ESP related parameters, so make sure these match. You can use the system-generated security profiles or create your own. Refer to VMware by Broadcom documentation for more details.

Once the tunnel is UP, you must configure static routes. Navigate to the Routing > Static Routes. Click NEW. Fill in the information, and here you would add the prefixes located at the on-premises side using the IP address of the other side of the VTI as the next-hop. If we assume that you would use 192.168.0.0/24 in VDC and you have 10.0.0.0/8 at on-premises. Following this example, you would use network 10.0.0.0/8 and 192.168.201.2 as the next hop for the route. Then the VPN on the other side would use a similar configuration, but vice versa. Destination would be 192.168.0.0/24 and 192.168.201.2 would be the next hop for the route.

VPN on Provider gateway

Let’s now take a look if we would configure the IPsec VPN at the Provider Gateway. Then the design would follow the pattern presented in the following diagram.

When configuring this, navigate to your Provider Gateway and select Services > IPsec VPN. Click AUTOCONFIGURE. But now…we got error. It complains about a missing IP Space. This is normal, as we are now missing a prerequisite. So, we have to create one first. 

To create an IP space, you must navigate to IP Spaces using tabs in the top row. Then click NEW, and a configuration menu pops up. First, give your IP Space a name, for example we have used Private for VPN in this example.

Then allow route advertisement, and click next. But wait…what does this mean? Using the tool tip: “Allow Route Advertisement if routed networks associated with this IP Space need to be advertised from the Edge Gateway to the Provider Gateway.” Remember that we are configuring the VPN in the Provider Gateway, and your networks are connected at the Edge Gateway. So the Provider Gateway must know how to reach the networks that belong to this IP Space, so you should allow this. But you can also do this on the VDC networks, and that is actually the default behavior in VCFaaS – all routed VDC networks are advertised to Provider Gateway anyway. If you got lost...never mind, the default settings will work pretty well for you anyway.

In the next step, define the Scope. Internal and External Scopes define the networks that are either local or remote. Why would this matter then? The option talks about NATs and whatnot…how are these actually used? You will see soon. But note, it is good to add the true networks here now, if you can. In our example, the network address allocation uses 10.0.0.0/8 at on-premises and 192.168.0.0/16 at this remote site.

There is some additional information asked about IP ranges and IP prefixes. These might be useful if you wanted to allocate IP addresses from the IP Spaces, but you can also ignore these for now. You can change them afterwards, if needed. Once you are done, click finish.

On your VDCs Provider Gateway, navigate to the Services > IPsec VPN. Click AUTOCONFIGURE again. Now you see that we got rid of the message, and we can continue. Add a name and allocate a new local endpoint from your Public IP Space. Then fill in the other details for the VPN, including the ASNs for BGP. You can choose any ASN you like, but do not use the pre-allocated ASN of the Provider Gateway as the local ASN. The AUTOCONFIGURE option will use this “local” ASN only in the BGP peer configuration, and therefore it wants some arbitary ASN here. Also note, that you cannot change this ASN afterwards – so select this ASN carefully which matches your own network design at on-premises (if you have to change it, you may have to start over). AUTOCONFIGURE will pre-allocate a subnet for the VTI interface and you can change this subnet here, if you want. In contrary to the previous example, the IPs in the VTI are used in the BGP peer configurations. Could you use static routes here – no, unfortunately not. This option only supports BGP. 

The configuration takes a few seconds to complete, and then depending on the other side, the VPN and BGP might take a bit longer to come up. So how to check this, and what did the autoconfigure actually do? The first thing to check, is the BGP > Overviewsection in the Provider Gateway configuration. You will see two BGP neighbors configured for the VPN tunnel with neighbor address 192.168.200.2 and remote ASN 65002. Note that I have a few other BGP peers, but just ignore these for now – we will discuss this in the next blog. One of VPN BGP peers should be established and the other shows most likely idle. This is normal. You can see from the Total IN/OUT Prefix Count columns how many networks do you currently receive or advertise to the BGP neighbor at the other side of the tunnel. If you see, that you advertise your network, then your VDC config should be good to go.

Now, let’s take a bit deeper look what else did the autoconfigure do. In the next tab called Neighbors, you see the BGP neighbor configurations. Notice that there are In and Out filters (Route Map) configured for the specific VPN BGP neighbor.

What is a route map? Route maps are used to control routing information and tune some routing protocol attributes or metrics for either advertised or learned routes with dynamic routing protocols, or when distributing routing information between routing protocols. They provide a more granular way to control advertised or learned routes than prefix lists, which only control what prefixes can be advertised or learned. In practice, these two are typically used together. So, let’s look at the route maps created for the VPN BGP peers in the tab called Route maps. One defines outgoing advertisements (-OUT) and the other incoming (-IN).

If you look at the match criteria for the route map, you will notice that it permits with IP prefix match using a prefix list. Then it depends on the prefix list, what prefixes will be handled (permitted or denied) on this row. And as there are no more rows, what happens to the other prefixes? There is an “explicit deny” at the end, so this means that only the prefixes allowed on this row will be advertised to the peer. Both route maps are configured in a similar way, they have one row and they use a prefix list, one uses VPN to On-Premises-IN / “-IN” and the other uses VPN to On-Premises-OUT / “-OUT”.

When we look at the prefix list VPN to On-Premises-IN, you see a definition here allowing any subnet belonging to 10.0.0.0/8 with any prefix length (prefix length less than 32). So, this would allow 10.0.0.0/8, 10.0.0.0/16, 10.0.1.0/24, 10.0.2.0/27 and so on.

Or if we look at the prefix list VPN to On-Premises-OUT, you see a definition here allowing any prefix/subnet belonging to 192.168.0.0/16 with any prefix length (prefix length less than 32). So this would allow 192.168.0.0/24, 192.168.1.0/25, 192.168.1.128/25 and so on.

Where do these come from? What did we specify in the Private IP Space…yes, we used 10.0.0.0/8 as the external scope defining the on-premises networks and 192.168.0.0/16 as the internal scope defining the local VDC networks. These route maps and prefix list will then allow any prefix to be learned from the remote VPN BGP peer or advertised to the VPN BGP peer, as long as the network belongs to the specific prefix list. Let’s think…you would configure a 172.16.0.0/24 on the VDC network, would this be advertised? Yes, you are right – It would not be as it does not belong to the Private IP Space and it is not configured in the VPN to On-Premises-OUT prefix list. Or…the on-premises VPN is trying to advertise 192.168.45.0/0 and 192.168.192.0/19, would that work? Same thing, the prefix list VPN to On-Premises-IN only allowed 10.0.0.0/8 with any prefix length. Does this make any sense? Could you directly modify the VPN prefix lists or the route map? Yes, you can. For example, if you used this VPN as a backup for on-premises connectivity, you might need to tune the as-path with as-prepends or you might want to use some other BGP attributes like local preference and MED. 

This might seem pretty complex, but it is simpler than you might think. Going back to the AUTOCONFIGURE feature, it creates you a pretty good baseline for the BGP configurations. With these route maps and prefix lists, you can control what you advertise and what you learn from the other peer. Then it depends how much you want to customize, if any. An important thing here is that configure the Private IP Space properly in the first place, and then you are most likely good to go. You could also keep it simple and use Edge Gateway with the policy or route based tunnels with static routes. All depends on your requirements and what do you want to achieve with the VPN. And this should be the starting point for your design, too. 

What's next?

I hope this blog helps you to choose the best options to configure VPNs for the IPSec interconnectivity needs, and I hope this opens the VPN possibilities offered with the VCFaaS platform. In the next blog, I will talk about private connectivity and why would use us that. And maybe we could talk more about debugging BGP, for example what you can do with the UI. How to see the routing tables and other BGP related information (like learned and advertised routes). Again, stay tuned...

#VMware
#Tech_Series_Using_VMware_Cloud_Foundation_as_a_Service
#IBMCloud