Questions tagged with Virtual Private Cloud

Content language: English

Sort by most recent

Browse through the questions and answers listed below or filter and sort to narrow down your results.

  • 1
  • 2
  • 12 / page

Adding MFA to Workspaces "failed" problem

I have been attempting to add Mult-Factor Authentication to my workspaces account for my user base. I have configured the radius server using Free Radius from this post here: https://aws.amazon.com/blogs/desktop-and-application-streaming/integrating-freeradius-mfa-with-amazon-workspaces/ and all goes according to plan. I have the FreeRadius server using LinOTP running. The problem is in the very last step, when I go to enable MFA in workspace , I put in the information and it just says "failed". Specifically, Step 6: Enable MFA on your AWS Directory Communication between the AWS Managed Microsoft AD RADIUS client and your RADIUS server require you to configure AWS security groups that enable communication over port 1812. Edit your Virtual Private Cloud (VPC) security groups to enable communications over port 1812 between your AWS Directory Service IP end points and your RADIUS MFA server. Navigate to your Directory Service console Click the Directory you want to enable MFA on. Select Network & Security tab, scroll down to Multi-factor authentication, click Actions and Enable. In Enable multi-factor authentication (MFA) configure MFA settings: Display label: Example RADIUS server IP address(es): Private IP of the Amazon Linux 2 instance Port: 1812 Shared secret code: the one set in /etc/raddb/clients.conf Confirm shared secret code: as preceding Protocol: PAP Server timeout (in seconds): 30 Max retries: 3 This operation can take between 5-10mins to complete. Once the Radius status is “completed” you can test MFA authentication from the WorkSpace client. I really have two questions: 1. How do I do this part? Edit your Virtual Private Cloud (VPC) security groups to enable communications over port 1812 between your AWS Directory Service IP end points and your RADIUS MFA server. Maybe I'm not setting up the endpoints correctly ? Do I go to the VPC and add endpoints there? CAn you pleae be specific. 2. How do I get more information from just the "failed" in red --- how do I access the creation logs? Thanks in advance, Jon
2
answers
0
votes
154
views
asked 7 months ago

Configured VPC NAT instances stopped working yesterday (03.03.2022, eu-central-1)

Hi, I'm confronted with a really annoying problem currently. My custom VPC (3 public subnets, 3 private subnets -> internet access through NAT instances) broke out of the blue yesterday. My infrastructure is deployed via CloudFormation and yesterday I updated a stack where three NAT instances for my VPC are located (for each public subnet there is one NAT instance deployed in it). They have worked flawlessly before yesterday and as a new Amazon Linux 2 version was released (I reference the AMI ID via /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-arm64-gp2), these instances got updated to use the newest AMI. Since then I have problems routing traffic from private subnets to the internet as things are not working as expected anymore. The current primary point of failure is that my CodePipeline fails because a CodeBuild action fails. The temporary CodeBuild instance is deployed in one of the three private subnets and then has to download a CodePipeline artifact from S3 through the internet. This step fails with the following error: `CLIENT_ERROR: RequestError: send request failed caused by: Get "https://s3.eu-central-1.amazonaws.com/<S3-bucket-name>?location=": dial tcp 52.219.170.173:443: connect: no route to host for primary source and source version arn:aws:s3:::<S3-prefix>` The thing is: before yesterday's last stack update which altered the NAT instances, everything was working as expected and CodePipeline succeeded. CodeBuild was able to download the necessary artifacts from S3 and the VPC and NAT instances were set up correctly. Then the update came in and CodeBuild fails now. The only thing that was changed was the AMI ID for the NAT instances (and I replaced absolute strings for "ProjectName" in my CodeBuild actions in CodePipeline with !Ref to the AWS::CodeBuild::Project resources which should have nothing to do with my current problem). After the updated NAT instances were not working anymore, I set their AMI IDs to explicit older versions as I assumed that there is a problem with the newest Amazon Linux 2 version. However, even with the older AMIs I'm not able to get the NAT instances working again (at least not for CodeBuild, but I noticed that ECS services running on an EC2 instance (which is also deployed in a private subnet) lost connection to the internet as well). I even redeployed the whole infrastructure to check if there is a problem on the side of AWS but the problem persists. The problem got me really frustrated now as everything was working fine. Then a small update was applied and now the NAT instances fail even if I havn't changed anything in the VPC and NAT configuration. Where should the problem be now if not on the side of AWS? My currently deployed NAT instances are configured as described by AWS and as they have worked before, they are reachable via SSH and can access the internet via the VPCs internet gateway. Still, CodeBuild continues to fail with the mentioned error and the internet seems not to be accessible from private subnets as it was the case before yesterday. I would be more than glad if anyone has suggestions how this problem can be resolved now. Thanks in advance!
3
answers
0
votes
122
views
Czyze
asked 9 months ago

Connect Amazon DocumentDB Cluster from Outside Amazon VPC

Connect Amazon DocumentDB Cluster from Outside Amazon VPC Amazon DocumentDB (with MongoDB compatibility) clusters are deployed within an Amazon Virtual Private Cloud (Amazon VPC). They can be accessed directly by Amazon EC2 instances or other AWS services that are deployed in the same Amazon VPC I setup an EC2 (same VPC as DocumentDB) with security permissions for port 22 SSH and can do this command below successfully to the EC2 $ ssh -i "AWSshkeyForEC2.pem" ubuntu@xxxx.compute-1.amazonaws.com No problem. I then try to setup a tunneling (for the DocumentDB at port 27017) issuing this command line $ ssh -i "AWSshkeyForEC2.pem" -L 27017:docdbwhatever.us-east-1.docdb.amazonaws.com:27017 ubuntu@xxxx.compute-1.amazonaws.com -N and says Warning: Permanently added 'xxxx.compute-1.amazonaws.com,yyyyy' (ECDSA) to the list of known hosts. and just hangs there? I am on a OSX machine. Overall I rather create the DocumentDB without the VPC for a DBaaS. There is a reasons for this the live hardware is on site at the factory for data and then the data should be stored at the Mongo Database in the cloud. Other Apps run in the cloud and can reference the DocumentDB. We are not going to have an App in the cloud to access hardware outside of the cloud due to security. So maybe the solution is to somehow create the DocumentDB without the VPC. I saw I could have deleted the default(VPC) and maybe I should have. The address is the magic 27017 of course for Mongo to the DocumentDB.
2
answers
0
votes
382
views
redpath
asked 10 months ago
  • 1
  • 2
  • 12 / page