yahoo-eng-team team mailing list archive

[Hunt Xu <1744223@xxxxxxxxxxxxxxxxxx>]

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