In the previous blog, we discussed about the generic concepts and components of the IBM Cloud for VMware Cloud Foundation as a Service (VCFaaS)  and we had an overview of network topology of the Virtual Data Center (VDC). In this blog, we focus on public networking and related key use cases. For example, how to access Internet from your VDC networks or how to access your workloads from the Internet? Using the network terminology, we talk about network address translation (NAT) services and Gateway Firewall features available in Provider and Edge Gateways. 

Public connectivity

The following diagram depicts a conceptual topology of your VDC, how the access to the IBM Cloud Services is established and the VDC uses the optional IBM Cloud Interconnectivity services (Transit Gateway and Direct Link).

Though you might not use or need IBM Cloud Interconnectivity Services (like Transit Gateway or Direct Link) in your solution, it is useful to think “what if” you had these embedded into your solution. You may not need or use them now, but you might in the future. Keep this in your mind for a sec, I will come back to this and why this is important at this point. 

I always recommend that one of the very first things you should do is to create a design of your solution. Draw a diagram with your own style and try to keep it up to date with the changes you might have in the future. Draw how many VDC networks would you have and add the key IP addressing information and other relevant and related information to it. Too often, people just start provisioning and then they get an issue, and they might need help to troubleshoot. In the worst case you might end up into a configuration error causing your workload to become vulnerable to rogue access from the Internet. It is so much easier to discuss about your solution with others when you have a design/diagram which explains what you want to achieve. In addition, a good design will help you when configuring the Edge and Provider Gateways. Once you have a design for the network segmentation, think about the traffic flows for your applications. Actually, you should think about this when you design your network segmentation. Anyway, understanding the traffic flows is very important when designing network security for your solution, as the flows define how the firewall and NAT rules should be configured.

Network address translation (NAT)

As discussed on the previous blog, inside the VDC you can do firewalling and NATing in two places. You can configure these either on the Edge Gateway or at the Provider Gateway, or even on both if you decided so. When you initially provision a VDC, there are a few default firewall and NAT rules are preconfigured on the Edge and the Provider Gateways. For example, the Provider Gateway has a default firewall rule to allow any traffic while Edge Gateway blocks any other traffic than the access to IBM Cloud Services networks. The Provider Gateway also includes two source NAT (SNAT) rules to access IBM Cloud Services networks (161.26.0.0/26 and 166.9.0.0/16). These default rules will allow you to access IBM Cloud DNS and NTP servers, private RedHat repositories or Debian APT Mirrors etc., and pretty much everything else is blocked. So, whatever connectivity your workloads need, you must allow this traffic by yourself.

Let’s now imagine you would have two VDC networks - 192.168.222.0/24 and 192.168.223.0/24. You would first like to access Internet from both networks, for example your would like to clone a Git repo or download software from a vendor site. As shown in the following diagram, the traffic flows through the following path: 

VM > VDC Network (NSX Segment) > Edge Gateway > Provider Gateway > Internet

If you create Edge Gateway SNAT rules for the two subnets 192.168.222.0/24 and 192.168.223.0/24 using destination “any”, what happens to all source IPs? Note that the Provider Gateway is “at an intersection” –  one “leg” goes to the Internet, another “leg” goes to IBM Cloud Services networks and another “leg“ goes to the optional Transit Gateway connection. If you would have private networks that you wanted to reach via Transit Gateway located in IBM Cloud VPCs, Power Virtual Servers or on-premises via Direct Links, you likely want to keep the original source IP of the VM, right? So, the outcome for doing source NATing at Edge Gateway may become a bit problematic, if not in the beginning but later. Edge Gateways do support NO_SNAT rules, which tell the Edge Gateway NOT to do SNATting for traffic matching the specific NO_SNAT rule. These NO_SNAT rules will help you to overcome these issues, but if you have many networks to be behind a Transit Gateway in VPCs or on-premises, this will become a bit difficult to manage.

A better option is to think where to do NATing. As mentioned before, also the Provider Gateway supports NATing. So, what would happen if you moved the rule from the Edge Gateway to the Provider Gateway? Then the Edge Gateway routes the packets to the Provider Gateway as is. Then Provider Gateway would do SNAT, but only when it is sending traffic to the Internet. But wait…don’t we get the same issue there, don’t we have to specify the NO_SNAT rules again? The key difference here is that the rule is applied to the Public IP Space (i.e. to the Provider Gateway interfaces used to access Internet). In this case, NATting would be done only for the traffic routed to the Public Internet. If the traffic would have to go to the other private networks though the Transit Gateway connection or to IBM Cloud Services networks, the configured NAT rule would not be applied and it is routed as is. Would this simplify the NAT operations? I think it would, and this is the best practice for NAT rules, too. An example provider gateway NAT rule configuration is shown for the previous example. 

First, figure out the Provider Gateway for your VDC. Open your VDC's Edge Gateway, and see Configuration > General. 

Then open the Provider Gateway tab and select your VDCs Provider Gateway.

Next, configure the NAT rules in Provider Gateway. Here we want to allow egress Internet access from both networks.

You can get the public IPs during the rule configuration tab, and or you can pre-allocate the IPs from the IP Spaces. If you have multiple VDCs, note the VRF group and number of your Provider GW (e.g. LON04-VRFGRPMS05-vrf10-GW), and find a matching IP Space with the name (MS05-V10-pub).

You can request more floating IPs from the /29 public subnet allocated for your instance using this page, too.

Gateway firewall

And now, would the traffic flow when you did the NAT rules as mentioned here? No, it should not because of…yes, you are right – we are missing firewall rules. Remember Edge Gateway has a default deny any policy in place.

To allow this traffic, you would have to create a firewall rule in the Edge Gateway to allow this. You can use IP addresses on the firewall rules, but here we create a Static Group of the specific VDC networks.

Then we create the rule to allow egress traffic to the Internet using the Local Networks Static Group as the source. You could also use IP Sets, or directly IP addresses on the rules. Using Static Groups or IP Sets in the firewall rules is handy (as in any other firewalls). You may have many firewall rules, and when updating the logical groups or sets updates all rules to use the correct IP addresses, instead of updating each rule individually. The example also shows another rule Allow Private, which allows any RFC1918 traffic to pass the firewall. Your needs are always unique, so design your firewall rules accordingly.

DNAT rules are configured in a similar way. Recall the design aspects discussed earlier – where do you want to do DNAT? It is usually better to NAT on one place to keep the traffic flows and rules as simple as possible, and not to create a scenario where the NAT or FW rules would “fight” amongst themselves. But other options are 

More advanced options are also available for both NAT and FW rules, such as priorities or rule ordering. For more information, see Broadcom documentation for VMware Cloud Director 10.6.

What's next?

I hope this blog gave you something to think about for your deployments. In the next blog, we will discuss about how to use your VDC capabilities to connect to on-premises or other clouds using site-to-site IPsec VPNs. Route based or policy based, both options are available. Stay tuned…

#VMware
#Tech_Series_Using_VMware_Cloud_Foundation_as_a_Service
#IBMCloud