Instance cannot connect to "public" lan, but can connect to the internet

Asked by Martin Samson

I have a multi-node openstack essex installation on ubuntu 12.04.

The control node runs nova-api, glance, keystone, etc.
The compute node runs nova-compute, nova-network

Launching instances works fine, they boot and run as expected. They can ping google.com/yahoo.com but cannot connect to anything on the office lan.

Network configuration:
10.0.0.0/16 "office lan"
10.2.0.0/16 Instance vlans (20 vlan within that space)

The compute and control nodes have dual nic, eth0 being on the office lan, eth1 on their private network (physically separated network).

Office lan machines can connect to instances using their floating ip. Instances cannot connect to anything on the office lan.

It seems a nat/forward rule is missing on the compute node to let instances connect to the office lan.

Nat rules on the compute node:

DNAT all -- 0.0.0.0/0 10.0.253.17 to:10.2.0.3
DNAT udp -- 0.0.0.0/0 10.0.254.101 udp dpt:1000 to:10.2.0.2:1194
DNAT all -- 0.0.0.0/0 10.0.253.18 to:10.2.0.5
ACCEPT all -- 10.0.0.0/8 10.0.0.0/8 ! ctstate DNAT
DNAT tcp -- 0.0.0.0/0 169.254.169.254 tcp dpt:80 to:169.254.169.254:8775
DNAT all -- 0.0.0.0/0 10.0.253.17 to:10.2.0.3
DNAT udp -- 0.0.0.0/0 10.0.254.101 udp dpt:1000 to:10.2.0.2:1194
DNAT all -- 0.0.0.0/0 10.0.253.18 to:10.2.0.5
SNAT all -- 10.2.0.3 0.0.0.0/0 to:10.0.253.17
SNAT all -- 10.2.0.5 0.0.0.0/0 to:10.0.253.18
SNAT all -- 10.0.0.0/8 0.0.0.0/0 to:10.0.254.101

Routes on the compute node
default firewall001.hq. 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 * 255.255.0.0 U 0 0 0 eth0
10.2.0.0 * 255.255.255.224 U 0 0 0 br100
192.168.122.0 * 255.255.255.0 U 0 0 0 virbr0

ip addr output
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet 169.254.169.254/32 scope link lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:30:48:f9:d5:98 brd ff:ff:ff:ff:ff:ff
    inet 10.0.254.101/16 brd 10.0.255.255 scope global eth0
    inet 10.0.253.17/32 scope global eth0
    inet 10.0.253.18/32 scope global eth0
    inet6 fe80::230:48ff:fef9:d598/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:30:48:f9:d5:99 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
    link/ether 0e:17:a5:45:d7:08 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
6: vlan100@eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop master br100 state DOWN
    link/ether fa:16:3e:4c:48:25 brd ff:ff:ff:ff:ff:ff
7: br100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether fa:16:3e:4c:48:25 brd ff:ff:ff:ff:ff:ff
    inet 10.2.0.4/27 brd 10.2.0.31 scope global br100
    inet6 fe80::8487:66ff:fe01:1968/64 scope link
       valid_lft forever preferred_lft forever
8: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br100 state UNKNOWN qlen 500
    link/ether fe:16:3e:6d:ac:77 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc16:3eff:fe6d:ac77/64 scope link
       valid_lft forever preferred_lft forever
9: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br100 state UNKNOWN qlen 500
    link/ether fe:16:3e:36:7f:d4 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc16:3eff:fe36:7fd4/64 scope link
       valid_lft forever preferred_lft forever

See http://serverfault.com/questions/382393/openstack-instance-cannot-reach-lan

Question information

Language:
English Edit question
Status:
Solved
For:
OpenStack Compute (nova) Edit question
Assignee:
No assignee Edit question
Solved by:
Martin Samson
Solved:
Last query:
Last reply:
Revision history for this message
Martin Samson (pyrolian) said :
#1

Okay, seems like i had a routing issue on the compute node.

Moving all the vlans to 192.168.0.0/16 range made requests on the 10.0.0.0/16 work.

Still unsure why it wasn't working before.