- Newest
- Most votes
- Most comments
I see, so basically we are looking t the below:
ACL Inbound - Allow all ACL Outbound - Allow all
Security Groups Inbound - Allow port 500 only Outbound - Allow all
Would this be the most secure approach which still allows me to telnet?
Yes, I don't think there is a need to control it with network ACLs if it can be controlled with security groups.
As a best practice for VPC, we recommend using network ACLs to manage communication, but the disadvantage is that network ACL management becomes difficult when communication becomes complex.
If you can tolerate these disadvantages, I think you may want to set up a network ACL.
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html
Hello.
Is port 500 allowed on the firewall of the "192.168.1.1" machine?
Also, is there any firewall device that prevents access to port 500 of "192.168.1.1" during the communication route?
Hi Riku,
So l allowed all incoming traffic and now l am able to telnet.
Initial setup was l had allowed all outbound traffic and had only allowed specific port i.e 500 in the acl and security groups.
What could l have done wrong here, grateful for your guidance. :)
ACLs are not stateful where security groups are. So even though you may allow outbound on port 500 in your NACL, youll also need create an appropiate inbound rule too for the return traffic
Thanks Riku for your response.
Can confirm that there are not firewall devices and yes 500 is allowed.
I am also just concerned how l cannot not telnet google.com 80 which should naturally work.
Thanks Riku,
The EC2 instance is in a private subnet.
EC2 -> customer gateway -> site to site vpn -> 192.168.1.1
What puzzling is l can ping, but its only telnet failing.
I do not have NAT configured
Hope the above addition info is helpful
I did request, however the customer highlights that other people are able to connect without challenges. so that route is proving a bit difficult.
Also not sure if this will help, I have a default internet gateway setup which is why l can ping google.com. But failing to telnet to google.com 80 is probably the same reason why l am failing to telnet to the client.
Hello Riku and Gary,
Thanks both for your reponses, appreciated.
To be more specific:
Initial setup was, l had allowed all outbound traffic and with regards to inbound traffic, l had only allowed the specific port i.e 500 in the acl and security groups.
The change l did was to allow all inbound which is obvisouly not secure. Its almost as if, if l allow only port 500 in the inbound, telnet doesnt work.
Kindly guide what l could be missing here.
Thank Riku,
So if l get you correctly, my config should be something like below:
ACL Inbound - Allow ports "1024 to 65535" Outbound - Allow all
Security Groups Inbound - Allow port "500" only Outbound - Allow all
Thanks again for your responses
I see, so basically we are looking t the below:
ACL Inbound - Allow all ACL Outbound - Allow all
Security Groups Inbound - Allow port 500 only Outbound - Allow all
Would this be the most secure approach which still allows me to telnet?
Relevant content
- asked 2 years ago
- asked 2 years ago
- asked a year ago
AWS OFFICIALUpdated 3 years ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
"google.com" is a public domain, so routing to the public network is required. Is there a route to communicate from your EC2 to the public network? For example, if EC2 is running in a private subnet, a NAT Gateway is required. You can also access the public network via on-premises, but even in this case you will need to configure NAT within the on-premises network.
By the way, are there any routers that perform NAT in the middle of the communication route? If you are using NAT, you will need to allow not only IKE on port 500, but also port 4500. Also, configure NAT traversal if a NAT router is on the route.
Is it possible to do a packet capture on the "192.168.1.1" machine? Please check how the Telnet log is output as a result of packet capture. For example, if there are no access logs to port 500, it may be blocked somewhere along the communication route.
I'm glad that you were able to successfully telnet. As @Gary Mclean says, network ACLs are stateless settings, so if you don't allow proper inbound and outbound communication, the connection will fail. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-basics
The inbound traffic in the network ACL is return traffic from "192.168.1.1", so the allowed port numbers should be different. Since the network ACL inbound rule is return traffic, please allow ephemeral ports "1024 to 65535".