I have set a VPC that has Cassandra DB nodes, I am trying to add my IP address to some tests, but I can't add my IP address:
Edited the source as:
10.0.0.0/16, xx.xxx.xx.xx/0
where xx.xxx.xx.xx is my public IP address, but I got error:
The source must be a valid CIDR (e.g. 0.0.0.0/0) or the ID of another security group.
So, how can I add my IP address to the inbounds rules?
The issue is with your xx.xxx.xx.xx/0 /0 is not a valid CIDR if you just want to use your IO address use it like this xx.xxx.xx.xx/32 and it will work.
For reference http://doc.m0n0.ch/quickstartpc/intro-CIDR.html
Related
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:
Your Server IP Address is 172.20.30.75 and it is part of 172.20.30.0/24 subnet. You have a service that needs to be accessible only from the above server. Service firewall allows you to specify CIDR based rules for configuring source address that can access the service. What address would you specify?
172.20.30.75/24
17.20.30.0/24
17.20.30.75/32
17.20.30.0/32
172.20.30.75 can be part of multiple subnets /32, /31, /30, ....
If you want only 172.20.30.75, then the CIDR is 172.20.30.75/32.
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!
I have created a security group in aws.amazon.com hosting.
I have set SSH to custom IP.
My problem is that my IPs are dynamic with in a range:
For example,
217.206.204.200
217.206.203.215
217.206.201.295
I want to create one rule for SSH custom IPs. So that all IPs have starting 217.206 can connect to server.
How can I do this?
217.206.0.0/16
This expression in the "Custom IP" box would allow every IP from 217.206.0.0 through 217.206.255.255, inclusive.
This is called CIDR notation.
The numbet after the slash is the prefix. An IPv4 address is 32 bits wide. The prefix indicates which bits of the address being compared must match the address specified. In this case, if the first 16 bits of the address of the connecting machine are "217" followed by "206" then the remaining bits of the address can be anything, and the rule will match that source IP.
http://en.m.wikipedia.org/wiki/Classless_Inter-Domain_Routing#CIDR_notation
Hi have issues with securithy groups on aws.
Assume I have two sec groups:
sg-d774eeed (secA)
sg-d787eady (secB)
I want secA to have access to port 9999 on secB.
In the source input box I will add sg-d774eeed with port 9999.
Commit the changes.
Nothing works
So I need to input sg-d774eeed/0 sg-d774eeed/32 or something like that?
You can create just one security group with port 9999, enter the same security group name in the source and assign this security group to both instances that you want to communicate together. However, to make that happen, you need to use either Private IP i.e. 172.1.2.3 or Public DNS i.e. ec2-54-1-2-3.eu-west-1.compute.amazonaws.com.
Port Range Source
9999 sg-abcdef
The best is to use Public DNS because:
When an EC2 instance queries the external DNS name of an Elastic IP, the EC2 DNS server returns the internal IP address of the instance to which the Elastic IP address is currently assigned.