Currently the is only one publicly available network defined in our OpenStack world called “inet”. This network puts your instance directly on a publicly accessible IPv4 network.

Security Groups

By default all network access to instances is blocked

More specifically outbound (“egress”) and related inbound (“ingress”) traffic is allowed, all other traffic is blocked. This means your instance will be able to run package updates, but you won’t be able to ping it or ssh to it.

Each project can edit its own default security group or create additional security groups to open up network access. Forgetting to assign the correct security group is one of the most common mistakes when starting instances and results in them being unreachable. It is possible to add or remove security groups from running instances using the “Actions” drop down menu on the “Instances” page of the web interface or the nova add-secgroup command.

To define rules:

In the web interface select the Access & Security tab, there should be a button on the right-hand side of the interface called
Create Security Group”.

Click that, and give the group a name and description. Once it’s in the list of security groups, click the “Manage Rules” button.

By default, groups that you create will automatically allow all outgoing (Egress) traffic to all ports and IPs. To set up a similar incoming (Ingress) rule, click the “ Add Rule” button in the rules management interface.

There are a number of predefined rules available in the “Rules” drop down. Most likely you will find what you need there either a specific application such as “ssh” or open all of a given protocol “all tcp”, “all udp”, or “all icmp” for example. It is possible to add multiple rules in a group and apply multiple groups to an instance.

It is also possible to add specific custom ports or port ranges. Since all egress traffic is allowed by default in a new rule set you will most likely want to set “Ingress” rules.

Note that all rules open new ports so as you stack rules togather they always become more premissive. For example if you want some instance to have more restrictions than the ‘default’ rule; you will need to remove it from the list of security groups for that instance before applying your more restrictive rules.

Using Fixed IP Addresses

Instances are dynamically assigned publicly routable IP addresses and this is sufficient in many cases.

If you need a fixed IP address one may be reserved using WebDNS and selecting “OpenStack public network (” as the subnet. DO NOT override the address WebDNS assigns you — this will be your new permanent public IP address (once you click the “Commit changes” button). Take a note of your new IP address.

Once your fixed IP is registered in WebDNS (CSAIL Login required), you should assign it to your instance in the WebUI. When launching an instance, fill in your fixed IP in the eth0 Fixed IP field under the Details tab. Currently the web interface for this only works if you are booting a single instance with a single connected network. That is by far the most common case but if you need to specify a fixed IP and require multiple networks you will need to use the CLI environment.

Multiple IPs

If you are building a system that requires multiple addresses on a single port things get complicated. Typically people do this when running webservers that run multiple sites or load balancers that balance multiple things. While these a reuseful tricks to keep hardware costs down they are usually not necessary in the cloud just launch a seperate instance fo reach task.

If you really need multiple addresses on one system you can add more “ports” the CLI and API allow this but the WebUI won’t let you set multiple interfaces on the same network at creation time. After boot up you can select “Attach Interface” from the “Actions” dropdown next to your instance on the “Instances” page.

If you really really need the address on the same interface you run into an anti spoofing feature the OpenStack deploys to only allow “know address pairs” so that it will only pass traffic from IPs it knows are assosciated with a given MAC address.

You can configure this but you must use the CLI environment.

First find out what “port” is associated with your instance: read the previous section on Fixed IPs and make sure the IP your going to assing is registered to you in WebDNS (CSAIL Login required)

Next find the UUID of the port your instance is currently using

neutron port-list|grep <current_instance_ip> | cut -d \| -f 2

Finally set that port to allow the new address (can be repeated multiple times)

neutron port-update <port_uuid>  --allowed_address_pairs type=dict list=true ip_address=<ip_addr>

Defining your own networks

Neutron makes it easy for us to allow groups to create their own private networks, so we did. There is no particular use case in mind so if you have one let us know and we can help configure the best solution. Here is the current state of things if you want to play with this part.

Right now you can definitely define your own networks that are private to your project. These are implemented as GRE tunnels, which you needn’t think about except that it means they are isolated and you don’t have to worry about coordinating IP addressing with other projects. If you have defined your own networks it is possible to add any or all of them to a given instance.

You can use OpenStack’s built in DHCP service to serve dynamic addresses from a range of your own choosing to hosts on that network.

You can use OpenStack’s “router” implementation to build routers between multiple private networks.

You cannot use OpenStack’s “router” implementation to provide NAT and connection to the public IP network, if you want this functionality you’d need to build an instance with multiple interfaces and configure that system manually to do routing and NAT. If you want to do this we might be able to configure things so it works but there are a number of performance bottlenecks that make it seem like a bad idea.

This is no longer stricly true. Routers on private networks can be assinged public "floating" IP addresses and can then NAT out bound traffic. It is aslo possible to assign "floating" public IPs to VMs on private networks like AWS elastic IPs.

More documentation is needed here. If you need this fuctionality ask and we'll walk you through the process.