DNAT of floating IPs on Neutron server doesn't work, incoming packets get swallowed
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 ...
good question. Try `iptables-save -c` between pings to find out which chains the packets are getting onto.
If you run `tcpdump` on `qr-3a8afdbe-20`, do you see the ICMP requests going out? Do you see anything coming back?
@darragh-oreilly thanks for the tip i'll try that
@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.