[RFE] VPNaaS: handle local side's tunnel IP in ipsec-site-connection operations

Bug #1744223 reported by Hunt Xu
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Confirmed
Wishlist
Unassigned

Bug Description

During fixing bug #1464387, we stores local side's tunnel IP in the database for later retrieval, in order to support the use case that VPN service is provided outside of the Neutron router.

However, for the default IPsec service provider, the local tunnel IPs(external_v*_ip) are only set when A VPN service is created, and never have a chance to get updated. This leads to the following problems:
  - User cannot create IPsec site connection with IPv6 peer address if the
    router is not connected to an external IPv6 subnet upon the creation
    of the VPN service, even though it is connected before the creation
    of the IPsec site connection
  - If router gateway's IP changes after the VPN service is created,
    later-created IPsec site connections would still use the one that was
    stored in the db instead of the new correct one
  - Router gateway's IP cannot be changed even when it is not used by any
    active/enabled IPsec site connections (related to bug #1743791)
  - Currently there is no checking to ensure the VPN service has an
    external IP with the same IP version as the peer address upon the
    creation of IPsec site connection

As today the VPN endpoint groups separate the "what gets connected" from the "how to connect" for a VPN service. The local side's tunnel IP should be considered a part of "how to connect" and thus it should be handled during ipsec-site-connection operations, instead of only set upon the creation of a VPN service.

Hunt Xu (huntxu)
description: updated
Changed in neutron:
assignee: nobody → Hunt Xu (huntxu)
Hunt Xu (huntxu)
description: updated
Akihiro Motoki (amotoki)
tags: added: rfe-confirmed
tags: added: rfe
Changed in neutron:
importance: Undecided → Wishlist
summary: - VPNaaS: handle local side's tunnel IP in ipsec-site-connection
+ [RFE] VPNaaS: handle local side's tunnel IP in ipsec-site-connection
operations
Revision history for this message
YAMAMOTO Takashi (yamamoto) wrote :

do you have a suggestion how to improve it?
add local_address field to ipsec-site-connection?

Revision history for this message
Hunt Xu (huntxu) wrote :

@yamamoto, I am working on this. My idea is to only update the external_v*_ip of vpnservices upon ipsec-site-connection creation/updating/deleting. The external_v*_ip would be None if the vpnservice is not used by any ipsec-site-connections. Thus operations of the router gateway won't be blocked.

Revision history for this message
YAMAMOTO Takashi (yamamoto) wrote :

i'm not sure if i understand use cases.
do you want to keep a vpn service without site connections for some reasons?
otherwise you can remove the vpn service, update the router gateway, and then re-create a vpn service, right?

Cao Xuan Hoang (hoangcx)
Changed in neutron:
status: New → Confirmed
Revision history for this message
Miguel Lavalle (minsel) wrote :

@Hunt Xu,

Any follow up response to Takashi's questions? A reply would go a long way helping the drivers team to make a decision on this RFE

Revision history for this message
Hunt Xu (huntxu) wrote :

Hey guys, sorry for the late response.

@yamamoto, it is not about to keep a vpn service without site connections. Remove the vpn service can solve the problem when it would be only used by one site connection, however it is not true when one vpn service would be used by multiple site connections.

Consider the following scenario:
1. I have a router connected to the public network with only an external IPv4 address, an internal subnet is connected to this router.
2. I setup a vpn site connection to connect the subnet to a remote one, say peerA.
3. Now I want to connect the subnet to another peer(peerB) via the public IPv6 network. I can give the router an external IPv6 address, however I can't setup the new site connection with IPv6 peer because the external_v6_ip of the vpn service is empty. The only way now is to delete the site connection to peerA, then delete and recreate the vpn service, then create both site connections.

Revision history for this message
Miguel Lavalle (minsel) wrote :

Let's bring this up to the drivers meeting

tags: added: rfe-triaged
removed: rfe-confirmed
Revision history for this message
Miguel Lavalle (minsel) wrote :

We discussed this RFE during today's Drivers meeting. We want to make sure that the scope is only to be able to update external_v6_ip. Please confirm

Revision history for this message
Miguel Lavalle (minsel) wrote :

@Hunt Xu,

Would you help us answering the question in #7? Is there still interest to pursue this RFE

Revision history for this message
Miguel Lavalle (minsel) wrote :

@Hunt Xu,

We have marked this RFE as postponed. If you still have interest in pursuing it, please:

1) Answer to the question in #7
2) Change the tag field of this bug from rfe-postponed to rfe-triaged

With these two steps, we will discuss it again in the drivers meeting

tags: added: rfe-postponed
removed: rfe rfe-triaged
Hunt Xu (huntxu)
Changed in neutron:
assignee: Hunt Xu (huntxu) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.