I have a VPC over EC2 and two Ubuntu 22.04 VMs.
I created a simple straight forward traffic-mirroring session, according to this manual.
But traffic does not gets replicated into destination.
My mirror targets is the interface of vm1
My mirror filters are "all protocols" source+dest CIDR 0.0.0.0/0
My mirror sessions combines both the above mirror-target and mirror-filter, and source as the interface of vm2
On vm2 I use wget in order to produce traffic on that interface.
On vm1 I use tcpdump, but I do not get any traffic mirrored from vm2.
I did not find any way to debug this.
Well,
Looks like I missed that part from Prerequisites 😅
The traffic mirror target instance must allow traffic to UDP port 4789.
I had to allow UDP port 4789 (vxlan) on the targer's security groups.
Related
I have created a new free-tier windows 2019 EC2 instance in my default VPC, the new EC2 has a public IP, and the security group allows the traffic from anywhere and the RDP protocol is already configured to be ready on port 3389.
I have spent two days now with no luck connecting to this instance from windows remote desktop.
I have tried to ping the ec2 from my machine but no luck.
telnet from my machine to the ec2 working perfectly.
I have disabled the windows firewall.
remote desktop sometimes asks me to enter the password and sometimes doesn't ask at all.
**** when I changed my wifi network, I do the remote desktop connection and I can access the ec2 instance.
Any help in this.
I had the same issue as you have. In my case, The internet service provider blocked the SSH connection(PORT). though our security group allows to all we can't connect our instance.
Take this to them and get it fixed:).
I have a windows machine in EC2 which works, with the security groups set up as follows:
Inbound RDP, TCP port 3389 from 0.0.0.0/0
Inbound All ICMP v4 from 0.0.0.0/0 <- This is necessary to ping the machine
Outbound All traffic, All protocols, all ports to 0.0.0.0/0
Outbound ALL traffic, All protocols, all ports to ::/0
A few more hints:
If you restarted the machine and haven't attached an elastic IP, the public IP address will have changed
You can try telnetting to the RDP port 3389
Run the reachability analyzer tool in the VPC management console
You can try connecting via a different computer or a different connection, e.g. a personal hotspot to rule out firewall issues on your side
Update:
RDP is a quite ressource-intensive protocol compared to e.g. ssh or telnet. You haven't specified if you are trying this from a home or corporate network. Could the quality of your internet connection be a problem? Comparing to e.g. a public or private hotspot might help.
Last but not least, you say it worked when you "changed your wifi network" - I'm not quite sure what to make of that statement. Did you change the configuration? Did you change TO your wifi from a wired network?
If you are in a high-density area, Wifi networks can strangle each other. If you always were wireless, try wired. If your wireless works better than your wired, check the cables for kinks and tears.
Colleagues of mine once spent an hour trying to find out why a mainboard would always go into flash mode, until I suggested unplugging the keyboard - it was a stuck F10 key. Bottom line: try to think of the factors you've so far overlooked.
You probably need to setup your inbound rules on the security group.
Go to Instances and find the value for the column: Security Group Name
Then under Network and Security go to Security groups.
Click on the Security group ID that has the matching Security Group Name you looked up.
In the inbound rules you need to make sure you add yours and modify it until it looks like this:
Type: RDP Protocol:
TCP Port: 3389
Source: 0.0.0.0/0
Description: open to the world to test only
Better would be to use a source that you know you are coming from, but you'll need to change it if your IP changes.
https://www.whatismyip.com/
if your IP is 17.18.19.20,
then enter 17.18.19.20/32
I have created an EC2 (Windows) instance on AWS. I want to run a TCP server on this EC2 on TCP port 7889
and want to connect to it from outside world.
I have edited the inbound traffic rule in security group and added TCP rule for 7889 from anywhere.
But unfortunately my TCP client socket can not reach the server through the public ip of the EC2 instance.
Please help.
Note: The same thing worked for me few years ago. My little search has shown me few things like , I need to create VPC, public and private subnets, internet gateway and route tables.Is it true? All these were not required earlier.Is it a new addition?
Yes all you mentioned are absolutely needed. VPC, Subnet, Route table, Internet Gateway and EIP all are required.
The reason it worked for you previously because you might have used the default VPC with all other components already configured. Even now you will be having a default VPC in every AWS region which you can make use of it.
But it's really needed to have basic understanding of how things connect and work together because all these components are very basic and important. Refer AWS documents for more details.
If all the components are cofigured already, check the output of
netstat -nptl
command. The port 7999 should be available and it should be ready to accept any IP (i.e. point to 0.0.0.0)
Thank you for the responses. It was windows internal firewall as #Marcin suggested.
Everything works now.
I've got an AWS VPC set up with 3 subnets - 1 public subnet and 2 private. I have an EC2 instance with an associated Elastic Block Store (the EBS contains my website) running in the public subnet, and a MySQL database in the private subnets. The security group attached to the EC2 instance allows inbound HTTP access from any source, and SSH access from my IP address only. The outbound security rule allows all traffic to all destinations. The security group associated with the database allows MySQL/Aurora access only for both inbound and outbound traffic, with the source and destination being the public access security group.
This has all been working perfectly well, but when I came to setting up the NACLs for the subnets I ran into a snag that I can't figure out. If I change the inbound rule on the public subnet's NACL to anything other than 'All Traffic' or 'All TCP', I get an error response from my website: Unable to connect to the database: Connection timed out. 2002. I've tried using every option available and always get this result. I'm also getting an unexpected result from the NACL attached to the private subnets: If I deny all access (i.e. delete all rules other than the default 'deny all' rule) for both inbound and outbound traffic, the website continues to function correctly (provided the inbound rule on the public subnet's NACL is set to 'All Traffic' or 'All TCP').
A similar question has been asked here but the answer was essentially to not bother using NACLs, rather than an explanation of how to use them correctly. I'm studying for an AWS Solutions Architect certification so obviously need to understand their usage and in my real-world example, none of AWS' recommended NACL settings work.
I know this is super late but I found the answer to this because I keep running into the same issue and always try to solve it with the ALL TRAFFIC rule. However, no need to do that anymore; it's answered here. The Stack Overflow answer provides the link to an AWS primary source that actually answers your question.
Briefly, you need to add a Custom TCP Rule to your outbound NACL and add the port range 1024 - 65535. This will allow the clients requesting access through the various ports to receive the data requested. If you do not add this rule, the outbound traffic will not reach the requesting clients. I tested this through ICMP (ping), ssh (22) http (80) and https (443).
Why do the ports need to be added? Apparently, AWS sends out traffic through one of the ports between 1024 and 63535. Specifically, "When a client connects to a server, a random port from the ephemeral port range (1024-63535) becomes the client's source port." (See second link.)
The general convention around ACLs is that because they are stateless, incoming traffic is sent back out through the mandatory corresponding port, which is why most newbies (or non hands on practitioners like me) may miss the "ephemeral ports" part of building custom VPCs.
For what it's worth, I went on to remove all the outgoing ports and left just the ephemeral port range. No outgoing traffic was allowed. It seems like either the ACL still needs those ports listed so it can send traffic requested through those ports. Perhaps the outgoing data, first goes through the appropriate outgoing port and then is routed to the specific ephemeral port to which the client is connected. To verify that the incoming rules still worked, I was able to ssh into an EC2 within a public subnet in the VPC, but was not able ping google.com from same.
The alternative working theory for why outgoing traffic was not allowed is because the incoming and matching outgoing ports are all below 1024-63535. Perhaps that's why the outgoing data is not picked up by that range. I will get around to configuring the various protocol (ssh, http/s, imcp) to higher port numbers,, within the range of the ephemeral ports, to continue to verify this second point.
====== [Edited to add findings ======
As a follow up, I worked on the alternate theory and it is likely that the outgoing traffic was not sent through the ephemeral ports because the enabled ports (22, 80 and 443) do not overlap with the ephemeral port range (1024-63535).
I verified this by reconfiguring my ssh protocol to login through port 2222 by editing my sshd_config file on the EC2 (instructions here. I also reconfigured my http protocol to provide access through port 1888. You also need to edit the config file of your chosen webserver, which in my case was apache thus httpd. (You can extrapolate from this link). For newbies, the config files will be generally found in the etc folder. Be sure to restart each service on the EC2 ([link][8] <-- use convention to restart ssh)
Both of these reconfigured port choices was to ensure overlap with the ephemeral ports. Once I made the changes on the EC2, I then changed the security group inbound rule, removed 22, 80 and 443 and added 1888 and 2222. I then went to the NACL and removed the inbound rules 22, 80 and 443 and added 1888 and 2222. [![inbound][9]][9]For the NACL, I removed the outbound rules 22, 80 and 443 and just left the custom TCP rule and add the ephemeral ports 1024-63535.[![ephemeral onnly][10]][10]
I can ssh using - p 2222 and access the web server through 1888, both of which overlap with ephemeral ports.[![p 1888][11]][11][![p2222][12]][12]
[8]: https://(https://hoststud.com/resources/how-to-start-stop-or-restart-apache-server-on-centos-linux-server.191/
[9]: https://i.stack.imgur.com/65tHH.png
[10]: https://i.stack.imgur.com/GrNHI.png
[11]: https://i.stack.imgur.com/CWIkk.png
[12]: https://i.stack.imgur.com/WnK6f.png
I have two projects on google cloud. First one has been set up 15 hours ago and working fine, port 8080 is expose properly and i can access it.
Right now i'm trying to do absolutely the same with another project. I've created the same instance of vm in there with the same configs, entered the same commands using ssh connection. But i can't connect app to this server.
I've tried to create another instance of the vm on first project and it works, but whatever i create on the second project - i can't get access to it.
I assume, something wrong with the project configs, and therefore no details about VM's contents are provided.
TL;DR - Double check and compare your firewall rules in both the projects. You're most likely missing firewall rules to allow incoming traffic to port 8080 on your instances in the project where it is not working, whereas the other project has these rules configured.
Default Firewall rules
Google Compute Engine firewall by default blocks all ingress traffic (i.e. incoming network traffic) to your Virtual Machines. If your VM is created on the default network (which is usually the case), few ports like 22 (ssh), 3389 (RDP) are allowed.
The default firewall rules are described here.
Opening ports for ingress
The ingress firewall rules are described in detail here.
The recommended approach is to create a firewall rule which allows incoming traffic to your VMs (containing a specific tag you choose) on port 8080 . You can then associate this tag only to the VMs where you will want to allow ingress 8080.
The steps to do this using gcloud:
# Create a new firewall rule that allows INGRESS tcp:8080 with VMs containing tag 'allow-tcp-8080'
gcloud compute firewall-rules create rule-allow-tcp-8080 --source-ranges 0.0.0.0/0 --target-tags allow-tcp-8080 --allow tcp:8080
# Add the 'allow-tcp-8080' tag to a VM named VM_NAME
gcloud compute instances add-tags VM_NAME --tags allow-tcp-8080
# If you want to list all the GCE firewall rules
gcloud compute firewall-rules list
Here is another stack overflow answer which walks you through how to allow ingress traffic on specific ports to your VM using Cloud Console Web UI (in addition to gcloud).
Operating System level firewall rules
Since you have not mentioned if you're using any of the public Google Compute Engine images or Container-Optimized OS images or a custom image of your choice, I also wanted to mention that even if you configure GCE firewall rules to allow incoming traffic to reach your VM, your OS level firewall could still very well reject the traffic.
Google's Container-Optimized OS images have this feature turned on where it blocks all ingress ports except for port 22 (SSH).
I'm trying to access Tensorboard on AWS. Here is my setting :
Tensorboard : tensorboard --host 0.0.0.0 --logdir=train :
Starting TensorBoard b'39' on port 6006 (You can navigate to
http://172.31.18.170:6006)
AWS Security groups (in):
HTTPS TCP 443 0.0.0.0/0
Custom_TCP TCP 6006 0.0.0.0/0
However connecting to ec2-blabla.us-west-1.compute.amazonaws.com:6006 I can't see anything, I basically can't connect.
Do you have any idea?
You can use ssh tunneling technique.
In your terminal:
ssh -i /path/to/your/AWS/key/file -NL 6006:localhost:6006 user#host
where:
user and host: your aws ec2 user and instance specific.
-N: don't execute a remote command (just forward ports)
-L: [bind_address:]port:host:hostport
After that, browse to http://localhost:6006/
Run tensorboard in your ec2 terminal (you can custom logdir and port)
tensorboard --logdir=data/model --port=8080
Find your workstations public ip (a.b.c.d) address by visiting http://ip4.me/
Access the security group configuration assigned to your EC2 and add a custom TCP rule to your inbound traffic.
Outbound should be set to allow traffic from tensorboard port. (In this case 8080). Or you just allow all outgoing traffic from your EC2 instance
Protocol Port Range Destination Description
All traffic All All 0.0.0.0/0
Use your public DNS to access tensorboard from your workstation
http://ec2-xx-xxx-xx-xx.compute-1.amazonaws.com:8080/
Fast (but unsecure) solution:
Run:
tensorboard --logdir=/training --host=0.0.0.0 --port=8080
on your AWS instance.
Make sure that both your inbound and outbound rules on AWS console (control center) are as unrestricted as possible (allow all types, all ports etc.). However, keep in mind that this solution is not recommendable for environments requiring security (in our case, we didn't consider security for training an NN).
An attempt to explain why this works: when the policy is set as described, AWS still seems to prohibit inbound/outbound connections on the standard tensorboard port 6006. This does not seem to apply to the port 8080.
Long (but more secure) solution:
See: https://blog.altoros.com/getting-started-with-a-cpu-enabled-tensorflow-instance-on-aws.html
(provides explanations for setting ports correctly on AWS)
I managed to set it up like this:
Go to security groups in your ec2 console:
Choose the relevant security group in the table, click edit.
Add a rule like this:
Start tensorboard: tensorboard --logdir tf_summary/ --port 8080
Find out the URL of your instance and visit http://yourURL:8080
Simply run the tensorboard without the host parameter (which poses restrictions)
tensorboard --logdir XXX --port 6006
I suffered from the same problem for several days.
Fortunately I solved this issue by adding rule on "AWS Outbound rule" as if I had added "AWS Inbound rule".
Regardless of this setting, it works at home.
The same error is still happening only in the company.