Ask Your Question

External instances L3 connectivity to physical network failing due to SNAT

asked 2017-01-26 18:51:59 -0500

updated 2017-01-27 10:14:07 -0500


When I place instances in my external network (for example when implementing my own routers instead of Neutron), I can connect to the physical world via L2 normally, but every L3 connection attempt seems to go to neutron, which is replacing the instance's source address with the compute node's address.

I'm aware of antispoofing rules, however, in this case I'm trying to connect to the outside from the same source IP assigned in the external network.

Is this normal? is there a way to deal with this without disabling the L3 Agent?

My environment is: Openstack Newton with 1 controller node, 1 compute node and 1 storage node, each running inside a VM.


edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted

answered 2017-01-27 10:09:05 -0500

Solved! something weird happened and I think it's a defect related to this kind of virtual environments with libvirt. Initially I though it was something specific to my setup but a colleague went through the exact same problem, so it's better to document it:

  • In my host, there are 3 libvirt VMs (Openstack Controller, Compute and Storage).
  • There is a virtual bridge called virbr0 ('default' network 192.168.122.x) that I was using as my 'provider' (external) network.
  • The strange thing, was that the OS Compute VM inherited this virbr0 interface and related MASQUERADE rules from the host, exactly as they exist out there. This only happened in the compute node at some stage of the Openstack installation. So in my compute node, we have the virbr0 (in DOWN state) and these 'alien' iptables rules:

    MASQUERADE tcp -- ! masq ports: 1024-65535 MASQUERADE udp -- ! masq ports: 1024-65535 MASQUERADE all -- !

These rules were the ones causing the problem, as any external VM source IP in the 192.168.122.x range was trying to exit with the compute node's IP address.

Instead if deleting the rules, I just changed the provider network to another, new virtual network (other than the 'default' one) and everything works as expected.

edit flag offensive delete link more


I was having the same problem in my virtualized environment with libvirt and I ran the procedure indicated by @gianpietro and it worked for me. Excellent!

ctomas gravatar imagectomas ( 2017-01-27 11:12:33 -0500 )edit

Get to know Ask OpenStack

Resources for moderators

Question Tools



Asked: 2017-01-26 18:51:59 -0500

Seen: 346 times

Last updated: Jan 27 '17