Oracle Cloud Infrastructure (OCI) provides complimentary site-to-site IPSec VPNs to your OCI networks, called virtual cloud networks (VCNs). However, companies often have multiple remote users or don’t have a corporate network at all and require client-to-site connections to their VCNs. We recommend properly configuring DNS when connecting networks to allow proper resolution between all devices.
Plenty of documentation for configuring DNS between VCNs and other private networks exists, but in this blog, I walk through achieving DNS resolution with OpenVPN, a popular client-to-site VPN solution offered on the Oracle Cloud Marketplace.
VPN connections have the following main categories:
Site-to-site: Also known as a gateway-to-gateway, site-to-site is a connection between entire networks. It typically uses 1-to-1 configurations where both sides have a network behind them.
Client-to-site: Also known as remote access, client-to-site is a single user cconnection to a network. It usually uses N-to-1 configurations, with N clients connecting to one server. The client is typically a single laptop with no network behind it.
Many client-to-site VPN appliances are available, but this blog focuses on using OpenVPN. In OCI OpenVPN is a powerful and easy-to-use enterprise VPN with a simple and friendly licensing model based on active VPN connections. Best of all, the OpenVPN Access Server is free to install and use for two simultaneous VPN connections.
This blog doesn’t cover setting up OpenVPN, but for details, refer to links at the end of this blog. As a starting point for private DNS in OCI, I recommend reading this blog on common private DNS scenarios. It covers the following key definitions:
Private DNS zones: Contains DNS data only accessible from within a VCN, such as private IP addresses has similar capabilities to an internet DNS zone but provides responses only for clients that can reach the VCN
Private DNS resolver endpoints: Comes in two options. A listening endpoint allows the resolver to answer DNS queries from outside the VCN. A forwarding endpoint allows the resolver to query a remote DNS as defined by forwarding rules.
With the default option, “Do not alter clients’ DNS server settings,” internet traffic is not routed through the VPN and the access server doesn’t push DNS servers to the client. Consequentially, nothing on the DNS side changes. So, the default expected behavior has the following details:
Access VM’s private IP directly: Yes
Resolve public DNS: Yes
Resolve VCN’s private DNS: No
Changing the DNS settings to “Have clients use specific DNS servers” allows you to specify DNS servers for the VPN clients to use. With this ideal setting, you can now specify the DNS listener endpoint created for your zone as the primary DNS server and then a public DNS server as secondary. The expected behavior changes to the following options:
Access VM’s private IP directly: Yes
Resolve public DNS: Yes
Resolve VCN’s private DNS: Yes
In this example, 216.146.35.35 is one of Oracle’s public DNS servers, but any public DNS server can suffice.
You can resolve your OCI private zone while still being able to resolve public DNS!
Just as public DNS is essential for accessing public sites, private DNS is essential to access your company’s internal sites. Properly setting up DNS within your private network and any connected networks is important because it allows you to use human-readable names instead of IP addresses and makes adding and removing servers seamless. This blog provided one solution for configuring DNS for a client-to-site VPN using an OpenVPN access server running in your Oracle Cloud Infrastructure network.
If you want to try this lab for yourself, check out Oracle Cloud’s Free Tier with US$300 credits for a 30-day free trial. Free Tier also includes several “Always Free” services that are available for an unlimited time, even after your credits expire.
For more information, see the following resources:
Cody is a Cloud Architect for Oracle Cloud's Commercial accounts
Next Post