In use cases where the VPN functionality is provided outside of the neutron
router (e.g. separate appliance, VM, H/W, external S/W), the local side's
tunnel IP address for IPSec connections will not be the Neutron router's GW
IP. As a result, if a connection is established, the user will have no way of
knowing the peer's external IP (no way to query it).
To support this we'll let the service driver determine the public facing
tunnel IP for this side (called external_ip internally for IPsec drivers),
and will store it in the service table. This will be used for every
connection created for that service (instead of looking up the router's GW IP),
and will be available via the GET API, so that the external IP can be obtained
and then specified by the peer end, when setting up an IPSec connection.
Keep in mind, however, when IPSec connections are created today, they will
select the GW IP based on the IP version of the peer's address. There could
be one connection using a V6 IP and another using a V4 IP.
To handle this, we'll use two entries in the service table to hold IPv4
and/or IPv6 tunnel IPs.
For the existing implementations, the external IP is the router's GW IP, so
the default service driver will store that information (again, IPv4 and/or
IPv6). Each IPSec connection will use the appropriate IP version, based on
peer's IP version (as is done today).
Note: The current code does not make sure there is an external IP with the
same IP version as the peer address. A separate commit could add validation
code to make sure that one exists, and if not, reject the IPSec connection.
For database migration, the new field will be populated from the router's
GW IP address(s). Since there is not a grenade job available for VPN
currently, the migration was tested manually.
Change-Id: I0cdded5105ad8000131e39a86cbfa80ed89ae37b
Closes-Bug: 1464387
b6cf05de21