| 2018-01-19 07:11:01 |
Hunt Xu |
bug |
|
|
added bug |
| 2018-01-19 07:12:48 |
Hunt Xu |
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 #1692130)
- 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. |
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 #1692130)
- 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. |
|
| 2018-01-19 07:14:04 |
Hunt Xu |
neutron: assignee |
|
Hunt Xu (huntxu) |
|
| 2018-01-19 11:10:18 |
Hunt Xu |
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 #1692130)
- 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. |
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. |
|
| 2018-02-04 03:30:04 |
Akihiro Motoki |
tags |
vpnaas |
rfe-confirmed vpnaas |
|
| 2018-02-04 03:30:10 |
Akihiro Motoki |
tags |
rfe-confirmed vpnaas |
rfe rfe-confirmed vpnaas |
|
| 2018-02-04 03:30:25 |
Akihiro Motoki |
neutron: importance |
Undecided |
Wishlist |
|
| 2018-02-04 03:30:31 |
Akihiro Motoki |
summary |
VPNaaS: handle local side's tunnel IP in ipsec-site-connection operations |
[RFE] VPNaaS: handle local side's tunnel IP in ipsec-site-connection operations |
|
| 2018-03-01 09:37:29 |
Cao Xuan Hoang |
neutron: status |
New |
Confirmed |
|
| 2018-05-18 13:41:15 |
Miguel Lavalle |
tags |
rfe rfe-confirmed vpnaas |
rfe rfe-triaged vpnaas |
|
| 2018-06-08 14:15:59 |
Miguel Lavalle |
tags |
rfe rfe-triaged vpnaas |
rfe-postponed vpnaas |
|
| 2018-08-20 05:59:41 |
Hunt Xu |
neutron: assignee |
Hunt Xu (huntxu) |
|
|
