I was able to connect my private Ec2 instance to the internet through NAT instance.
wget google.com was successful.
But when I attached a NACL to my private subnet.I wasn't able to connect to the internet.Can anyone please tell me what is wrong with my NACL.
10.0.1.0/24 and 10.0.2.0/24 are CIDRs of public subnet(which has the NAT instance)
private NACL inbound rule
private NACL outbound rule
Also, when I add rule to accept all traffic from internet.It works. Is it correct practice to add this rule ?
Based on the comments.
The issue was due to blocking inbound internet traffic (0.0.0.0/0). From the Instances cannot access the internet in AWS docs, to enable internet access of the instance using NAT, the following must be ensured:
Ensure that the network ACLs that are associated with the private subnet and public subnets do not have rules that block inbound or outbound internet traffic. For the ping command to work, the rules must also allow inbound and outbound ICMP traffic.
Question from comments:
But just one question how will whitelisting work in this case. If I only want to download certain libraries using the internet and not allow any api requests ?
If you know IP ranges of the public servers that these libraries are going to be downloaded from, then you could limit the internet traffic to only these ranges. But if the range is not fixed or unknown you have to allow all (0.0.0.0/0) internet traffic in the rules.
Generally, security groups are used as primary way of controlling network traffic. NACLs are good due to their their denying ability. Security groups can't explicitly deny traffic, thus NACLs are helpful in cases where you want to explicitly deny some IPs. But in your case, you are allow only traffic. Thus I think the use of default NACLs would be sufficient and could be considered.
Related
I'm using gitlab.com as my repository and I'm hosting my own gitlab runner in my own VPC in AWS. This is working fine however, I would like to add some additional layer of security by tightening my NACL to only allow the gitlab.com SaaS to reach my VPC.
Their own documentation states that it should work and list a few ip ranges used by them and cloudflare. However, it still isn't working. It is obvious that it is the NACL because simply adding 0.0.0.0/0 as and allow in the inbound makes the runner job complete as intended. However, removing 0.0.0.0/0 and only allowing the ip's listed below makes the gitlab job get stuck and it behaves as if no connection is established.
34.74.226.0/24
34.74.90.64/28
173.245.48.0/20
103.21.244.0/22
103.22.200.0/22
103.31.4.0/22
141.101.64.0/18
108.162.192.0/18
190.93.240.0/20
188.114.96.0/20
197.234.240.0/22
198.41.128.0/17
162.158.0.0/15
104.16.0.0/13
104.24.0.0/14
172.64.0.0/13
131.0.72.0/22
2400:cb00::/32
2606:4700::/32
2803:f800::/32
2405:b500::/32
2405:8100::/32
2a06:98c0::/29
2c0f:f248::/32
After having added all these ranges to my NACL as inbound rules. It still is unable to connect without allowing 0.0.0.0/0.
Additional information
Here is an overview of my VPC setup:
The public subnet NACL has all the ips listed above as allowed, on all ports for all protocols on inbound connections. The outbound is currently set as 0.0.0.0/0.
The private subnet allows 0.0.0.0/0 for both inbound and outbound.
I seemed to have solved the issue. The problem was that I had not added an allow in the NACL for local connections. Hence the private subnet was unable to connect to the NAT gateway.
I have
two public subnet which has one NAT EC2 instance and one bastion host
one private subnet which has one EC2 instance
I am able to ping google.com from my bastion host but I am unable to do so from my private EC2 instnace.I have checked all steps mentioned here:-
https://aws.amazon.com/premiumsupport/knowledge-center/ec2-internet-connectivity/
I think the problem is with my NACL.
INBOUND RULES OF THE NACL ATTACHED TO THE PRIVATE SUBNET
OUTBOUND RULES OF NACL ATTACHED TO THE PRIVATE SUBNET
Pinging google.com works in case I detach the NACLS from private subnet. Please verify these NACLS
NOTE: - 10.100.3.0/24 and 10.100.0.0/24 are the CIDRs of my public subnet
Your outbound NACL rules are blocking all traffic except those destined to have a final destination of 2 private IP ranges.
Whilst the NAT might be in these subnets, the target is not, you should allow any IP ranges you want to be able to speak out to.
The NACL is stateless. That means you have to open the respective protocol and ports for outgoing requests and you also need inbound rules for the return traffic of outgoing requests. To allow a response to outgoing ping requests, it must allow inbound ICMP traffic. If you want to send HTTP/S requests, you must allow inbound traffic on the ephemeral ports on TCP.
You can learn more about Network ACLs and ephemeral ports here.
I read about aws VPC and try to find any sense to use NAT. If I understand correctly, NAT is used when we have VPC with two subnets: public and private. And if we want to allow private subnet make requests to global network (for example for software updates), but block all inbound traffic - we can setup NAT in public subnet and connect this NAT with private subnet.
But in the same time we can just create ACL for private subnet and block all inbound traffic. So, it would be able to download software updates if it need.
So, if all above is true, why do we need NAT?
A Network Access Control List (NACL) is stateless. This means the rules are enforced in both directions. Thus, in your scenario, traffic would be blocked in both directions.
In general, there should be no need to use a NACL. There are some appropriate uses (such as creating a DMZ), but these are rare.
You could, if you wish, put everything in a public subnet and simply use Security Groups to control access. This would work well because inbound and outbound rules can be configured separately. However, many people like the traditional concept of a private subnet to give an added sense of security.
I am very new to AWS and networking. I have been playing with network ACL. I realized that if I don't allow outbound port 443 (HTTPS) on the network ACL, I wouldn't be able to use a browser to go to https://www.google.com from within the EC2 instance in the subnet associated with this ACL.
Likewise, if I don't allow outbound port 80, I wouldn't be able to go to http://www.cnn.com.
This confused me. When I allow port 80 outbound on the ACL, am I allowing the EC2 to talk to port 80 on the CNN server, from an ephemeral port on my EC2, or am I allowing the EC2 to initiate a connection from port 80 on the EC2?
use the security groups at instance level to have security at instance level.And unlike security group, ACL is stateless and works at subnet level i.e if you want your instances to communicate over port 80(http) then you have add an inbound and outbound rule allowing port 80.
You don't have to add any rules. The default network ACL is configured to allow all traffic to flow in and out of the subnets to which it is associated. Each network ACL also includes a rule whose rule number is an asterisk. This rule ensures that if a packet doesn't match any of the other numbered rules, it's denied. You can't modify or remove this rule.
Rules allow all IPv6 traffic to flow in and out of your subnet. We also add rules whose rule numbers are an asterisk (Catch All) that ensures that a packet is denied if it doesn't match any of the other defined numbered rules.
A network ACL has separate inbound and outbound rules (Stateless), and each rule can either allow or deny traffic.
Out Bound Rules allow outbound traffic from the subnet to the Internet. In other words it is matching the traffic flow with the defined rules in the ACLs list and apply it (ALLOW/DENY).
If you have private instances that should not be accessible by public users in the internet it is best practice from security point of view to place these instances in a private subnet and use NAT instance in a public subnet and make all traffic flow goes through this NAT instance to make patch updates and get the public access.
For more information, Check Amazon Docs
I have 2 AWS instances, i-1 and i-2. They are each on a different security group: sg-1 and sg-2, respectively. Both machines have elastic IPs.
sg-2 is configured to allow all traffic from sg-1, regardless of port, source IP or protocol.
When i-1 tries to talk to i-2 its traffic is being blocked. It seems AWS doesn't account for the fact that i-1's traffic is actually coming from its elastic IP.
Is this expected? Is there anything I can do to work around it, apart from manually adding i-1's elastic IP to sg-2?
sg-2 is configured to allow all traffic from sg-1
When you do this, only traffic from Private IP address is allowed. However, as you as using EIP, you explicitly need to allow traffic from that ip address.
Read this: https://forums.aws.amazon.com/thread.jspa?messageID=414060
Quoting from above link:
Out of curiosity, are you perhaps connecting using a public IP address? When you use a rule with a security group as the source, it will only match when connecting over the internal network. The private IP address can change though. If you have an Elastic IP associated with the instance, the public DNS name happens to be static and will always resolve to the current private IP address when used from within the same EC2 region. That allows you to easily connect internally without worrying about any address changes.
You haven't really provided enough information to diagnose the problem, but there are a few things to check:
Is I-1 definitely in SG-1? If you've got the instances muddled, the SG rules would be around the wrong way.
Does the machine in SG-2 have a firewall running that might be blocking incoming traffic even though the SG rules are allowing it?
You've tagged this with the VPC tag - do you have any network ACL settings that might be preventing traffic flow? Are the machines private, using a NAT appliance to get out to the Internet, or public, routing through the standard AWS gateway? Can I-1 see the Internet? If you're routing through a NAT, assigning an EIP to a machine effectively cuts it off from the Internet because EIP and NAT are mutually incompatible, and although I haven't tried it this might also screw up SG routing.
Does SG-1 have any egress rules that might be preventing traffic from leaving?
The answer to your question is likely to be found in the resolution of one of these questions if the answer to any of them is 'Yes'.
As previously stated by slayedbylucifer, you will need to explicitly allow traffic from the EIP.
Here's the reasoning from the official AWS documentation about Security Groups:
When you specify a security group as the source for a rule, traffic is allowed from the network interfaces that are associated with the source security group for the specified protocol and port. Incoming traffic is allowed based on the private IP addresses of the network interfaces that are associated with the source security group (and not the public IP or Elastic IP addresses).