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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
