Open Stack

Hi,

I'll respond to my own question in case someone else is looking for  
something similar.
It turned out that the customer tried to do this with IKEv1 instead v2  
(I know, v2 is not really "new"). After configuring both sites to use  
v2 the tunnel excepted both peer endpoints.

They also had a flaw in the network design which prevented a  
many-to-many connection through the same tunnel. They're reworking it,  
so for now this question can be considered as closed.

Regards,
Eugen


Zitat von Eugen Block <eblock at nde.ag>:

> Hi all,
>
> is anyone here able to help with a vpn issue?
> It's not really my strong suit but I'll try to explain.
> In a Rocky environment (using openvswitch) a customer has setup a  
> VPN service successfully, but that only seems to work if there's  
> only one local and one peer endpoint group. According to the docs it  
> should work with multiple endpoint groups, as far as I could tell  
> the setup looks fine and matches the docs (don't create the subnet  
> when creating the vpn service but use said endpoint groups).
>
> What we're seeing is that as soon as the vpn site connection is  
> created with multiple endpoints only one of the destination IPs is  
> reachable. And it seems as if it's always the first in the list of  
> EPs (see below).
>
> This seems to be reflected in the iptables where we also only see  
> one of the required IP ranges. Also neutron reports duplicate rules  
> if we try to use both EPs:
>
> 2020-02-12 14:14:27.638 16275 WARNING  
> neutron.agent.linux.iptables_manager  
> [req-92ff6f06-3a92-4daa-aeea-9c02dc9a31c3  
> ba9bf239530d461baea2f6f60bd301e6 850dad648ce94dbaa5c0ea2fb450bbda -  
> - -] Duplicate iptables rule detected. This may indicate a bug in  
> the iptables rule generation code. Line: -A  
> neutron-l3-agent-POSTROUTING -s X.X.252.0/24 -d Y.Y.0.0/16 -m policy  
> --dir out --pol ipsec -j ACCEPT
>
> These are the configured endpoints:
>
> root at control:~ # openstack vpn endpoint group list
> +--------------------------------------+-----------------+--------+------------------------------------------------------------------------------------+
> | ID                                   | Name            | Type   |  
> Endpoints                                                             
>               |
> +--------------------------------------+-----------------+--------+------------------------------------------------------------------------------------+
> | 0f853567-e4bf-4019-9290-4cd9f94a9793 | peer-ep-group-1 | cidr   |  
> [u'X.X.253.0/24']                                                     
>            |
> | 152a0f9e-ce49-4769-94f1-bc0bebedd3ec | peer-ep-group-2 | cidr   |  
> [u'X.X.253.0/24', u'Y.Y.0.0/16']                                      
>         |
> | 791ab8ef-e150-4ba0-ac2c-c044659f509e | local-ep-group1 | subnet |  
> [u'38efad5e-0f1e-4e36-8995-74a611bfef41']                             
>               |
> | 810b0bf2-d258-459b-9b57-ae5b491ea612 | local-ep-group2 | subnet |  
> [u'38efad5e-0f1e-4e36-8995-74a611bfef41',  
> u'9e35d80f-029e-4cc1-a30b-1753f7683e16'] |
> | b5c79e08-41e4-441c-9ed3-9b02c2654173 | peer-ep-group-3 | cidr   |  
> [u'Y.Y.0.0/16']                                                       
>            |
> +--------------------------------------+-----------------+--------+------------------------------------------------------------------------------------+
>
>
> Has anyone experience with this and could help me out?
>
> Another follow-up question: how can we gather some information  
> regarding the ipsec status? Althoug there is a active tunnel we  
> don't see anything with 'ipsec statusall', I've checked all  
> namespaces on the control node.
>
> Any help is highly appreciated!
>
> Best regards,
> Eugen