left=<ipv6_addr> not allowed when gw has both v4 & v6 address

Bug #1450479 reported by venkata anil
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Medium
venkata anil

Bug Description

No ipv6 address assigned to ipsec.conf 'left' and "leftid" paramter if gateway has both ipv4 and ipv6 addresses.
Gateway has both ipv4 and ipv6 address as public network has both ipv4 and ipv6 subnets.
I am trying vpn-service and ipsec-site-connection create with ipv6,

neutron vpn-service-create --name myvpn --description "My vpn service" router1 ipv6-private-subnet
neutron ipsec-site-connection-create --name vpnconnection2 --vpnservice-id myvpnB --ikepolicy-id ikepolicy --ipsecpolicy-id ipsecpolicy --peer-address 2001:db8::3 --peer-id 2001:db8::3 --peer-cidr fd8c:26c9:6aef::/64 --psk secret

Still only ipv4 address is assigned to "left" and "leftid" params in ipsec.conf.
As I am trying ipsec-site-connection with ipv6(gave ipv6 subnet during vpn-service-create), ipv6 address should be assigned to these params.

cat /opt/stack/data/neutron/ipsec/909081d8-db4c-4644-8cea-c52db27bd7e6/etc/ipsec.conf
conn 7ca1246e-8fd8-416a-9b39-f1b936760c59
    keyexchange=ikev1
    left=172.24.4.3
    leftsubnet=fd8c:26c9:6aef::/64
    leftid=172.24.4.3
    leftfirewall=yes
    right=2001:db8::4
    rightsubnet=1001::/64
    rightid=2001:db8::4
    auto=route

I think we are always selecting the first address for "external_ip" for vpn_service

def make_vpnservice_dict(self, vpnservice):
        vpnservice_dict['external_ip'] = vpnservice.router.gw_port[
            'fixed_ips'][0]['ip_address']

Need to fix this based on ip version.

Tags: ipv6 vpnaas
Revision history for this message
venkata anil (anil-venkata) wrote :

This is happening for both openswan and strongswan drivers, and only when the public external network has both ipv4 and ipv6 subnets(i.e router gateway port has both ipv4 and ipv6 address.)

Changed in neutron:
assignee: nobody → venkata anil (anil-venkata)
tags: added: vpnaas
summary: - [IPv6] [VPNaaS]left=<ipv6_addr> not allowed when gw has both v4 & v6
- address
+ left=<ipv6_addr> not allowed when gw has both v4 & v6 address
tags: added: ipv6
Changed in neutron:
importance: Undecided → Medium
Changed in neutron:
status: New → In Progress
Revision history for this message
John Joyce (joycej) wrote :

Based on the description of this problem it is possible these is also a problem for the the case that no external subnet is defined. This can occur for IPv6 as the neutron router and the upstream gateway router can use LLA to pass packets. https://review.openstack.org/#/c/156283/43 describes the case and added the changes to allow this scenario to work for general IPv6 traffic. It would be interesting to check if it is possible to set up the IPv6 tunnel when no external IPv6 subnet is defined.

Revision history for this message
venkata anil (anil-venkata) wrote :

Thanks John Joyce for the important info.

This is from strongswan wiki https://wiki.strongswan.org/projects/strongswan/wiki/IPv6Examples4
"Please be aware that the strongSwan pluto and charon IKE daemons cannot listen on IPv6 link-local addresses (fe80:..). You must assign a site-local, unique-local, or global IPv6 address to the physical network interface first"

So strongswan won't work with linklocal address assigned to gateway.

From the https://review.openstack.org/#/c/156283/43 I see 3 scenarios
1) Link local address for the neutron gateway and upstream router(i.e ipv6_gateway) . Adding default route in router with upstream router LLA.
As strongswan won't work with linklocal address assigned to router gateway, user can't use this approach(i.e depending only on LLA to connect to external network) for ipsec

2)router gateway autoconfigures GUA from the prefix recieved trough RA from upstream router.
In this case neutron is unaware of this GUA as it is assigned externally. This may change as prefix from upsteam router may be periodically changing.
So can't have ipsec vpn in this scenario also.

3)external network will have ipv6 subnet. This is the normal use case and we can we have GUA to router gateway, which neutron is aware of. VPN ipsec can be supported in this scenario.

So to support ipsec vpn with ipv6, we can say to the user that, external network must have ipv6 subnet.
Please correct me if I am wrong.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron-vpnaas (master)

Fix proposed to branch: master
Review: https://review.openstack.org/181842

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron-vpnaas (master)

Reviewed: https://review.openstack.org/181842
Committed: https://git.openstack.org/cgit/openstack/neutron-vpnaas/commit/?id=0003f936b040a16ee9c1f72de7702cb083d41d9d
Submitter: Jenkins
Branch: master

commit 0003f936b040a16ee9c1f72de7702cb083d41d9d
Author: venkata anil <email address hidden>
Date: Mon May 18 14:14:15 2015 +0000

    Assign external_ip based on ip version of peer_address

    In the same ipsec site connection, external_ip and peer_address
    should be of same ip version for *Swan.
    So external_ip should be assigned from router gateway addresses
    based on ip version of peer_address.

    Ipsec won't work with IPv6 LLA and neutron unaware GUA.
    So to support vpnaas with ipv6, external network must have ipv6 subnet.

    DocImpact
    a, In the same ipsec site connection, external_ip and peer_address
       should be of same ip version for *Swan.
    b, To support vpnaas with ipv6, external network must have ipv6 subnet,
       as ipsec won't work with IPv6 LLA and neutron unaware GUA.
    Change-Id: Id6ce9939d448d7d009af491ae3d49ba5e1efb9cf
    Closes-bug: #1450479

Changed in neutron:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in neutron:
milestone: none → liberty-1
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in neutron:
milestone: liberty-1 → 7.0.0
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.