We have a site to site VPN connection from our AWS cloud to the customer's on site network. Our web application login requires the authentication from the customer's active directory and hence the need for VPN connection.
When our application is not being used for a while the VPN tunnel goes down, due to which when a user tries to log into the application he is unable to due to downed tunnel. It takes some time for the tunnel to get up after which everything works properly.
I had a call with the customer's IT people and it seems they have set up a keep alive bit (DPD settings) on their end but still the tunnel keeps going down. AWS support isn't much of a help either.
I google around and discovered that one way we can keep the tunnel alive is by "sending a ping to the target from the device sourced from the outside interface. A possible destination for the ping is an instance within the VPC"
AWS documentation also suggests "to create a host that sends ICMP requests to an instance in your VPC every 5 seconds."
I already have an private subnet EC2 instance (with only private IP) in my VPC.
My question is, do I need to create another ec2 instance in my VPC private subnet and ping the first one from the other every 5 seconds?
Would I need to write a shell script for this?
I am basically confused about from where to ping, whom to ping and how to ping.
Ping any remote AWS instance from your on-premise site, thereby causing traffic over the vpn. Just schedule it in windows task scheduler, and use the basic command line ping.
Related
I tried to connect to a running ec2 instance with my usual settings, it returns
ssh: connect to host ec2 port 22: Connection timed out
I tried to connect with the built-in "EC2 Instance Connect", to connect directly from the browser with the AWS account, it returns
There was a problem setting up the instance connection An error
occurred and we were unable to connect or stay connected to your
instance. If this instance has just started up, try again in a minute
or two.
The instance was running for weeks, I am the only user with access to the AWS account and the SSH Keys and I didn t change any setting in the last ~3 weeks or restarted it
1st the timeout started ~1 week ago, nand then without any other change, my website (wordpress) suddenly started to show a database connection error (the database in inside the EC2 instance as well)
What I used to connect :
Either
ssh -i "Keys.pem" ec2-user#ec2-[public ip].eu-west-3.compute.amazonaws.com
Or
ssh ec2-user#[public ip] -i "Keys.pem"
Both show the same error. I used the first one several weeks ago and it used to work well
This timeout will be caused by invalid security group rules.
Ensure that the security group rules attached to your instance allow inbound access from the source IP address you're trying to SSH from, the database connection may also be related to this.
If you're connecting using a dynamic public IP address to SSH to your host, you will need to adjust this every time your IP address changes. It might be more appropriate to setup a VPN so that you can connect privately to your host.
We have a very difficult problem here, we have a Windows Server 2019 Base x64 on Amazon EC2, connected through RDP and setup-ed forest and activated AD DS , also activated DNS. But whenever we try to connect we are not allowed to.
We have opened all the relevant ports on inbound traffic rules.
We have added users.
We have tried searching internet and various tutorials.
In Server Manager=:
Added the public ipv4 address to our ipv4 settings of the adapter.
Went to the computer setting in computer domain entered the domain but no fun.
Disabled the firewall in server manager.
We want to connect our clients on different network to connect to the server hosted else-where on AWS.
We are really new into this can some one guide through this?
Please make sure there is network connectivity between your client and you DC which is set up on EC-2 Instance.
[1] In case your clients are on AWS (meaning different EC-2 Instances), and in a different network, you need to create VPC peering or use Transit Gateway, so that it has proper network connectivity.
[2] In case your clients are not on AWS, and in an On-prem Environment, you need to have a VPN connection between your client and your DC.
So in Summary, you need to have network connectivity between your client and DC so that clients can join your Domain.
What do you mean whenever we try to connect we are not allowed to?
What are you trying to connect to, the Windows EC2 instance?
Are you saying that the instance is joined to AWS Directory Service domain but you can't connect to the instance using one of the users in your AWS directory?
Edit: This should have been a comment but couldn't post comments at the time of answering.
I created Ubuntu instance in EC2. And worked fine so far.
But somehow I can't connect to the server by PuTTy anymore and I get Network error: Connection timed out.
The instance is running in the console.
CPU uses just 2%.
InBound Setting seems no problem. SSH with 22 port.
Tried with the IP address and DNS.
restarted the instance and Tried.
Stopped and tried with different IP address.
Instance connection is fine.
This is the screenshot:
This is inbound rule:
How can I solve this problem?
A Connection timeout is a sign that your computer is unable reach the remote computer. Such an error normally takes some time before it fails.
If, instead, the remote computer rejected the connection, the error would appear immediately and the message would be Permission denied.
Things to check:
The Security Group on the EC2 instance needs to allow inbound SSH (port 22) access either from the whole internet (0.0.0.0/0) or, preferably, from a smaller CIDR range that includes your computer (eg choosing "My IP" in the console). This is typically the cause of the issue 80% of the time.
The instance needs to be in a Public Subnet, which means the subnet is connected to an Internet Gateway.
Your network must allow an outbound SSH connection to AWS. Some corporate networks might block this.
There are some other potential causes, but most of the time the cause is one of the above.
I have a load balancer and EC2 instance with AWS. I had problems with e-mail restrictions and was recommended to use an elastic IP. I then read somethere that you can't use elastic IP and a load balancer so I removed the elastic IP. I can no longer access my instance even when I've rebooted it and waiting 2 hours later. I can ping it (after enabling ICMP with network security) but I can't SSH or go to the web server. All the network settings remain, which included allowing TCP ports for HTTP and SSH. Does anyone know what has happened to make port 80 and 23 no longer accessible? This is a real nightmare for me because I did a bit of a marketing campaign, got increased traffic, noticed emails weren't getting sent, then in an attempt to fix that I've screwed the server completely so the website is down at the worst possible time :(
I fixed it all up. This isn't a direct solution to the problem, more like a workaround. I couldn't connect to that server no matter what, so I created a new instance and that worked. It was as if the Linux server itself was corrupt, not the AWS settings. I detached the volume from the old instance and attached it as a secondary volume on the new instance. When I logged into the new instance I was able to mount the secondary volume as a new drive and I just copied the files over that way. I don't have a bloated server so this wasn't really a big deal to pull off. Anyway, if you can't log in to a server anymore, you can always mount it to a new instance and access it via the file-system
I have created a VPC with public and private subnets on AWS. All app servers are in private subnets and all outbound requests have to be through an internet-facing NAT instance.
At the moment, our project requires the app servers to access a ftp server provided by a service provider.
I have tried several ways to manage that, but all no luck. What I have done was to open a port range, let's say (40000 - 60000) on both NAT and APP security groups, also standard ftp ports 20 - 21 as well.
The user authentication can be passed, but I could not list contents from app servers.
I am able to access the ftp server from NAT, not problem at all.
So what should I do to make it work?
#JohnRotenstein is absolutely correct that you should use Passive FTP if you can. If, like me, you're stuck with a client who insists that you use Active FTP because their FTP site that they want you to connect to has been running since 1990 and changing it now is completely unreasonable, then read on.
AWS's NAT servers don't support a machine in a private subnet connecting using Active FTP. Full stop. If you ask me, it's a bug, but if you ask AWS support they say it's an unsupported feature.
The solution we finally came up with (and it works) is to:
Add an Elastic Network Interface (ENI) in a public subnet on to your EC2 instance in the private subnet
So now your EC2 instance has 2 network adapters, 2 internal IPs, etc.
Let's call this new ENI your "public ENI"
Attach a dedicated elastic IP to your new public ENI
Let's assume you get 54.54.54.54 and the new public ENI's internal IP address is 10.1.1.10
Add a route in your operating system's networking configuration to only use the new public ENI
In windows, the command will look like this, assuming the evil active ftp server you're trying to connect to is at 8.1.1.1:
route add 8.1.1.1 mask 255.255.255.254 10.1.1.1 metric 2
This adds a route for all traffic to the FTP server at 8.1.1.1 using subnet mask 255.255.255.254 (ie. this IP and only this IP) should go to the internet gateway 10.1.1.1 using ethernet adapter 2 (your second NIC)
Fed up yet? Yeah, me too, but now comes the hard part. The OS doesn't know it's public IP address for the public EIN. So you need to teach your FTP client to send the PORT command with the public IP. For example if using CURL, use the --ftp-port command like so:
curl -v --ftp-port 54.54.54.54 ftp://8.1.1.1 --user myusername:mypass
And voila! You can now connect to a nightmare active FTP site from an EC2 machine that is (almost entirely) in a private subnet.
Try using Passive (PASV) mode on FTP.
From Slacksite: Active FTP vs. Passive FTP, a Definitive Explanation:
In active mode FTP the client connects from a random unprivileged port (N > 1023) to the FTP server's command port, port 21. Then, the client starts listening to port N+1 and sends the FTP command PORT N+1 to the FTP server. The server will then connect back to the client's specified data port from its local data port, which is port 20.
Thus, the traffic is trying to communicate on an additional port that is not passed through the NAT. Passive mode, instead, creates an outbound connection, which will then be permitted through the NAT