Unable to communicate to floatingip on a same network

[Itsuro Oda]

If one try to communicate from a tenant network to floatingip which attached to
a port on the same network, the communication fails.

------------------------------------------------------------
for example, unable to communicate from 10.0.0.3 to 100.0.0.5

  --------+--------- exeternal
          | 100.0.0.0/24
     +----+----+
     | router |
     +----+----+
          | 10.0.0.0/24
  --+-----+----+---- internal
    | |
  10.0.0.3 10.0.0.4
           (100.0.0.5)
-------------------------------------------------------------

Note that ping is not adequate to check connection.
icmp reply is returned thus ping success but the from address is different.
---
<10.0.0.3 host>: $ ping 100.0.0.5
PING 100.0.0.5 (100.0.0.5) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=3.45 ms (must be returned from 100.0.0.5)
---
(This is because destination address (100.0.0.5) is DNATed to fixed ip (10.0.0.4)
on the router, but reply does not go through the router.)

Use TCP/IP (ex. ssh) to check connection.

This problem is a regression cased by https://review.openstack.org/#/c/131905/ .
(it is my fault.)
This maybe not common use case but should be fixed since it was OK before the patch.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/161947

[yong sheng gong (gongysh)]

are you sure it is caused by your packet? I thought it is an old bug!

[Itsuro Oda (oda-g)]

gongysh, yes I am sure. It is easy to use Juno release to examine it was OK.

[Brian Haley (brian-haley)]

I can confim this is broken in the latest neutron code, but you do have to be on the same subnet, to a VM on a different subnet behind the same router seems to work just fine. I will give the patch a test.

[Itsuro Oda (oda-g)]

Brian,

Yes. 'on a same subnet' is more precisely. I just use 'network' since one subnet per network is typical use case.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/161947
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=5154d974fdce4625710d3b4f360d45568678eb2f
Submitter: Jenkins
Branch: master

commit 5154d974fdce4625710d3b4f360d45568678eb2f
Author: Itsuro Oda <email address hidden>
Date: Wed Feb 25 13:34:04 2015 +0900

    Make floatingip reachable from the same network

    The problem is that if one tries to communicate from a tenant network
    to floatingip which attached to a port on the same network, the
    communication fails.

    This problem is a regression cased by [1].
    [1] https://review.openstack.org/131905/

    Before [1] SNAT rule is as follows:
    -s %(internal_cidr)s -j SNAT --to-source ...
    (for each internal interface)

    After [1] SNAT rule is as follows:
    -o %(interface_name)s -j SNAT --to-source ...
    (for an external interface)

    The new rule was considered a super-set of the packets going out to
    the external interface compared to the old rules. This is true but
    there is a lack of consideration.

    Note that the packet is 'going out to external interface' OR 'DNATed'
    at this point since the rule:
    ! -o %(interdace_name)s -m conntrack ! --ctstate DNAT -j ACCEPT
    was applied already. So we should consider the following three cases.

    1) going out to external interface
    should be SNATed. It is OK under the new rule but there was a lack
    of rules for packets from indirectly connected to the router under the
    old rules. ([1] fixed this.)

    2) DNATed (and going out to internal interface)
    2-1) came in from internal interface
    should be SNATed because the return traffic needs to go through the
    router to complete the conntrack association and to reverse the effect
    of DNAT on the return packets. If a packet is not SNATed, the return
    packet may be sent directly to the private IP of the initiator.
    The old rules done SNAT in this case but the new rule doesn't.

    2-2) came in from external interface
    nothing to do.

    This patch adds a rule for the case 2-1).
    This patch also adds mangle rules to examine whether a packet came from
    external interface.

    Change-Id: Ifa695ac5428fb0edba60129a4d61ec0e127a5818
    Closes-Bug: #1428887

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: neutron-pecan
Review: https://review.openstack.org/185072