Allowed_pairs also let's you add MAC addresses. You can also disable port_security at the port level to remove any restrictions.

# neutron port-create net1 --allowed-address-pairs type=dict list=true mac_address=<mac_address>,ip_address=<ip_cidr>

On Tue, Apr 5, 2022 at 3:44 PM lejeczek <peljasz@yahoo.co.uk> wrote:


On 04/04/2022 13:53, Sean Mooney wrote:
> On Mon, 2022-04-04 at 09:04 +0100, lejeczek wrote:
>> Hi guys.
>>
>> Has anybody solved that puzzle?
>> Or perhaps it's not a puzzle at all, I'd imagine might be
>> trivial to experts.
>>
>> First I thought - and only thought so far thus asking here -
>> 'allowed_address_pairs' I'd need but that obviously does not
>> do anything as 'wireguard' creates its own ifaces.
>> So.. how do you get your 'wireguard' in openstack to route
>> (no NAT) to instances' local network(s)?
> i have not done this but i suspect you would need to enable the subnet used by wireguard
> in the allowed adres pairs as you said on the instnace that is hosting the wireguard endpoint.
> then set a staic route in the neutron router so other instance knew how to acess it.
> openstack router set --route destination=<wireguard subnet>,gateway=<host vm ip> <router>
> you might also need to confiure some sequirty group rules but im not certin on the last point.
But doesn't openstack's neutron do some mac "firewalling",
which if it does, would "brake" that wireguard iface
always/anyways, right?
I see that and more weird instance network behavior, when I
set wg iface to use IP on instance's local net, which IP
otherwise work - with allowed_address_pairs - when set as a
secondary IP to a "real" iface.

Also, is what you suggest "admin" end or can be done by
non-admin consumer?

many thanks, L.


> if you run wireguard in a vm it is basicaly becomeing a router which is not something that  we typicaly
> expect vms to do but other service like octavia do this when they deploy loadblancers and the vpn as a service exteion similar
> did this in the past so this should be possibel with the exising api.
>> many thanks, L.
>>