neutron

Bug #1837847
Comment #22

Comment 22 for bug 1837847

Revision history for this message

Slawek Kaplonski (slaweq) wrote on 2019-12-17: Re: [Bug 1837847] [RFE] neutron-vpnaas OpenVPN driver

#22

Hi,

> On 17 Dec 2019, at 12:05, Adriaan Schmidt <email address hidden> wrote:
>
> I've uploaded an updated version of the spec
> (https://review.opendev.org/#/c/680990) and the implementation
> (https://review.opendev.org/#/c/666282/).

I will try to review the spec soon but I’m not vpnaas expert so others will also have to look at it.

>
> Regarding the spec: I resolved the issue we discussed (creation of ports
> for remote VPN clients). There still are a few open questions.
>
> Regarding implementation: I changed communication between the OpenVPN
> callback/hook and the agent as suggested in #19. My current draft can be
> run in devstack, and I am now looking into writing tests.
>
> Do you think it is realistic to have the OpenVPN feature included in the
> upcoming ussuri release?

Theoretically, if we will go with spec fast, I think it’s still doable to get it into Ussuri.
But it’s matter of reviews speed and if we look into vpnaas project velocity currently, it may be hard.
I think You will need to talk mostly with Akihiro Motoki and Takashi Yamamoto who are most active neutron-vpnaas reviewers today.

>
> --
> You received this bug notification because you are subscribed to
> neutron.
> Matching subscriptions: Neutron bugs
> https://bugs.launchpad.net/bugs/1837847
>
> Title:
> [RFE] neutron-vpnaas OpenVPN driver
>
> Status in neutron:
> Triaged
>
> 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
>

—
Slawek Kaplonski
Senior software engineer
Red Hat

Hi,

> On 17 Dec 2019, at 12:05, Adriaan Schmidt <adriaan.schmidt@siemens.com> wrote:
> 
> I've uploaded an updated version of the spec
> (https://review.opendev.org/#/c/680990) and the implementation
> (https://review.opendev.org/#/c/666282/).

I will try to review the spec soon but I’m not vpnaas expert so others will also have to look at it.

> 
> Regarding the spec: I resolved the issue we discussed (creation of ports
> for remote VPN clients). There still are a few open questions.
> 
> Regarding implementation: I changed communication between the OpenVPN
> callback/hook and the agent as suggested in #19. My current draft can be
> run in devstack, and I am now looking into writing tests.
> 
> Do you think it is realistic to have the OpenVPN feature included in the
> upcoming ussuri release?

> 
> -- 
> You received this bug notification because you are subscribed to
> neutron.
> Matching subscriptions: Neutron bugs
> https://bugs.launchpad.net/bugs/1837847
> 
> Title:
>  [RFE] neutron-vpnaas OpenVPN driver
> 
> Status in neutron:
>  Triaged
> 
> 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
>

— 
Slawek Kaplonski
Senior software engineer
Red Hat