DNAT of floating IPs on Neutron server doesn't work, incoming packets get swallowed

asked 2014-03-06 02:47:35 -0500

mauro.stettler gravatar image

I'm using Neutron with Openvswitch and with namespaces.

My problem is that floating IPs are correctly assigned to an interface in the router's namespace, and the Iptables rules to implement the DNAT are added as well, but for some reason the incoming packets get lost when the DNAT should happen. When i use tcpdump inside the router's namespace, listening on the interface with the floating IPs (qg-1aad9421-8f), I see the packets arriving as expected. But when I listen for the same packets inside the same namespace, but on the router's internal interface (qr-3a8afdbe-20), I cannot see these packets.

Something must be swallowing these packets and prevent them from being DNATed and inserted into the private (10.100.0.0/16) subnet. But I can't see where/why they get lost, so I guess I must be missing something.

That's the setup:

  • Floating IP subnet: 154.72.0.0/22
  • Router's IP in floating subnet: 154.72.0.10
  • Floating IP that I use to test: 154.72.0.13
  • Private subnet: 10.100.0.0/16
  • Router's IP in private subnet: 10.100.0.1

Pinging the router's IP in the 154.72.0.0/22 subnet works.

$ ping 154.72.0.10
PING 154.72.0.10 (154.72.0.10) 56(84) bytes of data.
64 bytes from 154.72.0.10: icmp_seq=1 ttl=56 time=152 ms

Pinging the floating IP in the same subnet gets an ICMP Destination Host Unreachable reply:

$ ping 154.72.0.13
PING 154.72.0.13 (154.72.0.13) 56(84) bytes of data.
From 154.72.0.13: icmp_seq=1 Destination Host Unreachable

Interfaces in the router's namespace:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 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
  inet6 ::1/128 scope host
    valid_lft forever preferred_lft forever
17: qr-3a8afdbe-20: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
  link/ether fa:16:3e:ac:41:b6 brd ff:ff:ff:ff:ff:ff
  inet 10.100.0.1/16 brd 10.100.255.255 scope global qr-3a8afdbe-20
  inet6 fe80::f816:3eff:feac:41b6/64 scope link
    valid_lft forever preferred_lft forever
18: qg-1aad9421-8f: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
  link/ether fa:16:3e:9b:6d:46 brd ff:ff:ff:ff:ff:ff
  inet 154.72.0.10/24 brd 154.72.0.255 scope global qg-1aad9421-8f
  inet 154.72.0.13/32 brd 154.72.0.13 scope global qg-1aad9421-8f
  inet 154.72.0.16/32 brd 154.72.0.16 scope global qg-1aad9421-8f
  inet6 fe80::f816:3eff:fe9b:6d46/64 scope link
    valid_lft forever preferred_lft forever

Routes in the router's namespace:

default via 154.72.0.1 dev qg-1aad9421-8f 
10.100.0.0/16 dev qr-3a8afdbe-20  proto kernel  scope link  src 10.100.0.1 
154.72 ...
(more)
edit retag flag offensive close merge delete

Comments

good question. Try `iptables-save -c` between pings to find out which chains the packets are getting onto.

darragh-oreilly gravatar imagedarragh-oreilly ( 2014-03-06 06:16:27 -0500 )edit

If you run `tcpdump` on `qr-3a8afdbe-20`, do you see the ICMP requests going out? Do you see anything coming back?

larsks gravatar imagelarsks ( 2014-03-06 08:07:01 -0500 )edit

@darragh-oreilly thanks for the tip i'll try that

mauro.stettler gravatar imagemauro.stettler ( 2014-03-06 10:06:03 -0500 )edit

@larsks no they don't come out on the internal interface. I only see them coming in on the external interface but they don't appear on the internal one.

mauro.stettler gravatar imagemauro.stettler ( 2014-03-06 10:06:57 -0500 )edit