I am attempting to connect to my instance via PuTTY but when I attempt to connect with the inbound rule set to my private range (i.e 192.168.2.0/24) it just won't work. When I set it to the insecure 0.0.0.0/24 all is fine. Can anyone explain, or solve this issue. I am running Windows 7 with all current updates. My IP address is not static.
The 192.168.0.0/16 CIDR range is considered a private network, which means it is not routable. This also means that AWS, when receiving the connection from the PuTTY client on your machine (which might have an IP address of 192.168.2.1, for example), does not see the remote address of that connection as the IP address of your server. Instead, AWS probably sees the remote address of that incoming connection as being an IP address from your ISP. That's why allowing "0.0.0.0" as the inbound rule works; it allows incoming addresses from everywhere.
To find out what CIDR range to use as a more restrictive inbound range for your AWS security groups, you might connect in to your instance, then do:
$ env | grep SSH_CONNECTION
SSH_CONNECTION=1.2.3.4 54068 5.6.7.8 22
In particular, you are looking for the SSH_CONNECTION environment variable. Per the ssh man page, the SSH_CONNECTION environment variable
Identifies the client and server ends of the connection.
The variable contains four space-separated values: client IP address,
client port number, server IP address, and server port number.
Thus the first part of the value, the "1.2.3.4" in my contrived example, would show you the IP address that AWS sees your PuTTY connection as coming from; you can then use that IP address as the basis for a CIDR range.
Hope this helps!
Related
Trying to create tcp socket connection between via an Ipv6 address, I get Network is unreachable (os error 101)
As a binding local address is used fe80::850***.
Probably it's because of fe80*** is local ipv6 address generated by OS. Is there a way to provide correct configuration for system to make a call via IPv6?
Short answer:
Your IPv6 connectivity is not setup correctly. This is most probably no configuration problem on your machine, but on the gateway router.
Long answer:
You get a "Network is unreachable" error because your operating system does not know how to reach the destination address. Usually it maintains a table called the routing table, where it looks up which network path leads to which ip subnet. It seems that in your case, there are several things missing.
Your interface probably has no configured non-link-local (fe80::/64) address
There is no routing table entry for the destination address range
In the IPv4 world these missing things are usually resolved by a DHCP server. In the IPv6 world, there are two possible configuration options. Either DHCPv6 is used or the IPv6 Stateless Address Autoconfiguration is used. It seems that neither is setup in your network. Note that correctly setting up one of these requires you to have administrative access to your gateway router.
As it required quite long time to find the main reason of the problem, will try to share the solution/investigation steps:
To make sure ipv6 is not configured properly just run 'ping6 ipv6.google.com'. It should return some error message like 'connect: Network is unreachable' or just stuck.
AWS ec2 instances by default are not assigned ipv6 global routable addresses(only ipv4 is assigned). Ipv6 addresses like 'fe80:*' are local routable and can't be used for global requests. To check the list of ip addresses, check eth0 config /sbin/ifconfig. Btw, AWS provides interface to generate global routable ipv6 address for ec2 instance (just check vpc/ec2 console pages - https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html)
Check security group of ec2 instance and make sure that in route table ipv6 traffic is allowed.Specifically inbound and outbound rules should include '::/0' for ipv6(or one of them based on the need).
Try 'ping6 ipv6.google.com' again
Run the following command to check whether IPv6 is enabled:
ip addr
If only an IPv4 address is displayed, IPv6 is disabled. Enable it by referring to this tutorial.
If a link-local address (starting with fe80) is displayed, IPv6 is enabled but dynamic assignment of IPv6 addresses is not enabled.
If an IPv6 address other than fe80 is displayed, IPv6 is enabled and an IPv6 address has been assigned.
I am very much new to network programming and maybe I am asking a very basic question.
I am working on a legacy C++ codebase where the windows 'getnameinfo' API is used to obtain the hostname from the given IP address. The obtained hostname is wrong and it belongs to a different VM in the domain.
Let us say, there is VM with hostname 'VM1' with IP 10.44.176.57 and
another VM with hostname 'VM2' and IP 10.44.176.24.
When IP 10.44.176.57 is passed to the getnameinfo() API, it resolves it to the hostname VM2.
The ping command also returns the same results.
When I ping hostname VM1 and VM2 both resolves to their correct respective IP addresses.
I checked in DNS manager, the IPs of VMs are assigned correctly.
My question is,
1) Why getnameinfo API is returning the wrong hostname?
2) Is there any way to verify the resolved hostname is the correct one ?
I have a network in GCP with configured firewall rules. I have couple of instances and two of them are as below.
instance 1 - with network tag "kube-master"
instance 2 - with network tag "kube-minion"
And I want to ping from kube-master to kube-minion So, I set up a firewall rule (master-to-node) for icmp as below.
But the problem is I can't still ping from kube-master to kube-minion. I logged into instance 1 (kube-master) and tried to ping the public ip address of instance 2 (kube-minion) but it doesn't ping
As above image, am I restricting this behaviour? But I have setup the priority as 2 so it will take the precedence.
When I set source as 0.0.0.0/0 instead of giving kube-master it works, but I need to only do this (send traffic to kube-minion) only from kube-master
Can someone tell me where am I doing the mistake? Thank you!
As you can see in the documentation
Thus, the network tags are still only meaningful in the network to which the instance's network interface is attached.
Therefore, if you access to the VM with the Public IP, you are going out of your network to reach it, and the tag information is lost. Use the private IP of the VM and it will work as expected.
Add 0.0.0.0/0 as source, or the public IP of the master in /32 (better) if you want to continue to use the instance 2 public IP
Source tags only apply to traffic sent from the network interface of another applicable instance in your VPC network. A source tag cannot control packets whose sources are external IP addresses, even if the external IP addresses belong to instances.
When you ping from instance-1 the external IP address of instance-2, the ICMP request is translated and therefore on the receiving side, the request appears to come from an IP address(external IP of instance-1) that is not associated with the network tag kube-master.
Edit:
I have a database server configured on AWS and I want to restrict access to it only from my computer's IP.
The problem is as IP addresses get assigned dynamically by the ISPs, I manually need to whitelist my IP address before accessing the server from my computer, everytime I switch from my home network to some other network.
I have been able to set a static IP address for my machine, but when I try to change my ISP from local broadband to mobile internet's hot-spot or to another network different from my broadband, the connection seems to fail. Is there any way to make my machine use the same static IP while using different ISPs ?
Here's a script I use:
IP=`curl -s http://whatismyip.akamai.com/`
aws ec2 authorize-security-group-ingress --group-name GROUP-NAME --protocol tcp --port 22 --cidr $IP/32 --output text
In this example, it is adding my current IP address to the security group for use with SSH (port 22). You can modify it for your needs.
Please note that there is a maximum number of security group rules, so you will need to "empty it out" after you've hit the limit.
I recently changed port field with custom port sshd_config file on amazon ec2.
However, it doesn't respond to ssh -p1234 user#domain.com because of security groups.
I have my ssh port (22) open on security group but I need to make it 1234 but on aws console, when I changed ssh source to 0.0.0.0/1234 it says unable to find group.
So, how do I set security group right ?
You appear to have confused the port with the CIDR address.
The CIDR annotation describes the range of addresses which are permitted to establish connections on a port - if you want anyone to be able to access the port from any address, use 0.0.0.0/0.
You then specify the port separately, which in your case is 1234.
Please note that changing your ssh port is not considered as a best practice. Network scanners will find your 'hidden' ssh port in no time. It is actually worse than having ssh on 22 since it provides you with false sense of security.
Consider restricting the actual scope of this service to your home / office IP addresses (as instructed by AWS Trusted Advisor)
You can even utilize Dome9 to have this port normally closed and only opened on demand.
(disclaimer: I'm a proud Dome9'er)