i've an elastic IP associated with my instance
i've security group of instance permits incoming connections
my instance firewall permits incoming connections
my application listens
i allowed specifically the Echo Request protocol in the ICMP inbound
traffic of my EC2 instances.
In the past I could ping the domain name linked to my machine.
After looking for where the error could have come from I realized that in elastic IP there was no NAT Gateway associated.
I can't remember if this is necessary or not ?
i guess this issue is coming from here .
Function of NAT gateway is to enable instance in a private subnet to connect to the internet and prevent the internet from initiating a connection with those instance. NAT gateway need elastic IP. So if you have an NAT gateway configured then one EIP should be attached with it. In your case this EIP is attached to an EC2 instance not to NAT gateway thats why it showing no NAT gateway attached.
Your issue might be with security group rules. Check your SG. To exactly answer your question please add more information in your question like..Where your instance launched. In public subnet or in private subnet ? Have you attached EIP to instance launched in private subnet ? What is the inbound rules configured in SG ? what is the command you are using ?
Update:
Instance were launched in private subnet. After adding routes for IGW in the route table of the subnet, this issue has been resolved
Related
I've been following the instructions here: https://aws.amazon.com/blogs/networking-and-content-delivery/simulating-site-to-site-vpn-customer-gateways-strongswan/
I can successfully get the VPN up and running, but I can't successfully ping internal IP addresses from behind the VPN.
Here's my setup:
"On-prem" is simulated using a VPC with IP address: 172.19.0.0/16. The VPN is deployed on an EC2 instance in the subnet 172.19.16.0/20. This subnet has the following route table:
Destination
Target
172.19.0.0/16
local
172.21.0.0/16
eni-XXXXXXXXX
0.0.0.0/0
igw-XXXXXXXXX
Where eni-XXXXXXXXX is the network interface of the EC2 instance that has the VPN deployed on it.
My cloud VPC has the CIDR range: 172.21.0.0/16. I have an EC2 instance deployed in the 172.21.32.0/20 subnet which has the following route table:
Destination
Target
172.21.0.0/16
local
172.19.0.0/16
vgw-XXXXXXXXX
0.0.0.0/0
igw-XXXXXXXXX
Where the vgw-XXXXXXXXX is the virtual gateway associated with the VPN I have.
I can send traffic from my "on-prem" VPC into my cloud VPC successfully, but no traffic comes back out. I've tested this by SSHing into an EC2 instance in my "on-prem" VPC and then pinging a private IP address of an EC2 instance in my cloud VPC and I can see the pings are received by the EC2 instance in the cloud VPC, but my "on-prem" instance never receives the response.
I have checked my security groups and NACLs and they are not preventing this type of traffic.
Is there something misconfigured here?
This is not an entirely satisfying answer, but I moved from using a Virtual Private Gateway to using a Transit Gateway and I was able to get it to work.
I have the config below on AWS:
NLB with TCP 443 listner on it
NAT instance in Target Group under NLB in public subnet with preconfigured iptables on it, the health check is passed
EC2 instance in private subnet
Routing table for private subnet uses NLB eni for 0.0.0.0 destination
Default Security Group accepts all incoming traffic from VPC and it's attached to EC2 and NAT instance
The problem is that I can't reach any external resource from the EC2, the example is below:
telnet 1.1.1.1 443
Trying 1.1.1.1...
telnet: connect to address 1.1.1.1: Connection timed out
I turned Flow Logs on NLB and NAT enis and I see, that request from EC2 is accepted by NLB's eni, but there is no request on NAT's eni.
When I change my Routing table to use eni from NAT instance, not NLB, I can reach anything I want.
How can I make reach the Internet from EC2 in private subnet using NLB's eni with NAT instance under it?
You cannot use an NLB for routing you're limited to NAT Gateway or NAT instance from this perspective.
If you are trying to add resilience or gain performance over multiple nodes you should instead make use of the NAT Gateway.
One of the reasons NAT Gateways exist is they provided a scalable solution, prior to this you were limited to a single NAT instance per route table and the only way to adjust performance was to change instance type.
Our aim is to get our Elastic Beanstalk setups to route traffic through a NAT gateway as we require for certain traffic connecting to API's which require IP whitelisting. Rather than make modifications to the current setup, I have created a separate/isolated VPC & EC2 instance to familiarise and test the setup. However I am yet to get the setup working as desired.
Here is the setup
VPC (vpc-77049811) with CIDR of 10.0.0.0/16
Internet gateway (igw-4d4b212a) assigned to mentioned VPC
Subnet (subnet-096d8a53) with CIDR of 10.0.1.0/24
NAT Gateway (nat-00bb49204627de7e6) attached to mentioned subnet and assigned Elastic IP
Route table attached to mentioned VPC and associate with mentioned subnet
1x EC2 Instance assigned to VPC and its own Elastic IP and Disabled Source/Destination Check
Route Table Setup
10.0.0.0/16 local
0.0.0.0/0 igw-4d4b212a
With the above setup, and am able to log into the server and make a curl request to get the servers public IP address (curl icanhazip.com). As soon as I add a rule to the route table for the url's resolved IP's to route through the NAT gateway though, I am unable to ping or request the curl request as it will timeout.
Rules added to route table which do not work
45.63.64.111/32 nat-00bb49204627de7e6
144.202.71.30/32 nat-00bb49204627de7e6
Not sure if I've overlooked something here or maybe I have misunderstood the concept and use cases for the NAT gateway?
This is public IP 45.63.64.111. You need IGW to reach to this traffic.
You either do that by directly redirecting your traffic to IGW
OR
You do that by directing to NAT then further directing that traffic to IGW
Directing to IGW part is missing.
Nat gateway is used for EC2 in private subnets (which does not have IGW attached to it). In scenario above, EC2 is in public subnet so ideally it does not need NAT.
Here is what I would do to use NAT-
1. Place EC2 in private subent. and have a Route table where all outgoing traffic to nat-gateway.
2. Nat-gateway which is in public subnet will forward your traffic to IGW.
It seems like you have misunderstood the purpose of a NAT.
Its purpose is to provide outbound internet access to instances in a private subnet without allowing any inbound connectivity - i.e. a subnet where the routing table does NOT have an entry for:
0.0.0.0/0 igw-4d4b212a
If you want to restrict access from your EC2 instance to specific IP addresses, put your NAT in the public subnet, create a private subnet, and put your instance in the private subnet. Then add the two routes to the route table associated with the private subnet:
45.63.64.111/32 nat-00bb49204627de7e6
144.202.71.30/32 nat-00bb49204627de7e6
If you simply want to restrict access of your EC2 instance to a couple of IP addresses, you can only create routes for those addresses:
45.63.64.111/32 igw-4d4b212a
144.202.71.30/32 igw-4d4b212a
Be aware that with this last option, your instance can be reached from the internet if you have rules open in your security groups.
I working on aws. I created a public subnet which has a network ACL allows all net traffic, and associated with a internet gateway in the route table.
And then I create a ec2 instance without elastic ip and a ec2 instance with elastic ip in it, and the security group also allows all traffic.
I ssh to the instance which has elastic ip. It works well when I run yum update and curl www.baidu.com and so on. But I can't access internet when I ssh to the ec2 instance which has no elastic ip. anyone knows that is why?
For accessing internet from EC2 instance in public subnet using Internet Gateway, the instance needs to have public IP address. Either one can configure the instance to have public IP address or attach EIP.
Reference: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html
If you do not want to attach public IP address for instances with Internet access (consider private subnets), NAT instance and NAT gateway can help.
Reference: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat.html
As well as being in a subnet that has a route to an Internet gateway, an instance must have a public IP address to communicate with the outside world (this is distinct from an elastic IP).
You can specify this when launching an instance, if not there is a per subnet setting that controls this. The per subnet setting defaults to false other than default subnets in your default VPC. There are more details in the aws docs.
The problem lies with the gateway connected to the subnet you are using. To check the gateway you are using:
Go to the subnet you are using
Click on the Route table
Under Routes -> Destination look for 0.0.0.0/0 and check the gateway you have for it under Target
Here's how the gateways behave:
Internet Gateway (IGW) allows instances with public IPs to access the internet.
NAT Gateway (NGW) allows instances with no public IPs to access the internet.
This is a good article to help you understand and solve your problem:
https://medium.com/awesome-cloud/aws-vpc-difference-between-internet-gateway-and-nat-gateway-c9177e710af6
I'm putting the instances behind the aws loadbalancer, I have configured the routable and attached the IGW to it, created the loadbalancer and added this instance to the aws loadbalancer every things work well, the endpoint URL of the AWS loadbalancer able to load the HTTP pages
Now i have removed the IGW from the route table and tested it again, the AWS loadbalalncer endpoint URL not able to load the page, but the instace status shows in AWS loadbalancer as inService
Why the IGW is required when loadbalancer is configured over private subnet, it technically Mean it's a public subnet, which is blocking me to create a NAT inatance
A subnet without a default route pointing to the igw-xxxxxxxx Internet Gateway object is, by definition, a private subnet. If you remove the igw from a public subnet, you now have a private subnet.
Placing an Internet-facing load balancer (ELB) in such a private subnet is incorrect.
It sounds as though you are making a commonly-made -- but incorrect -- assumption that the ELB should be configured in the same subnets as the instances behind it. This is also incorrect.
Provision the ELB in public subnets, without regard to the subnets the instances behind it were placed in.
In summary:
Internet-facing ELB requires a public subnet for placement.
NAT instance requires a public subnet for placement.
The instances that use these services (NAT and ELB) belong in different -- private -- subnets, different subnets than the ELB and NAT instances.
ELB and NAT can be placed together in the same subnets, or separately, as long as the subnets are public (have the IGW as their default route) and are in the same availability zones.
I believe you cannot do anything without the IGW attached to the routing table where the subnet is attached to.
Another way to do this is to spin off a NAT instance(can be found in AWS marketplace) in the public subnet, add it to your private route table where your original instance is on (0.0.0.0/0 - instanceid) all the traffic will be routed through the NAT instance.
Here mainly we have to see two things, provided subnet for the elasticloadbalancer is public or private.
Every VPC should have one IGW to connect to the public, every trafic should go through the IGW only. If VPC connected to the IGW, IGW distribute internet to the all instance which are in that VPC, if route table changed to the particular rt, internet traffic can send to only that instance. Here in ELB instance is in service because both are in the same VPC and can communicate each other means checks the status. This IGW will work main role when we are using the NAT.
Always we provide ip range for the IGW or rt as 0.0.0.0/0, it represents as public.
The following link will explain more : http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html
This small explanation might be helpful for someone.
Let me cover your two questions
the AWS loadbalalncer endpoint URL not able to load the page, but the instace status shows in AWS loadbalancer as inService
This is the default behaviour of load balancer , since internally load balancer and your instance may be in the same VPC so they are able to communicate that is why loadbalancer is showing inService status.
Second question Why the IGW is required when loadbalancer is configured over private subnet, it technically Mean it's a public subnet, which is blocking me to create a NAT inatance
You need IGW if you want to access any resources especially EC2 , Loadbalancer from internet. however if you put your load balancer in private subnet it means IGW is not associated with the subnet having loadbalancer in it and hence this load balancer is not accessible outside your VPC that is reason that you were not able to load your page.
NAT instance is usually used when you want your private subnet instances should be able to initiate request over internet and has nothing to do with normal load balancing setup unless and untill you want dont want to install any updates from internet to your instance.
You are trying to access webpage publicly and removing the route entry IGW from the loadbalncer subnet.
The Subnet without IGW will become Private, Hence you can't access it.
First, a subnet with route table that route traffic via the internet gateway (IGW) is a public subnet. An IGW is required because the subnets created in AWS VPC are internal IPs and as internal IPs are not routable via the internet, traffic to and fro EC2 instances that belongs to an internal IP needs a way to complete these request. This is where an IGW comes into play. The IGW allows your EC2 instance to make outbound request to the internet and allows other user/client to make inbound request to your ec2 instance.
A public subnet are group of IPs (called subnets) in your VPC that allows internet traffic to and fro your ec2 instance. A subnet without an Internet gateway is a private subnet. As you already guess no traffic is allowed in or out.
That said, instances in VPC which are in Private subnet still need to initiate an outbound request to the internet to download software or perform update. In this case you have to create and attach a NAT gateway or NAT instance to the private subnet. NAT Gateway and NAT instance only allow outbound traffic to the internet but not the the other way round. In some cases you might want your production EC2 to be in the private subnet and ELB in public subnet for security reason.
ELB usually belong to the public subnet so it reachable from the internet as is your case as well.
TO answer some of your question - when you deleted the IGW from the route table, your ELB automatically becomes a private subnet as such your web page stops loading.
Also, you could still see the ec2 instance behind the ELB as InService even when you deleted the IGW because the ELB and EC2 instance can communicate via the internal IP as they are in same network or VPC.
The ELB needs a route to the internet in order to send you the response over internet.. As simple as that.
Configure your ELB in public subnet, regardless of where your instances are present.
Basically there are two types of load balancers.
1)Internal
2) External
Internal load balancers are those which are launched in a private subnet which will be accessible only internally by the instances on same vpc of the internal elb
External load balancers are which are accessible over the internet which should be launched in a subnet which has internet gateway attached to it and which has route table configured properly to route the requests.
If you attach an internet gateway to a subnet it becomes a public subnet.Also if you create a load-balancer which you need to be accessible from internet it should be a External load balancer and aws will not allow it launch in a private subnet.The instances are showing in service because its communicating internally using private ip-address.