Solved with Aviatrix - Google Compute instances with DNS Forwarding Zones
Solved with Aviatrix
Google Compute instances with DNS Forwarding Zones
Aviatrix is the leading vendor of Secure Multicloud Networking.
From the website: The Aviatrix cloud network platform delivers a single, common platform for multi-cloud networking, regardless of public cloud providers used. Aviatrix delivers the simplicity and automation enterprises expect in the cloud with the operational visibility and control they require.
Environment and DNS Structure
In the interest of simplicity, the customer has a single region Aviatrix-based deployment in GCP, using Firewall Insertion. They connect to their datacenter using Cloud Interconnect and Aviatrix Edge. They also have Apigee-X, deployed using a single region version of this article.
DNS is deployed on the same servers as the Active Directory Domain Controller role. The DCs/DNS Servers are on-prem at this time. GCP Domain Controllers will eventually be deployed as well.
So what's the problem?
When VM instances are deployed in Public Cloud, it is almost universal that the VMs configure their NICs with DHCP. In AWS and Azure, it is easy to change the configured DNS servers supplied by DHCP.
GCP doesn't have the same ability, as far as I can find. The expectation is that Cloud DNS Forward Zones are created and used to forward to other DNS Servers.
Note: It is also possible, as in the on-prem days, to statically assign DNS Servers within the VM. This is an extra step and is not desirable from a management or operations standpoint.
Why is using a Forwarding Zone an issue? Routing.
A Forwarding Zone is a Cloud DNS Zone that forwards all queries for a domain to an external DNS Server.
As the red box says, the traffic is sourced from 35.199.192.0/19 and from the VPC Network(s) its attached. The specific VPC Network is based on the VM originating the query.
Consider the customer diagram at the top. The 35.199.192.0/19 prefix needs to be reachable from on-prem in all of these spokes. The traffic is stateful and has to arrive back at the originating VPC. How does the routing work? With no changes, it doesn't.
If asymmetric routing isn't scary enough, this prefix is blackholed by the GCP fabric if used with an intermediate hop, such as NGFW or Router Appliance. I couldn't even find the packets in the flow logs!
Solutions
There are a few different solutions to this problem.
The Right Way: From a design and redundancy standpoint, it is best to deploy a pair of Domain Controllers (or your preferred DNS poison) per GCP region. Use the Forwarding Zone to point to the in-VPC DCs. Use DNS Peering Zones to point the other VPCs to the Forwarding Zone.
The DNS Peering Zone works cross project and is transitive. I was able to chain Peering Zone -> Peering Zone -> Forward Zone. This is useful when dealing with Private Services Access/VPC Peering scenarios, such as with Apigee-X or MongoDB.
My customer will get to that point, but they're still building out their POC/Dev environment. Domain Controllers are only allowed in the Prod Environment.
Alternative solution needed: For the POC environment they are building, the DNS Resolvers in 35.199.192.0/19 need to reach the Domain Controllers in the datacenter. The customer has Aviatrix Multicloud Networking already deployed. How do we work around this scenario without introducing Domain Controllers or custom DNS Proxy servers into the POC environment?
Aviatrix Spoke and standalone Gateways are both capable of SNAT and DNAT. With the issue being asymmetric routing, SNAT is the trick needed.
Implement the alternative solution
Its entirely possible to implement this solution on just one set of Spokes or Standalone, then use a DNS Peering Zone to spread around the resolution. For the sake of the article, I'll describe both options.
Create the DNS Forwarding Zone per the instructions. Specify the Destination DNS Servers exactly as they are in the datacenter environment. Attach the Zone to the VPC(s) you want to use.
This step is required regardless of the method chosen.
Make sure to check Private Forwarding or the queries won't hit the VPC.
Spoke method
Add a new Firewall rule to allow traffic from 35.199.192.0/19. A rule must be created for each Spoke VPC where the DNS Forward Zone is attached.
Configure NAT Rules on the Aviatrix Spoke Gateway. In the Aviatrix Controller, go to Gateway.
Highlight spoke-1 and click Edit.
Collect the Private IP of the Gateway by expanding Gateway Detail.
Scroll down to Source NAT.
Specify as above. The important fields are:
- Customized SNAT
- Sync to HA GW: Unchecked
- Src cidr: 35.199.192.0/19 (GCP DNS Prefix)
- Dst cidr: Prefix or IP of the DNS Server or 0.0.0.0/0
- Protocol: All
- Interface: eth0 or blank.
- Connection: Transit attachment, usually the name of the Transit Gateway
- SNAT IPs: Private IP of the Gateway
- Apply Route Entry: Unchecked
Once the rule is entered, click Save then Update.
Edit the HAGW and create the same rule, changing the Private IP to match the HAGW.
Completion: DNS queries to your internal AD DNS zones will now be correctly resolved.
Standalone Gateway Method
This design is an option in a scenario like Apigee-X where Spoke Gateways are not in use.
Create a new subnet in the Apigee-X Ingress subnet. A /28 is sufficient.
Click Create New.
Fill out as above. Note that the Subnet is the new one I had just created.
Under Gateway for High Availability Peering, check that the subnet is correct. Pick another Zone, then click create.
We can see the HAGW in the view now.
Configure the NAT rules on the new Gateways. Edit the primary NAT gateway again. Collect the Private IP of the Gateway by expanding Gateway Detail.
Specify as above. The important fields are:
- Customized SNAT
- Sync to HA GW: Unchecked
- Src cidr: 35.199.192.0/19 (GCP DNS Prefix)
- Dst cidr: Prefix containing the DNS Server or just 0.0.0.0/0
- Protocol: All
- Interface: eth0
- Connection: blank
- SNAT IPs: Private IP of the Gateway
- Apply Route Entry: Unchecked
Once the rule is entered, click Save then Update.
Edit the HAGW and create the same rule, changing the Private IP to match the HAGW.
Create a Firewall Rule to allow the GCP DNS Resolver prefix to the VPC with the Standalone Gateways.
Create Routes to Forward DNS traffic. To put the Gateways in the path, we need to create 4 routing rules per server or DNS Server prefix. The 4 routes share the same destination, the server or prefix.
FYI: When creating these routes, remember that all VPC traffic to these IP ranges will be sent through the Aviatrix Gateways. This traffic won't be NAT'd. Consider any other traffic. The Apigee-X example isn't impacted as we're strictly concerned with DNS queries.
All routes are defined in the Apigee ingress VPC.
To Primary NAT GW and HA NAT GW, untagged.
Explanation: The DNS Resolver traffic needs to be sent to the Gateways to be NAT'd. There's no way to tag routes to be used only by the DNS Resolver, so this route applies to all. Consider how specific to make them.
To Primary and HA Transit, tagged for the NAT gateways.
Explanation: After being NAT'd, the DNS resolver traffic needs to be sent on to the Aviatrix Transit. The extra routes, tagged to the Gateways, are required. If they were not present, the Gateways would use the first set of routes, causing a routing loop.
Completion: VMs in the VPC can now resolve internal DNS entries properly.
Next Steps
- Create DNS Peering Zones
Comments
Post a Comment