When I try to create a VM with a public IP address on Bluemix, I get the following error:
Your VMs are in error - Resource CREATE failed: Error: Resource CREATE
failed: Error: Resource CREATE failed: NotFound: External network
f242da31-3809-48a4-aa84-46da1c50586c is not reachable from subnet
a78fbf7e-1e4a-4d3a-a039-c05be4846bc3. Therefore, cannot associate Port
6978
Creating a VM without a public IP works, but I cannot connect to the VM without a public IP.
I also tried creating a network on the Horizon dashboard, but I could not figure out how to assign a public IPv4 or IPv6 address.
I understand that IPv4 addresses may be short in supply and would be happy with an "IPv6 only" VM, but I could not figure out how to request a "public" IPv6 prefix on Bluemix.
I have not seen that error. I think the problem you ran into may be intermittent. I just created a VM an hour ago using the Bluemix dashboard and that worked no problem. As usual, the VM was assigned two IP's, one internal and one public.
As you've discovered, in the Horizon dashboard, when you create a VM, by default it only has an internal IP. To add a public IP takes a few steps that aren't exactly obvious:
From the Cloud Management Dashboard, select the Instances tab
In the Actions column for your VM, select Associate Floating IP
In the IP Address field, select an IP address
By default, there won't be any IP addresses to select. To allocate one, press the plus (+) sign.
In the Allocate Floating IP dialog, set the Pool to Public-Network and press Allocate IP.
Now select that IP address you've just allocated.
For Port to be associated, choose the internal IP and press Associate.
Now the Instances tab will display the VM with two IP addresses.
If this doesn't work: There is a limit to how many public IPs you get, so maybe you've hit that limit. Looks like Horizon shows the limit as 10; I think that's public, but it may be public and private.
To see the list of IPs allocated to your account (and whether that list has reached 10):
From the Cloud Management Dashboard, go to the Access & Security tab.
Go to the Floating IPs sub-tab.
That shows your list of public IPs and their mapping to internal IPs. If you've reached you max, you'll need to move an IP from one VM to another. You can delete the first VM to make its IP available. Or you can disassociate the IP from one VM (don't release the IP, disassociate it) and then assign it to another VM has described above.
This screen is another place to allocate IPs to your account. The only network I see is Public-Network, and it has IPv4 addresses. I don't see any way to allocate IPv6 addresses.
Related
Is there any way in the GCP, to allow VM hostnames to be resolved to their IPs even when the VMs are stopped?
Listing VMs in a project reveals their assigned internal IP addresses even when the VMs are stopped. This means that, as long as the VMs aren't re-created, their internal IPs are statically assigned.
However, when our VMs are stopped, the DNS resolution stops working:
ping: my-vm: Name or service not known
even though the IP is kept assigned to it, according to gcloud compute instances list.
I've tried reserving the VM's current internal IP:
gcloud compute addresses create my-vm --addresses 10.123.0.123 --region europe-west1 --subnet default
However, the address name my-vm above is not related to the VM name my-vm and the reservation has no effect (except for making the IP unavailable for automatic assignment in case of VM re-creation).
But why?
Some fault-tolerant software will have a configuration for connecting to multiple machines for redundancy, and if at least one of the connections could be established, the software will run fine. But if the hostname cannot be resolved, this software would not start at all, forcing us to hard-code the DNS in /etc/hosts (which doesn't scale well to a cluster of two dozen VMs) or to use IP addresses (which gets hairy after a while). Specific example here is freeDiameter.
Ping uses the IP ICMP protocol. This requires that the target is running and responding to network requests.
Google Compute Engine VMs use DHCP for private IP addresses. DHCP is integrated with (communicates with) Google DNS. DHCP informs DNS about running network services (VM IP address and hostname). If the VM is shutdown, this link does not exist. DHCP/DNS information is updated/replaced/deleted hourly.
You can set up Google Cloud DNS private zones, create entries for your VPC resources and resolve private IP addresses and hostnames that persist.
When setup a IP-Alias via gloud command or the interface, it works out of the box. But in the machine itself, i do not see any configuration, ip addr-entries, no firewall rules, no routes that would allow to be the machine pingable - but it's pingable (local and remote)! (for example 10.31.150.70, when you setup a 10.31.150.64/26-subnet, and you primary IP is 10.31.150.1)
On the other hand, the primary IP of the machine is a /32-Netmask. For example:
10.31.150.1/32, Gateway: 10.31.0.1/16. So, how can the machine reach the gateway, 10.31.0.1, when the gateway is out of the range?
When removing the Main-IP via ip addr del, the aliases aren't pingable anymore.
Google runs a networking daemon on your instance. It runs as the google-network-daemon service. This code is open source and viewable at this repo. This repo has a Python module called google_compute_engine which manages IP aliasing among other things. You can browse their code to understand how Google implements this (they use either ip route or ifconfig depending on the platform)
To see the alias route added by Google on a Debian box (where they use ip route underneath for aliasing) run the following command.
ip route ls table local type local dev eth0 scope host proto 66
If you know your Linux commands, you can remove appropriate routes after stopping the daemon, and then assign the alias IP address to your primary interface as the second IP address to see the ifconfig approach in action as well.
When alias IP ranges are configured, GCP automatically installs VPC network routes for primary and alias IP ranges for the subnet of the primary network interface. Alias IP ranges are routable within the GCP virtual network without requiring additional routes. That is the reason why there is no configuration on the VM itself but still it's pingable. You do not have to add a route for every IP alias and you do not have to take route quotas into account.
More information regarding Alias IP on Google Cloud Platform (GCP) can be found in this help center article.
Be aware that Compute Engine networks only support IPv4 unicast traffic and it will show the netmask as /32 on the VM. However, it will still be able to reach the Gateway of the subnet that it belongs to. For example, 10.31.0.0/16 includes hosts ranging from 10.31.0.1 to 10.31.255.254 and the host 10.31.150.1 is within that range.
To further clarify why VM instances are assigned with the /32 mask, it is important to note that /32 is an artificial construct. The instance talks to the software defined network, which creates and manages the "real" subnets. So, it is really a link between the single address and the gateway for the subnet. As long as the link layer is there, communications are established and everything works.
In addition to that, network masks are enforced at the network layer. This helps avoid generation of unnecessary broadcast traffic (which underlying network wouldn't distribute anyway).
Note that removing the primary IP will break the reachability to the metadata server and therefore the IP aliases won't be accessible.
I use a static IP connection, Configured to TPLINK router.
I have a local server running which i can access from my network, but i want it to be accessed outside network.
So I did port forwarding. and its Successfully running.
Now the problem is :: The IP address of my WAN is also a private address like 10.10.X.X, so when am entering http://10.10.X.X, i can access my site, but not outside my network. Please guide me how to fix this?
If your WAN address is a private address, your ISP is using CGN. This is becoming more common since the RIRs have, or soon will, run out of public IP addresses to assign to ISPs. It sounds like your ISP has run out of public addresses and needs to use private addresses for its residential customers, reserving its remaining public addresses for its business customers which are willing to pay for public addresses.
Basically, your ISP is using NAT, too. You would need to have the ISP forward your port on its NAT router, but the odds of that are zero since it probably has a policy you agreed to to not host servers on your residential LAN (buried in the fine print of the ISP agreement). This situation will play out more and more over time.
You have to use the "Virtual Server" settings. Port triggering is used for.
Once the modem router is configured, the operation is as follows: 1. A local host makes an outgoing connection to an external host using a destination port number defined in the Trigger Port field. 2. The modem router records this connection, opens the incoming port or ports associated with this entry in the Port Triggering table, and associates them with the local host. 3. When necessary, the external host will be able to connect to the local host using one of the ports defined in the Incoming Ports field.
It is not used for incoming connections which are triggered from outside!
Of course, to have it working you have to have an application listening on that port not only having the firewall on Windows allowing the port.
After you set up the "Virtual Server" a port scanner should show you the port is open (even without having a running application listening) - it will try to port forward it. I use ShieldsUp for testing.
I want to know how does the openstack assign ip to virtual machines ? and how to find out port and ips used by the VM. Is it possible for us to find out the IP and ports being used by an application running inside the VM ?
To assign an IP to your VM you can use this command:
openstack floating ip create public
To associate your VM and the IP use the command below:
openstack server add floating ip your-vm-name your-ip-number
To list all the ports used by applications, ssh to your instance and run:
sudo lsof -i
Assuming you know the VM name
do the following:
On controller run
nova interface-list VM-NAME
It will give you port-id, IP-address and mac address of VM interface.
You can login to VM and run
netstat -tlnp to see which IP and ports being used by applications running inside the VM.
As to how a VM gets IP, it depends on your deployment. On a basic openstack deployment when you create a network and create a subnet under that network, you will see on the network node a dhcp namespace getting created. (do ip netns on network node). The namespace name would be qdhcp-network-id. The dnsmasq process running inside the dhcp namespace allots IPs to VM. This is just one of the many ways in which VM gets IP.
This particular End User page of the official documentation could be a good start:
"Each instance can have a private, or fixed, IP address and a public, or floating, one.
Private IP addresses are used for communication between instances, and public ones are used for communication with the outside world.
When you launch an instance, it is automatically assigned a private IP address that stays the same until you explicitly terminate the instance. Rebooting an instance has no effect on the private IP address.
A pool of floating IPs, configured by the cloud operator, is available in OpenStack Compute.
You can allocate a certain number of these to a project: The maximum number of floating IP addresses per project is defined by the quota.
You can add a floating IP address from this set to an instance of the project. Floating IP addresses can be dynamically disassociated and associated with other instances of the same project at any time.
Before you can assign a floating IP address to an instance, you first must allocate floating IPs to a project. After floating IP addresses have been allocated to the current project, you can assign them to running instances.
You can assign a floating IP address to one instance at a time."
There are of course deeper layers to look at in this section of the Admin Guide
Regarding how to find out about ports and IPs, you have two options: command line interface or API.
For example, if you are using Neutron* and want to find out the IPs or networks in use with the API:
GET v2.0/networks
And using the CLI:
$ neutron net-list
You can use similar commands for ports and subnets, however I haven't personally tested if you can get information about the application running in the VM this way.
*Check out which OpenStack release you're running. If it's an old one, chances are it's using the Compute node (Nova) for networking.
I am setting up a VPC on Amazon AWS using Scenario 2: VPC with Public and Private Subnets.
In the "Adding Rules to the WebServerSG Security Group" section, it specifies to set an inbound SSH rule, specifying allowed sources to be: "Your network's public IP address range".
I have an elastic IP address assigned to my NAT EC2 device. When I created my public web server (in the public subnet) I also assigned a public IP address to it (as part of the wizard). This does not appear in my elastic IP list for some reason (although I believe them to be the same thing right?). They are are not contiguous addresses.
I am not sure exactly what is supposed to happen here. Am I supposed to be able to ssh into the web server in the public subnet? Why would I specify that the only source to be able to ssh into the web server is my network's public IP address range? When I set the allowable source address to either of the public IPs, my connection is refused. Am I supposed to be SSH-ing somewhere else.
Could someone please explain to me exactly how this setup is supposed to work, in terms of how I am supposed to be SSH-ing into the instances remotely?
"Your network's public IP address range" means the network where you are -- not EC2... it refers to the public IP address or range of the computer where you're sitting now, your office network, your home network, any network where your traffic will be be coming from when you want to access the EC2 machines remotely to administer them.