How do I reach a DevStack instance setup on HOST A, from HOST B (located on the same network)? [closed]

asked 2020-04-28 14:23:22 -0500

Pranav Bhatt gravatar image

I've setup two GCP instances, both with an adapter subnet 10.0.3.0/24 (HOST A: 10.0.3.7, HOST B: 10.0.3.6). Both have DevStack setup on them with the following local.conf :

HOST A: https://pastebin.com/m3sXPaz9

HOST B: https://pastebin.com/311qjqbh

According to the documentation, (https://docs.openstack.org/neutron-vpnaas/latest/contributor/testing-with-devstack.html (https://docs.openstack.org/neutron-vp...)):

You can use two DevStack nodes connected by a common “public” network to test VPNaaS. The second node can be set up with the same public network as the first node, except it will use a different gateway IP (and hence router IP).

And,

With DevStack running on East and West and connectivity confirmed (make sure you can ping one router/GW from the other), you can perform these VPNaaS CLI commands.

However, despite following the above AND the following https://stackoverflow.com/questions/59109557/how-to-expose-the-devstack-floating-ip-to-the-external-world (SO question asked here),

I can't get HOST B to ping the Floating IP assigned to a DevStack instance(10.0.3.156) in A.

I have made sure that the Security groups both in GCP and DevStack allow all ingress and egress traffic on all ports. br-ex has the GW of 10.0.3.129, which is also not reachable from HOST B.

An image of the network in HOST A:

https://i.stack.imgur.com/ffxnB.png

I'm also aware of the setup as shown https://docs.openstack.org/devstack/latest/guides/neutron.html (here).

Does my issue have anything to do with how the router is configured?

edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by Pranav Bhatt
close date 2020-04-28 23:20:08.968660

Comments

I don't know Google Cloud, but could it filter traffic that is not destined to host A? After all, GCP knows nothing about 10.0.3.156.

Do you have the same problem in the other direction? Did you run tcpdump to find out where traffic to 10.0.3.156 disappears?

Bernd Bausch gravatar imageBernd Bausch ( 2020-04-28 16:51:52 -0500 )edit

HI! Thank you so much for the tip to use tcpdump !!! Turns out that the firewall for the VMs themselves were blocking the incoming traffic, and a rule change to ufw to allow traffic from the network did the trick!

Pranav Bhatt gravatar imagePranav Bhatt ( 2020-04-28 23:05:39 -0500 )edit