yahoo-eng-team team mailing list archive

[Adriaan Schmidt <adriaan.schmidt@xxxxxxxxxxx>]

Public bug reported:

I started implementing an OpenVPN driver that allows remote client logins to Neutron networks, similar to the patches started and then abandoned by Rajesh Mohan [1].
In my specific use case this allows remote clients to join Neutron networks in a way that allows broadcast/multicast communication with the instances.
There is a PoC with code in gerrit [2].

One point of criticism of the previous implementation was the storage of
VPN server secrets. I addressed this by storing them in Barbican.

There is one questionable detail in the current implementation: IP addresses of remote clients are not assigned by OpenVPN. Instead, during the connection process, a Neutron Port is created, and the IP address is assigned by the Neutron DHCP service. This is ugly, and I didn’t find a good way to clean up those ports when clients disconnect.
But, doing it this way, the only neutron-vpnaas object needed is a vpnservice, so it made a first implementation simpler. I expect to have OpenVPN assign the addresses would also require an endpoint group (to configure the address range for the VPN server) and a site connection (which may require IKE and IPsec policies as well). 

Any feedback is welcome.

[1] https://review.opendev.org/#/c/70274/
[2] https://review.opendev.org/#/c/666282

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: rfe

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1837847

Title:
  [RFE] neutron-vpnaas OpenVPN driver

Status in neutron:
  New

Bug description:
  I started implementing an OpenVPN driver that allows remote client logins to Neutron networks, similar to the patches started and then abandoned by Rajesh Mohan [1].
  In my specific use case this allows remote clients to join Neutron networks in a way that allows broadcast/multicast communication with the instances.
  There is a PoC with code in gerrit [2].

  One point of criticism of the previous implementation was the storage
  of VPN server secrets. I addressed this by storing them in Barbican.

  There is one questionable detail in the current implementation: IP addresses of remote clients are not assigned by OpenVPN. Instead, during the connection process, a Neutron Port is created, and the IP address is assigned by the Neutron DHCP service. This is ugly, and I didn’t find a good way to clean up those ports when clients disconnect.
  But, doing it this way, the only neutron-vpnaas object needed is a vpnservice, so it made a first implementation simpler. I expect to have OpenVPN assign the addresses would also require an endpoint group (to configure the address range for the VPN server) and a site connection (which may require IKE and IPsec policies as well). 

  Any feedback is welcome.

  [1] https://review.opendev.org/#/c/70274/
  [2] https://review.opendev.org/#/c/666282

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1837847/+subscriptions