Network ACLs settings for VPC Endpoints

0

I think we have to create folloing network ACLs for S3 VPC Endponts(Interface type), but could not access to S3(timeout).

  • outbound: port=443, destination=0.0.0.0/0
  • inbound: port=1024 - 65535, source=VPC-CIDR (ephemeral

I added folloing network ACL and could access to S3!! Do you have any idea why do you need folloing settings?

  • inboud: 443, source=VPC-CIDR
  • outbound: 1024 - 65535, destination=0.0.0.0/0(ephemeral
2 Answers
2
Accepted Answer

Hi there,

Network ACL (NACL) is VPC component that works at subnet level which filters traffic between subnets(inter-subnets) and is Stateless by design - as compared to Security Groups which are Stateful so any traffic allowed in any direction will be allowed to return. So that means that you have to specify allowed traffic rules in both directions (in/outbound). For example you can check here for more detailed information(1).

So as you explained that you created VPC Endpoint(Interface type) for S3 service and with below rules for NACL associated with the Subnet of that VPC Endpoint ENI:

  • outbound: port=443, destination=0.0.0.0/0
  • inbound: port=1024 - 65535, source=VPC-CIDR (ephemeral)

With this rules in place on NACL, any client(eg: EC2 intances) from other subnets in the same VPC won't be able to connect because access from other subnets needs TCP 443 allowed for inbound on this NACL for VPC Endpoint subnet(let's call this SubnetB). But if the source is within the same subnet NACL doesn't come into picture and only Security Groups is relevant to this traffic, so presumably Security Group has allowed TCP 443 from 0.0.0.0/0 or VPC_CIDR.

To explain further lets have below example:

VPC_A(10.0.0.0/16) has two subnets - SubnetA(10.0.0.0/24)(ec2 instances/clients) and SubnetB(10.0.1.0/24)(VPC Interface Endpoint for S3). SubnetA is associated with NACL_A and SubnetB is associated with NACL_B. So if we use above rules for NACL_B then Traffic flow is as below:

EC2(10.0.0.10) ----> VPC Interface Endpoint for S3 ENI(10.0.1.10) since this traffic is actually between subnets then traffic is seen like below for NACL point of view:

SubnetA ----> SubnetB | Assuming that traffic is allowed from/to SubnetA if we take a close look at NACL rules for SubnetB. Traffic is incoming from SubnetA so we first look at Inbound:

-inbound: port=1024 - 65535, source=VPC-CIDR (ephemeral) ---> By this rule TCP 443 incoming is not allowed, so it will be denied.

So let's see the working scenario:

-inbound: 443, source=VPC-CIDR ----> By this rule TCP 443 traffic from SubnetA will be allowed to SubnetB, because the source IP address will be matching VPC_CIDR as well as the destination port TCP 443. Note: As for TCP session source selects ephemeral ports to initiate a session to a destination so source will choose a port from 1024 to 65535 range, let's say in this case port 22222 for example. Source is 10.0.0.10:22222 and destination is 10.0.1.10:443.

Looking at the return traffic:

-outbound: 1024 - 65535, destination=0.0.0.0/0(ephemeral) - Now the return traffic is from SubnetB to SubnetA ( VPC Interface Endpoint for S3 ENI to EC2 instance in Subnet_A). Destination is 10.0.0.10:22222 and source is 10.0.1.10:443, so by this rule this traffic is allowed, destination IP and port matches the specifics on rule.

Just to give more clarity into the context NACL_A is presumed to have below rules or similar to below:

  • inbound: TCP 1024-65535, source 0.0.0.0/0 or VPC_CIDR
  • outbound: TCP 443, destination 0.0.0.0/0 or VPC_CIDR

Additionally, yes as mentioned above Reachability Analyzer is great tool to troubleshoot connectivity issues like this and it is greatly recommended.

(1) Network ACLs - Network ACL basics - https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-basics

Thanks Munkhbat

AWS
SUPPORT ENGINEER
answered 2 years ago
  • Thak you for your greate advice!! I totally understatnd why it is necessary. I didn't consider trafiic SubnetA to SubnetB!!

1

When you create a VPC endpoint for an AWS service the service will become available inside a VPC subnet. The internal DNS will translate the service urls to local subnet IP addresses.

NACLs are defined on a subnet. The NACL defines what can enter into the subnet and what can exit from the subnet.

Port 443 is the necessary port for accessing the S3 service.

When you are not leaving any subnet no NACL is involved in the traffic, only if you cross the boundary of a subnet NACLs will be checked.

So I presume the a subnet crossing is made during your tests. And that the NACL is defined on the subnet of the VPC Endpoint but you are calling the service from another subnet.

The subnet with the VPC Endpoint needs ingress 443 and ephemeral egress. The subnet where the service is called needs egress 443 and ephemeral ingress.

So my guess is that the subnet from where you are calling the S3 service already has egress 443 and ephemeral ingress.

If you share a bit more about the network details I can help figure out what is happening. Also a great tool to use is the Reachability Analyzer to inspect cases like this.

profile picture
JaccoPK
answered 2 years ago
  • than you for your help. It is realy helpful for me to understatnd NACL!!

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions