Archive to Glacier and using EC2 over private connection

[mark49808]

I see and followed this article (https://www.veeam.com/kb4226), which successfully sends s3 traffic over the direct connection.

However the s3 -> Glacier step seems to require the temporary proxy ec2 instance, which appears to be created over a public IP. I've tried editing the xml file in the KB article to override the ec2 instance endpoint as well (even though this is not mentioned in the article) but that does not seem to work, or at least its still failing on a connection from my public IP.

<Endpoint Type="S3">bucket.vpc.<redacted>.s3.us-east-2.vpce.amazonaws.com</Endpoint>
<Endpoint Type="EC2">vpce-<redacted>.ec2.us-east-2.vpce.amazonaws.com</Endpoint>

Ideally I'd want all traffic to flow over my private connection, including the call to set up the ec2 instance. Instead, I get this error message:
"Cannot find a security group with open ports 22 and 443 for IP address <my public IP>"

Once I allow that public IP, all is well. However, my desire here is not use public internet at all.

Can you advise the expected behavior for the ec2 piece and if it can be overridden like the s3 steps in the KB?

I'm running latest 11a.

[veremin]

Kindly, read the referenced article carefully, as it provides the answers to your questions:

In order to use PrivateLink Endpoint with your Archive Tier extent, you will need some additional tweaks:

Create the following registry parameter on the Veeam Backup Server:

Key Location: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
Value Name: ArchiveFreezingUsePrivateIpForAmazonAppliance
Value Type: DWORD (32-Bit) Value
Value Data: 1

Configure an EC2 Interface Endpoint in your VPC.

This tweak will allow backup server to communicate with the appliance over private network.

Thanks!

[mark49808]

Hi, I did set both registry keys and rebooted the server afterwards. It does seem to work, however, i still received an error when attempting to validate the config.

What i was seeing during the validation phase is below… note the associatePublicIpAddress being true… this implies that it wants to set a public IP address on the extent that it creates, which will create an invalid networking scenario in our case, as no traffic is allowed to hit the internet directly via an AWS Internet Gateway

Code: Select all

{
  "instancesSet": {
    "items": [
      {
        "imageId": "ami-0be1e365ee45143c8",
        "minCount": 1,
        "maxCount": 1
      }
    ]
  },
  "instanceType": "m5a.large",
  "blockDeviceMapping": {},
  "monitoring": {
    "enabled": false
  },
  "disableApiTermination": false,
  "disableApiStop": false,
  "clientToken": "<redacted>",
  "networkInterfaceSet": {
    "items": [
      {
        "deviceIndex": 0,
        "subnetId": "<redacted>",
        "associatePublicIpAddress": true,
        "groupSet": {
          "items": [
            {
              "groupId": "<redacted>"
            }
          ]
        }
      }
    ]
  }
}

When it validates the security group, it also looks like it’s grabbing the public IP address of the gateway server and then validating against that IP address, as opposed to recognizing that privatelink is in use and instead using the private IP address.

Does that make sense?

[veremin]

One more question, then - what exact validation procedure you refer to?

[mark49808]

When setting up parameters for the Proxy Appliance when adding a Glacier extent, you click Apply, and it seems to validate something (while not actually deploying).

[veremin]

If it eventually fails or the public IP is still used regardless of proper configuration, then reach our support team for further investigation, as it does not look like something that can be fixed over forum correspondence.

You can share the ticket number here and we can pass it over to our Q&A team who will be also interested in this case.

Thanks!

[mark49808]

Case 05311247

[veremin]

Passed to QA team. Will update the thread, once I have more information. Thanks!

[veremin]

QA team has expressed interest in this case, so there will be a joint investigation conducted. I will keep the thread updated.

[mark49808]

Support helped solve this.

Code: Select all

Value Path: HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication
Value Name: ArchiveFreezingSkipProxyValidation
Value Type: DWORD
Value Data: 1

Bypasses the validation which is hard coded to public IP.

Seems like something that should be on the KB?

[veremin]

We have raised this request (to update the KB article) internally. I will let you know, once it's processed. Thanks!

[veremin]

The KB article has been updated.

[B-C]

We are experiencing a very similar error...
Support unfortunately hasn't been able to give options
Case #05841131
Below key is present but the other 4 are not...
ArchiveFreezingUsePrivateIpForAmazonAppliance

For us the odd part is the test-netconnection fails however the there are 3 IPs on the server 1 Production 2x iSCSI\SAN - non routed IPs and naturally the proxy process picks SAN2 IP address to proxy its connection to AWS..
IP 3 > 127.0.0.1(custom port) > goes back through mgmt IP in redirects it appears.

older Logs show
?:\ProgramData\Veeam\Backup\SOBR_Archival_xxxx\Session_xxxx
We see a lot of Granados Failures then Renci makes the connection in the logs at least in the past it did.. Now just fails and never makes any connection.

When testing the test-netconnection without being able to specify the specific interface the test is kinda flawed it looks like.

we've removed any filtering from the server so its essentially passing out NAT without inspection outbound

looking at the xml examples where would I locate the specific config.xml
"associatePublicIpAddress": true,

article only shows
C:\Program Files\Veeam\Backup and Replication\Backup\AmazonS3Regions.xml

yet the OP found the vpc config (was wondering what path that is at)

Code: Select all

{
  "instancesSet": {
    "items": [
      {
        "imageId": "ami-0be1e365ee45143c8",
        "minCount": 1,
        "maxCount": 1
      }
    ]
  },
  "instanceType": "m5a.large",

part 2 of the issue for us is a Sister Server in a different segment of the environment, however egress is the same WAN IP the Archive and proxy communicate without any issue and no additional registry keys - no issue outbound / sshproxy connecting.


Looking for ideas, Escalated Ticket seems to be stumping the Engineer.