Public bug reported:
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.
** Affects: neutron
Importance: Undecided
Assignee: Hunt Xu (huntxu)
Status: New
** Tags: vpnaas
** Description changed:
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
+ - 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.
** Changed in: neutron
Assignee: (unassigned) => Hunt Xu (huntxu)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1744223
Title:
VPNaaS: handle local side's tunnel IP in ipsec-site-connection
operations
Status in neutron:
New
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 #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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1744223/+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
