For testing purposes, I set up a VPC on Amazon and created an instance within the VPC. I've added a gateway for the 0.0.0.0/0 address to the attached routing table, and given the instance an elastic IP address. I'm unable to ssh or ping it, even when I set the security group to allow all traffic. I must be missing something obvious. What am I doing wrong?
It turns out that when I created the instance, I accepted the default security group, which only allows access from a specific IP address. When I added another instance, I created it with a security group which allowed all traffic, and I was able to ping it.
Related
I am trying to set up SSM on Windows.
I have an ASG in a private subnet (absolutely 0 internet access). I can not use NAT, only VPC endpoints.
In the instance launch configuration, I have a PowerShell script that uses Set-DnsClientServerAddress so that the instance can find and join an AWS Managed MS AD service. I would also like to set up the instance so it can be fully managed with SSM.
The problem comes with the DNS Client Server Address.
When I set it to match the address of the AD service SSM will not work.
When I leave the DNS Client Server Address default, SSM works but I can not join the AD.
I tried forcing the SSM Agent to use the endpoints by creating a amazon-ssm-agent.json file and setting all three endpoints in there. This allowed the instance to show on the Managed Instance list, but its status never changed from pending and requests from within the instance still timed out.
Does anyone know the magic sauce to get these things all working at the same time?
EDIT 1:
I also tried adding a forward as described in this thread, however I'm either missing somethign or it is not working for my case:
https://forums.aws.amazon.com/thread.jspa?messageID=919331󠜣
It turns out that adding the forwarder as described in the link above worked. The part I was missing was joedaws comment, "I would also remove the existing 169.254.169.253 entry so that only the 10.201.0.2 ip address is in the list".
Of course, my IPs are different, but once I removed the preexisting forward so that my x.x.x.2 IP was the only one in the list (I did this for both of the AD DNS servers) the instance was discoverable by SSM.
So, I would make a minor change to the list that saugy wrote:
On a domain joined windows instance, log in with AD domain Admin user
Open DNS manager
Connect to one of the DNS IP addresses for the AWS AD
Select forwarders
Add the VPC's DNS IP (x.x.x.2 from you VPC's CIDR range)
Remove the existing IP (so you VPCs IP is the only one)
Click Apply
Repeat from step 3 with the other DNS IP address for the AWS AD (not 1
Also, as mentioned in the other post. This only has to be done once and the settings persist in the AD DNS.
I have a VPC. In it I have two sub-nets (subnet-1, subnet-2).
Subnet-1 has these EC2 instances: 10.0.0.66, 10.0.0.83
Subnet-2 has these EC2 instances: 10.0.0.203, 10.0.0.208
I would expect to be able to ping from 10.0.0.66 to 10.0.0.83 and I can.
However, I would not expect to be able to ping from 10.0.0.203 to 10.0.0.83 but I can. I thought the whole point of a subnet was to keep instances in it isolated from other subnets? Why then can I ping across subnets?
Yes, You can able to Ping/SSH all your instance within your VPC.
When you create your VPC with your preferred CIDR range,Your main Route table will be created automatically and which will allow you to reach whole CIDR range. It does not matter how many subnets you have created under the VPC. This is default behavior in AWS.
If you want to block the access from one subnet to another subnet you can restrict.Select VPC associated Network ACL and edit the Inbound rule. By default source will be 0.0.0.0/0 ,You Mention the subnet which you want to access. You can restrict based on protocol/Port also.Post changes You can't reach from the subnet which you have not allowed.
For Reference : https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html
I am unable to connect to amazon ec2 instance (public domain) form office network. It works fine outside the office network.
Looks like something is getting blocked in the network. Not sure how to figure out or which logs need to be checked to find out what exactly is getting blocked.
Error Message:
ec2-54-218-186-23.us-west-2.compute.amazonaws.com took too long to respond.
Typically, if the connection takes too long to respond, the problem is due to the Security Group assigned to the instance. Check that it is allowing Inbound access from the entire Internet (0.0.0.0/0) on your desired port (Windows RDP port 3389, SSH port 80).
Of course, opening up access to the entire Internet is not good for security, so it is better to limit it to a smaller range of IP addresses, such as your corporate network and your home IP address.
Reason
Security groups enable you to control traffic to your instance, including the kind of traffic that can reach your instance. For example, you can allow computers from only your home network to access your instance using SSH. If your instance is a web server, you can allow all IP addresses to access your instance using HTTP or HTTPS, so that external users can browse the content on your web server.
Before You Start
Decide who requires access to your instance; for example, a single host or a specific network that you trust such as your local computer's public IPv4 address. The security group editor in the Amazon EC2 console can automatically detect the public IPv4 address of your local computer for you. Alternatively, you can use the search phrase "what is my IP address" in an internet browser, or use the following service: Check IP. If you are connecting through an ISP or from behind your firewall without a static IP address, you need to find out the range of IP addresses used by client computers.
Warning
If you use 0.0.0.0/0, you enable all IPv4 addresses to access your instance using SSH. If you use ::/0, you enable all IPv6 address to access your instance. This is acceptable for a short time in a test environment, but it's unsafe for production environments. In production, you authorize only a specific IP address or range of addresses to access your instance.
THE SOLUTION BEGINS HERE
Your default security groups and newly created security groups include default rules that do not enable you to access your instance from the Internet. To enable network access to your instance, you must allow inbound traffic to your instance. To open a port for inbound traffic, add a rule to a security group that you associated with your instance when you launched it.
Adding a Rule for Inbound SSH Traffic to a Linux Instance
In the navigation pane of the Amazon EC2 console, choose Instances. Select your instance and look at the Description tab; Security groups lists the security groups that are associated with the instance. Choose view rules to display a list of the rules that are in effect for the instance.
In the navigation pane, choose Security Groups. Select one of the security groups associated with your instance.
In the details pane, on the Inbound tab, choose Edit. In the dialog, choose Add Rule, and then choose SSH from the Type list.
In the Source field, choose My IP to automatically populate the field with the public IPv4 address of your local computer. Alternatively, choose Custom and specify the public IPv4 address of your computer or network in CIDR notation. For example, if your IPv4 address is 203.0.113.25, specify 203.0.113.25/32 to list this single IPv4 address in CIDR notation. If your company allocates addresses from a range, specify the entire range, such as 203.0.113.0/24.
Choose Save.
You can find detailed solution here
I'm unable to join an EC2 instance to my Directory Services Simple AD in Amazon Web Services manually, per Amazon's documentation.
I have a Security Group attached to my instance which allows HTTP and RDP only from my IP address.
I'm entering the FQDN foo.bar.com.
I've verified that the Simple AD and the EC2 instance are in the same (public, for the moment) subnet.
DNS appears to be working (because tracert to my IP gives my company's domain name).
I cannot tracert to the Simple AD's IP address (it doesn't even hit the first hop)
I cannot tracert to anything on the Internets (same as above).
arp -a shows the IP of the Simple AD, so it appears my instance has received traffic from the Simple AD.
This is the error message I'm receiving:
The following error occurred when DNS was queried for the service
location (SRV) resource record used to locate an Active Directory
Domain Controller (AD DC) for domain "aws.bar.com":
The error was: "This operation returned because the timeout period
expired." (error code 0x000005B4 ERROR_TIMEOUT)
The query was for the SRV record for _ldap._tcp.dc._msdcs.aws.bar.com
The DNS servers used by this computer for name resolution are not
responding. This computer is configured to use DNS servers with the
following IP addresses:
10.0.1.34
Verify that this computer is connected to the network, that these are
the correct DNS server IP addresses, and that at least one of the DNS
servers is running.
The problem is the Security Group rules as currently constructed are blocking the AD traffic. Here's the key concepts:
Security Groups are whitelists, so any traffic that's not explicitly allowed is disallowed.
Security Groups are attached to each EC2 instance. Think of Security Group membership like having a copy of an identical firewall in front of each node in the group. (In contrast, Network ACLs are attached to subnets. With a Network ACL you would not have to specify allowing traffic within the subnet because traffic within the subnet does not cross the Network ACL.)
Add a rule to your Security Group which allows all traffic to flow within the subnet's CIDR block and that will fix the problem.
The question marked as the answer is incorrect.
Both of my AWS EC2 instances are in same VPC, same subnet, with same security group.
I have the same issue. Here are my inbound rules on my security group:
Here is the outbound rules:
I can also ping from the between the dc and the other host, bi-directional with replies on both side.
I also have the DC IP address set as the primary and only DNS server on the other EC2 instance.
AWS has some weird sorcery preventing a secondary EC2 instance from joining the EC2 domain controller, unless using their managed AD services which I am NOT using.
The other EC2 instance has the DC IP address set as primary DNS. And bundled with the fact I can ping each host from each other, I should have ZERO problems joining to domain.
I had a very similar problem, where at first LDAP over UDP (and before that, DNS) was failing to connect, even though the port tests were fine, resulting in the same kind of error (in network traces, communication between standalone server EC2 instance and the DC instance stopped at "CLDAP 201 searchRequest(4) "" baseObject", with nothing being returned). Did all sorts of building and rebuilding, only to find out that I was inadvertently blocking UDP traffic, which AWS needs for both LDAP and DNS. I had allowed TCP only, and the "All Open" test SG I was using was also TCP only.
D'oh!!!
Is there any way to make new instances added to an autoscaling group associate with an elastic IP? I have a use case where the instances in my autoscale group need to be whitelisted on remote servers, so they need to have predictable IPs.
I realize there are ways to do this programmatically using the API, but I'm wondering if there's any other way. It seems like CloudFormation may be able to do this.
You can associate an Elastic IP to ASG instances using manual or scripted API calls just as you would any other instance -- however, there is no automated way to do this. ASG instances are designed to be ephemeral/disposable, and Elastic IP association goes against this philosophy.
To solve your problem re: whitelisting, you have a few options:
If the system that requires predictable source IPs is on EC2 and under your control, you can disable IP restrictions and use EC2 security groups to secure traffic instead
If the system is not under your control, you can set up a proxy server with an Elastic IP and have your ASG instances use the proxy for outbound traffic
You can use http://aws.amazon.com/vpc/ to gain complete control over instance addressing, including network egress IPs -- though this can be time consuming
There are 3 approaches I could find to doing this. Cloud Formation will just automate it but you need to understand what's going on first.
1.-As #gabrtv mentioned use VPC, this lends itself to two options.
1.1-Within a VPC use a NAT Gateway to route all traffic in and out of the Gateway. The Gateway will have an Elastic IP and internet traffic then whitelist the NAT Gateway on your server side. Look for NAT gateway on AWS documentation.
1.2-Create a Virtual Private Gateway/VPN connection to your backend servers in your datacenter and route traffic through that.
1.2.a-Create your instances within a DEDICATED private subnet.
1.2.b-Whitelist the entire subnet on your side, any request from that subnet will be allowed in.
1.2.c Make sure your routes in the Subnet are correct.
(I'm skipping 2 on purpose since that is 1.2)
3.-The LAZY way:
Utilize AWS Opsworks to do two things:
1st: Allocate a RESOURCE Pool of Elastic IPs.
2nd: Start LOAD instances on demand and AUTO assign them one elastic ip from the Pool.
For the second part you will need to have the 24/7 instances be your minimum and the Load instances be your MAX. AWS Opsworks now allows Cloud Watch alarms to trigger instance startup so it is very similar to ASG.
The only disadvantage of Opsworks is that instances aren't terminated but stopped instead when the load goes down and that you must "create" instances beforehand. Also you depend on Chef solo to initiate your instances but is the only way to get auto assigning EIPs to your newly created instances that I could find.
Cheers!