<div dir="ltr">Any overlay inside the vxlan overlay should work. Since it encapsulates the actual pod/service traffic, Openstack has no clue and happily forwards the traffic since it matches the spec (mac + IP) of the port.<div><br></div><div>Using only security groups will not let you spoof traffic/act as a router.</div><div><ul><li>If you want to keep using security groups, you will need allowed-pairs.</li><ul><li>You can use a subnet as a wildcard / or use the IP address specifically.</li></ul><li>If you dont mind very permissive rules, then disabling port-security will require you to remove security groups + allowed-ip-pairs.</li></ul></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 8, 2022 at 4:59 PM Gaël THEROND <<a href="mailto:gael.therond@bitswalk.com">gael.therond@bitswalk.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Interesting I’ve thought about especially because of the anti-spoofing features but I had the feeling that Security-groups if assigned to the port would have allowed it.</div><div dir="auto"><br></div><div dir="auto">Additionally, what’s really weird is that one of our k8s clusters using flannel and/or calico (depends on the user needs) is actually putting those exact rules (SNAT+FORWARD rules) automatically for pods services ingress access but I’m wondering if it works because the traffic is on a tunnel that the host can’t see.</div><div dir="auto"><br></div><div dir="auto">I’ll have a look at your idea by disabling the port security and check if it work like that. If it works then I’ll re-enable it and work with the allowed-pairs.</div><div dir="auto"><br></div><div dir="auto">Many thanks!</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 8 mars 2022 à 22:13, Laurent Dumont <<a href="mailto:laurentfdumont@gmail.com" target="_blank">laurentfdumont@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">You might want to look at port-security on the bastion host VM. If it's enabled, it means that Openstack will drop any outgoing packets that are not sourced using the ip address + mac AND/OR the allowed_pairs defined on the port.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 8, 2022 at 3:07 PM Gaël THEROND <<a href="mailto:gael.therond@bitswalk.com" target="_blank">gael.therond@bitswalk.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi everyone!<div><br></div><div dir="auto">I’m facing a weird situation on a tenant of one of our Openstack cluster based on Victoria.</div><div dir="auto"><br></div><div dir="auto">On this tenant, the network topology is as follow:</div><div dir="auto"><br></div><div dir="auto">One DMZ network (<a href="http://192.168.0.0/24" target="_blank">192.168.0.0/24</a>) linked to our public network through a neutron router where there is a VM acting as a bastion/router for the MGMT network.</div><div dir="auto"><br></div><div dir="auto">One MGMT network (<a href="http://172.16.31.0/24" target="_blank">172.16.31.0/24</a>) where all VMs are linked to.</div><div dir="auto"><br></div><div dir="auto">On the DMZ network, there is a linux Debian 11, let’s call it VM-A with a Floating IP from the public pool, this VM is both attached to the DMZ network (ens3 / 192.168.0.12) AND the MGMT network (ens4 / 172.16.31.23).</div><div dir="auto"><br></div><div dir="auto">All other VMs, let’s call them VM-X are exclusively attached to the MGMT network (ens4).</div><div dir="auto"><br></div><div dir="auto">I’ve setup VM-A with ip_forward kernel module and the following iptables rule:</div><div dir="auto"><br></div><div dir="auto"># iptables -t nat -A POSTROUTING -o ens3 -J SNAT —to-source 192.168.0.12</div><div dir="auto"><br></div><div dir="auto">My VM-X are on their own setup with a default gateway via VM-A:</div><div dir="auto"><br></div><div dir="auto"># ip route add default via 172.31.16.23</div><div dir="auto"><br></div><div dir="auto">The setup seems to be working as if I don’t put the iptables rule and the kernel forwarding I can’t see any packets on my DMZ interface (ens3) on VM-A from VM-X.</div><div dir="auto"><br></div><div dir="auto">Ok so now that you get the whole schema, let dive into the issue.</div><div dir="auto"><br></div><div dir="auto">So when all rules, modules and gateway are set, I can fully see my VM-X traffic (ICMP ping to a dns server) going from VM-X (ens4) to VM-A (ens4) then forwarded to VM-A (ens3) and finally going to our public IP targeted service.</div><div dir="auto"><br></div><div dir="auto">What’s not working however is the response not reaching back to VM-X.</div><div dir="auto"><br></div><div dir="auto">I’ve tcpdump the whole traffic from VM-X to VM-A on each point of the platfrom:</div><div dir="auto"><br></div><div dir="auto">from inside the VM-X nic, on the tap device, on the qbr bridge, on the qvb veth, on the qvo second side of the veth through the ovs bridges and vice-versa.</div><div dir="auto"><br></div><div dir="auto">However the response packets aren’t reaching back further than on the VM-A qvo veth.</div><div dir="auto">Once it exit the VM-A the traffic never reaches the VM-X.</div><div dir="auto"><br></div><div dir="auto">What’s really suspicious in here is that a direct ping from VM-X (172.16.31.54) to VM-A (172.16.31.23) is coming back correctly, so it looks like if ovs detected that the response on a SNAT case isn’t legit or something similar.</div><div dir="auto"><br></div><div dir="auto">Is anyone able to get such setup working?</div><div dir="auto"><br></div><div dir="auto">Here are few additional information:</div><div dir="auto">Host runs on CentOS 8.5 latest update.</div><div dir="auto">Our platform is a Openstack Victoria deployed using kolla-ansible.</div><div dir="auto">We are using a OVS based deployment.</div><div dir="auto">Our tunnels are VXLAN.</div><div dir="auto">All VMs have a fully open secgroup applied and all ports have it (I checked it twice and even on host iptables).</div><div dir="auto"><br></div><div dir="auto">If you ever need additional information feel free to let me know !</div><div dir="auto"><br></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>