Open Stack

Hi Paul,

Apologies for late response. I was having throat infection.




> Can you show the ipsec-site-connection-create command used on each end?
>


neutron ipsec-site-connection-create --name vpnconnection1 --vpnservice-id
myvpn --ikepolicy-id ikepolicy1 --ipsecpolicy-id ipsecpolicy1
--peer-address <public address> --peer-id <q-router-ip> --peer-cidr
10.2.0.0/24 --psk secret


   - In the above command: --peer-address is the public ip of the node
   having devstack setup -- you can call it devstack West
   - --peer-id: we are giving the ip of the q-router


Make sense?



> Can you show the topology with IP addresses used (and indicate how the two
> clouds are connected)?
> Are you using devstack? Two physical nodes? How are they interconnected?
>

We are using exactly the same topology as shown below even the floating ip
addresses are same one mentioned below. However, Our Internet gateway is a
public ip. Similarly, other Internet GW is also a public ip.

      (10.1.0.0/24 - DevStack *East*)
              |
              |  10.1.0.1
     [Quantum Router]
              |  172.24.4.226
              |
              |  172.24.4.225
     [Internet GW]
              |
              |
     [Internet GW]
              | 172.24.4.232
              |
              | 172.24.4.233
     [Quantum Router]
              |  10.2.0.1
              |
     (10.2.0.0/24 DevStack *West*)



> First thing would be to ensure that you can ping from one host to another
> over the public IPs involved. You can then go to the namespace of the
> router and see if you can ping the public I/F of the other end’s router.
>

We can ping anything on the host having devstack setup for example
google.com, but GW of the other host. However, we cannot ping from within
the CirrOS instance. I have run the traceroute command and we are reaching
till 172.24.4.225 but not beyond this point. BTW we did some other
experiments as well. For example, when we tried to explicitly link our
br-ex (172.24.4.225) with eth0 (Internet GW), machine got corrupted. Same
is the issue if we do a hard reboot, Neutron gets corrupted :)


>
> You can look at the screen-q-vpn.log (assuming devstack used) to see if
> any errors during setup.
>
> Note: When I stack, I turn off neutron security groups and then set nova
> security groups to allow SSH and ICMP. I imagine the alternative would be
> to setup neutron security groups to allow these two protocols.
>
> I didn’t quite follow what you meant by "Please note that my two devstack
> nodes are on different public addresses, so scenario is a little different
> than the one described here:
> https://wiki.openstack.org/wiki/Neutron/VPNaaS/HowToInstall”. Can you
> elaborate (showing the commands and topology will help)?
>
> Germy,
>
> I have created this BP during Juno (unfortunately no progress on it
> however), regarding being able to see more status information for
> troubleshooting:
> https://blueprints.launchpad.net/neutron/+spec/l3-svcs-vendor-status-report
>
> It was targeted for vendor implementations, but would include reference
> implementation status too. Right now, if a VPN connection negotiation
> fails, there’s no indication of what went wrong.
>
> Regards,
>
>
> PCM (Paul Michali)
>
> MAIL …..…. pcm at cisco.com
> IRC ……..… pcm_ (irc.freenode.com)
> TW ………... @pmichali
> GPG Key … 4525ECC253E31A83
> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
>
>
>
> On Sep 29, 2014, at 1:38 AM, masoom alam <masoom.alam at gmail.com> wrote:
>
> Hi Germy
>
> We cannot ping the public interface of the 2nd devstack setup (devstack
> West). From our Cirros instance (First devstack -- devstack east), we can
> ping our own public ip, but cannot ping the other public ip. I think
> problem lies here, if we are reaching the devstack west, how can we make a
> VPN connection
>
> Our topology looks like:
>
> *CirrOS --->Qrouter---->Public IP -------publicIP---->Qrouter----->CirrOS*
> _________________________             _____________________________
>        devstack EAST                                        devstack WEST
>
>
> Also it is important to note that we are not able to ssh the instance
> private ip, without *sudo ip netns qrouter id *so this means we cannot
> even ssh with floating ip.
>
>
> it seems there is a problem in firewall or iptables.
>
> Please guide
>
>
>
> On Sunday, September 28, 2014, Germy Lure <germy.lure at gmail.com> wrote:
>
>> Hi,
>>
>> masoom:
>> I think firstly you can just check that if you could ping from left to
>> right without installing VPN connection.
>> If it worked, then you should cat the system logs to confirm the
>> configure's OK.
>> You can ping and tcpdump to dialog where packets are blocked.
>>
>> stackers:
>> I think we should give mechanism to show the cause when vpn-connection is
>> down. At least, we could extend an attribute to explain this. Maybe the
>> VPN-incubator project is a chance?
>>
>> BR,
>> Germy
>>
>>
>> On Sat, Sep 27, 2014 at 7:04 PM, masoom alam <masoom.alam at gmail.com>
>> wrote:
>>
>>> Hi Every one,
>>>
>>> I am trying to establish the VPN connection by giving the neutron
>>> ipsec-site-connection-create.
>>>
>>> neutron ipsec-site-connection-create --name vpnconnection1 --vpnservice-id myvpn --ikepolicy-id ikepolicy1 --ipsecpolicy-id ipsecpolicy1 --peer-address 172.24.4.233 --peer-id 172.24.4.233 --peer-cidr 10.2.0.0/24 --psk secret
>>>
>>>
>>> For the --peer-address I am giving the public interface of the other
>>> devstack node. Please note that my two devstack nodes are on different
>>> public addresses, so scenario is a little different than the one described
>>> here: https://wiki.openstack.org/wiki/Neutron/VPNaaS/HowToInstall
>>>
>>> The --peer-id is the ip address of the Qrouter connected to the public
>>> interface. With this configuration, I am not able to up the VPN site to
>>> site connection. Do you think its a firewall issue, I have disabled both
>>> firewalls with sudo ufw disable. Any help in this regard. Am I giving the
>>> correct parameters?
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>  _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141001/8707df5c/attachment.html>