Network

Network

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 (128.52.128.0/18)” 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 reallyreally 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.

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
help@csail.mit.edu and we'll walk you through the process.