• EN
Solved

Best Practice for DNS configuration for Veeam Cloud Connect

HangTen416
Userlevel 7
Badge +10

I want to revisit a discussion I’ve had before about the best DNS configuration for Veeam Cloud Connect.

What is common is that there is a common DNS name given to the customers for which multiple A records are created. This provides the round robin load balancing for the cloud gateways.

I’ve heard two ways of creating the DNS records for the gateways.

  1. A records for each gateway
  2. CNAME pointing back to the common DNS name

I know I had seen some documentation supporting the CNAME option before but I can’t seem to find it now.

I’m asking this in context of pushing out VSPC Agents. I’m not sure I fully understand how the Agents communicates back to the VSPC and connects the Agent Backups or VBR to the service provider. I am seeing in some instances that it adds a service provider to the VBR but using one of the gateway DNS entries and not the common DNS entry.

icon

Best answer by MicoolPaul 4 May 2023, 20:22

View original
VMCE2024 | VMCA2022 | Veeam Legend

20 comments

MicoolPaul
Userlevel 7
Badge +20

https://vccbook.io/3.Backups/3.4-cloud_gateways.html
 

the end bit has the CNAME part you’re referencing 🙂

 

Ive been out the MSP game for coming up 18 months now but IIRC it doesn’t matter what name is resolved as once it connects to VCC it’ll get all the gateways from the pool.

 

A CNAME record just redirects to an A record anyway so what you’re saying makes sense but I’m not familiar with VSPC anymore to comment further

Michael Paul - #VeeamLegend | #VeeamVanguard | Veeam Certified Architect | VMware vExpert | https://micoolpaul.com | Twitter: @MicoolPaul | Mastodon: @micoolpaul@masto.nu | Bluesky: @micoolpaul.bsky.social
Chris.Childerhose
Userlevel 7
Badge +20

When I spoke to Chris Arceneaux, he told me this for the A record setup -

 

GW1 = external IP

GW2 = external IP

GW3 = external IP

 

Primary URL - points to GW1 external IP

Primary URL - points to GW2 external IP

Primary URL - points to GW3 external IP

 

This then does the Round Robin using DNS.

Chris Childerhose - VMCA2022 | VMCE2023 | Veeam Vanguard 7* | Veeam Legend 3* | vExpert 5* | VCAP-DCV/VCP-DCV | Object First Ace | Cisco Champion | Twitter: @cchilderhose | Blog Site – https://just-virtualization.tech
HangTen416
Userlevel 7
Badge +10

@Chris.Childerhose ,

I thought he had mentioned using CNAMES like this:

GW1 = CNAME for Primary URL (eg. vgw1.domain.com points to vcc.domain.com)

GW2 = CNAME for Primary URL (eg. vgw2.domain.com points to vcc.domain.com)

GW3 = CNAME for Primary URL (eg. vgw3.domain.com points to vcc.domain.com)

 

Primary URL (vcc.domain.com) - Three separate A name records pointing to each of the external IPs for round robin.

 

Am I remembering this correctly?

VMCE2024 | VMCA2022 | Veeam Legend
HangTen416
Userlevel 7
Badge +10

I have some more context for this. I am working with a customer who is deploying VSPC and when an VSPC management agent is deployed to a backup and replication server both the agent and the service provider part of the backup infrastructure are automatically populated with the DNS name of one of the gateways which is a single point of failure. It should really be using the common/primary DNS name for full round robin redundancy, IMHO. Configuring DNS as above with CNAMEs would be a workaround for this issue.

VMCE2024 | VMCA2022 | Veeam Legend
Chris.Childerhose
Userlevel 7
Badge +20

I have noted what I posted above and this is the diagram which no CNAME is mentioned he gave me.

 

Chris Childerhose - VMCA2022 | VMCE2023 | Veeam Vanguard 7* | Veeam Legend 3* | vExpert 5* | VCAP-DCV/VCP-DCV | Object First Ace | Cisco Champion | Twitter: @cchilderhose | Blog Site – https://just-virtualization.tech
MicoolPaul
Userlevel 7
Badge +20

@Chris.Childerhose,

I thought he had mentioned using CNAMES like this:

GW1 = CNAME for Primary URL (eg. vgw1.domain.com points to vcc.domain.com)

GW2 = CNAME for Primary URL (eg. vgw2.domain.com points to vcc.domain.com)

GW3 = CNAME for Primary URL (eg. vgw3.domain.com points to vcc.domain.com)

 

Primary URL (vcc.domain.com) - Three separate A name records pointing to each of the external IPs for round robin.

 

Am I remembering this correctly?

This wouldn’t make sense because Veeam can’t load balance as it would give a gateway and then DNS could redirect it elsewhere.

 

Veeam Cloud Connect documentation also states: 

 

Configurations with one DNS record for multiple IP addresses are not supported.

The SP can use one public DNS name for their Veeam Cloud Connect infrastructure and provide the tenant with this DNS name instead of DNS names of cloud gateways. In this case, the SP must create DNSrecords for both public Veeam Cloud Connect DNSname and DNS names of cloud gateways. For example:

provider.tech.com "A" record to 198.51.100.1
provider.tech.com "A" record to 198.51.100.2
gateway01.tech.com "A" record to 198.51.100.1
gateway02.tech.com "A" record to 198.51.100.2
Michael Paul - #VeeamLegend | #VeeamVanguard | Veeam Certified Architect | VMware vExpert | https://micoolpaul.com | Twitter: @MicoolPaul | Mastodon: @micoolpaul@masto.nu | Bluesky: @micoolpaul.bsky.social
MicoolPaul
Userlevel 7
Badge +20

Was struggling to find the other part I wanted to add but I’ve got it: https://vccbook.io/3.Backups/3.5-cloud-gateway-pools.html

 

When initiating a connection, a client resolves the record cc.virtualtothecore.com and it can receive any of the possible records from the DNS server thanks to round robin. As long as at least one gateway is available, the connection is successful. Once the connection is established, Cloud Connect server sends to the tenant the entire list of all the available gateways, listed with both their DNS name and IP address, and also tells the tenant to which Gateway it should connect, which is usually the one with the lowest amount of active connections. This design works perfectly over public internet, but it may lead to some connection issues in other scenarios; this can be solved thanks to Cloud Gateway Pools.

—-

 

This is why you create a round Robin DNS to give a customer for initial connection, then VCC instructs to which cloud gateway endpoint the tenant should connect, by giving the individual DNS Records and IP addresses of the Cloud Gateways

Michael Paul - #VeeamLegend | #VeeamVanguard | Veeam Certified Architect | VMware vExpert | https://micoolpaul.com | Twitter: @MicoolPaul | Mastodon: @micoolpaul@masto.nu | Bluesky: @micoolpaul.bsky.social
dloseke
Userlevel 7
Badge +6

This is good to know.  Since I only have one Gateway, I guess vspc.domain.com and vcc.domain.com pointing to the same server (Gateway and console are the same server) but I had planned on if we grew to needing additional gateways I'd add as needed. 

Derek M. Loseke, Senior Systems Engineer | Veeam Legend 2022-2023 | VMSP/VMTSP | VCP6-DCV | VSP/VTSP | CCNA | https://technotesanddadjokes.com | @dloseke
MicoolPaul
Userlevel 7
Badge +20

This is good to know.  Since I only have one Gateway, I guess vspc.domain.com and vcc.domain.com pointing to the same server (Gateway and console are the same server) but I had planned on if we grew to needing additional gateways I'd add as needed. 

Hi @dloseke 🙂 when time permits you should consider splitting those out onto separate servers. A cloud gateway should reside in a DMZ with limited internal access due to it being web facing, and it would do a lot of damage if your VSPC server was compromised

Michael Paul - #VeeamLegend | #VeeamVanguard | Veeam Certified Architect | VMware vExpert | https://micoolpaul.com | Twitter: @MicoolPaul | Mastodon: @micoolpaul@masto.nu | Bluesky: @micoolpaul.bsky.social
dloseke
Userlevel 7
Badge +6

This is good to know.  Since I only have one Gateway, I guess vspc.domain.com and vcc.domain.com pointing to the same server (Gateway and console are the same server) but I had planned on if we grew to needing additional gateways I'd add as needed. 

Hi @dloseke 🙂 when time permits you should consider splitting those out onto separate servers. A cloud gateway should reside in a DMZ with limited internal access due to it being web facing, and it would do a lot of damage if your VSPC server was compromised

I wouldn’t mind doing that anyway...I hate the name I’m using for the server and as it’s using a old naming convention.  With that said, I need to reread the documentation I think.  I was thinking they were both web-facing, just with the needed specific ports.

Derek M. Loseke, Senior Systems Engineer | Veeam Legend 2022-2023 | VMSP/VMTSP | VCP6-DCV | VSP/VTSP | CCNA | https://technotesanddadjokes.com | @dloseke
HangTen416
Userlevel 7
Badge +10

So I’ve found out more about how VSPC Management Agent communication and VCC Cloud Gateway communication happens. Turns out the information is in the documentation but who reads ALL the documentation? 😉

It seems to me that the round-robin DNS isn’t necessary as the first (and subsequent) connections to a Cloud Gateway will provide the VSPC Management Agent or VBR or Backup Agent on the tenant side with a full list of the gateways to connect to. This answers the main question I had which was more of a cosmetic issue as both the Management Agent and the service provider settings for a VBR deployed using VSPC shows only one of the gateway DNS names. Under the hood, all gateway IPs or DNS names are understood.

Reference:

Veeam Service Provider Console management agent setup file contains the list of FQDN or IP addresses of cloud gateways assigned to the company. This list can include only up to 7 IP addresses or 150 FQDN symbols. When you deploy a management agent on a computer, the agent connects to Veeam Service Provider Console using the first available gateway from the list. If the connection fails, the management agent will automatically fail over to the next gateway. Once the connection is established, the management agent obtains from Veeam Service Provider Console FQDN or IP addresses of all cloud gateways assigned to the company.
 
 

Veeam Backup & Replication supports automatic failover between cloud gateways configured in the Veeam Cloud Connect infrastructure. When a tenant connects to the SP using a DNS name or IP address of a cloud gateway, the Veeam backup server on the tenant side obtains a list of all configured cloud gateways. If the primary cloud gateway is unavailable, the Veeam backup server on the tenant side fails over to another cloud gateway from the list.

https://helpcenter.veeam.com/docs/backup/cloud/cloud_connect_gateway.html?ver=120

 
VMCE2024 | VMCA2022 | Veeam Legend
Chris.Childerhose
Userlevel 7
Badge +20

So I’ve found out more about how VSPC Management Agent communication and VCC Cloud Gateway communication happens. Turns out the information is in the documentation but who reads ALL the documentation? 😉

It seems to me that the round-robin DNS isn’t necessary as the first (and subsequent) connections to a Cloud Gateway will provide the VSPC Management Agent or VBR or Backup Agent on the tenant side with a full list of the gateways to connect to. This answers the main question I had which was more of a cosmetic issue as both the Management Agent and the service provider settings for a VBR deployed using VSPC shows only one of the gateway DNS names. Under the hood, all gateway IPs or DNS names are understood.

Reference:

Veeam Service Provider Console management agent setup file contains the list of FQDN or IP addresses of cloud gateways assigned to the company. This list can include only up to 7 IP addresses or 150 FQDN symbols. When you deploy a management agent on a computer, the agent connects to Veeam Service Provider Console using the first available gateway from the list. If the connection fails, the management agent will automatically fail over to the next gateway. Once the connection is established, the management agent obtains from Veeam Service Provider Console FQDN or IP addresses of all cloud gateways assigned to the company.
 
 

Veeam Backup & Replication supports automatic failover between cloud gateways configured in the Veeam Cloud Connect infrastructure. When a tenant connects to the SP using a DNS name or IP address of a cloud gateway, the Veeam backup server on the tenant side obtains a list of all configured cloud gateways. If the primary cloud gateway is unavailable, the Veeam backup server on the tenant side fails over to another cloud gateway from the list.

https://helpcenter.veeam.com/docs/backup/cloud/cloud_connect_gateway.html?ver=120

 

Very interesting.  Thanks for sharing the update.  Time to get reading some more.  😁

Chris Childerhose - VMCA2022 | VMCE2023 | Veeam Vanguard 7* | Veeam Legend 3* | vExpert 5* | VCAP-DCV/VCP-DCV | Object First Ace | Cisco Champion | Twitter: @cchilderhose | Blog Site – https://just-virtualization.tech
dloseke
Userlevel 7
Badge +6

Thanks for this.  I need to read more on this myself.  I don’t have multiple cloud gateways or VCC servers, so I kinda glossed over that part a little when I was performing my setup, but I did look at it because I wanted to set it up in a way that would be scalable if/when the time came that I needed a gateway and multiple VCC servers.  But I think that was also two versions ago, so I need to reread to refresh my memory, but also in the event of updates/changes in the product as well.

Derek M. Loseke, Senior Systems Engineer | Veeam Legend 2022-2023 | VMSP/VMTSP | VCP6-DCV | VSP/VTSP | CCNA | https://technotesanddadjokes.com | @dloseke
G
Userlevel 3

Hello hello, the post is some time old, I hope you can help me.

Understanding the documentation, but I have the following doubt, if the client when it connects to the gateway, and it is not available, performs the failover, how should I configure my nat, that is, it is not clear to me if I only do the Is NAT a single gateway or if I do 1 nat for each Gateway? I don't know if I can explain myself? Thanks for the prompt response.

Chris.Childerhose
Userlevel 7
Badge +20

Hello hello, the post is some time old, I hope you can help me.

Understanding the documentation, but I have the following doubt, if the client when it connects to the gateway, and it is not available, performs the failover, how should I configure my nat, that is, it is not clear to me if I only do the Is NAT a single gateway or if I do 1 nat for each Gateway? I don't know if I can explain myself? Thanks for the prompt response.

Which product are you referring to for Veeam?  Veeam Cloud Connect?  Gateways use DNS round robin typically for load balancing.  We need a bit more clarity to help or make suggestions.

Chris Childerhose - VMCA2022 | VMCE2023 | Veeam Vanguard 7* | Veeam Legend 3* | vExpert 5* | VCAP-DCV/VCP-DCV | Object First Ace | Cisco Champion | Twitter: @cchilderhose | Blog Site – https://just-virtualization.tech
HangTen416
Userlevel 7
Badge +10

Hello hello, the post is some time old, I hope you can help me.

Understanding the documentation, but I have the following doubt, if the client when it connects to the gateway, and it is not available, performs the failover, how should I configure my nat, that is, it is not clear to me if I only do the Is NAT a single gateway or if I do 1 nat for each Gateway? I don't know if I can explain myself? Thanks for the prompt response.

The set up should be multiple A records in public DNS entries for the main URL which provides round robin redundancy. Each IP should be set up with one to one NAT to a single internal gateway server. Each internal gateway server should be set up with unique URL (eg prefix gw1, gw2, etc to the main URL) and those DNS records should also be configured in public DNS with one to one mapping. Eg main URL has three A records. Gw1.mainURL has one IP. Gw2.mainURL has second IP, etc.

VMCE2024 | VMCA2022 | Veeam Legend
G
Userlevel 3

Thanks for the prompt response and explanation, now if I add one of that url that would belong to a single Gateway, but this gateway at some point becomes unavailable, could it automatically and/or natively do the switching error even though the client side was added with the URL belonging to that gateway that would be dowm in this example?

Chris.Childerhose
Userlevel 7
Badge +20

Thanks for the prompt response and explanation, now if I add one of that url that would belong to a single Gateway, but this gateway at some point becomes unavailable, could it automatically and/or natively do the switching error even though the client side was added with the URL belonging to that gateway that would be dowm in this example?

You would not use a GW URL as it would be the main URL for the service which points to the GW URLs.  This way it can failover to another.  If you use a specific GW URL then you have failures until changed.

Chris Childerhose - VMCA2022 | VMCE2023 | Veeam Vanguard 7* | Veeam Legend 3* | vExpert 5* | VCAP-DCV/VCP-DCV | Object First Ace | Cisco Champion | Twitter: @cchilderhose | Blog Site – https://just-virtualization.tech
G
Userlevel 3

Sorry, it's still not very clear to me, I'm going to put it more or less as it would be so that you can guide me better, I thank you very much.

Suppose my domain is mydomain.com

I have 3 gateway servers with the following private and public IPs with their respective NAT on my firewall

Gateway 1=190.168.20.90 with private IP 192.168.10.10
Gateway 2=190.168.20.91 with private IP 192.168.10.11
Gateway 3=190.168.20.92 with private IP 192.168.10.12

I understand that the urls would remain

G1= gw1.mydomain.com
G2= gw2.mydomain.com
g3= gw3.mydomain.com

I understand that the A records within my DNS will be these:

G1= gw1.mydomain.com
G2= gw2.mydomain.com
g3= gw3.mydomain.com

But what URL should you give to the client to connect to the gateways.

As I understand it, it would be "mydomain.com"

Assuming this is the case, shouldn't I do anything in my DNS hosting for it to recognize the gateways?

Sorry if it doesn't explain it to me and thanks for the response.

Chris.Childerhose
Userlevel 7
Badge +20

You need three more records for the primary URL that point to the same IPs as the GW URLs.

Service.mydomai.com = IP1

Service.mydomain.com = IP2

Service.mydomain.com = IP3

This is the URL customers use but the GWs in Veeam use the gateway URLs.

Chris Childerhose - VMCA2022 | VMCE2023 | Veeam Vanguard 7* | Veeam Legend 3* | vExpert 5* | VCAP-DCV/VCP-DCV | Object First Ace | Cisco Champion | Twitter: @cchilderhose | Blog Site – https://just-virtualization.tech

Comment


Terms & Conditions