<div dir="ltr"><div dir="auto">Nice! I reread and meant to say that SNAT transforms the packets to take the source of eth1, not eth0.<div dir="auto"><br></div><div dir="auto">But the logic is the same.</div><div dir="auto"><br></div><div>It's worth mentioning that routers in Openstack essentially do that. But they are a bit less flexible than a VM.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 11, 2022, 6:06 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"><div dir="auto">I actually dig deeper and that’s exactly that, it’s filtered out by iptable that get a special match rule when you don’t disable the security ports or assign any allowed pairs :-)</div><div dir="auto"><br></div><div dir="auto">TBN: Your explication and schema is perfect! I’ll use it to explain this to my teammates that may face it at some point.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 11 mars 2022 à 23:37, Laurent Dumont <<a href="mailto:laurentfdumont@gmail.com" rel="noreferrer" 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">It's a bit hard to see without a diagram but here is my theory.<div><ul><li>Packets from client-vm towards external endpoint exit from eth0.</li><li>Packets arrive to eth1 on router-vm and are allowed because</li><ul><li>security-groups OK</li><li>mac-address + ip_address policy is only applicable to outgoing traffic (that's what I think for now...)</li></ul><li>You have a SNAT in place for eth0.</li><li>Packets leave router-vm from eth0 with the source address becoming the IP of eth0. This is allowed because</li><ul><li>security-groups OK</li><li>mac-address + ip_address policies are applied, but will match the packet since you are SNAT the traffic (and not just routing).</li></ul><li>Packets arrive to ze-internet, traffic returns towards the router-vm.</li><li>Packets arrive to eth0, still valid.</li><li>Packets are processed by iptables which mangles the flow to correct the source IP to the source of the ze-internet.</li><li>Packets try to leave through eth1 but are now invalid because</li><ul><li>security-groups OK</li><li><font color="#ff0000">mac-address + ip_address policies are applied <b>but are now invalid. Source is ze-internet, which Openstack knows is not associated with eth1.</b></font><br></li></ul><li><font color="#000000">If you tcpdump on eth1 of router-vm, you should see the traffic going out since it's before any filtering from ovs on the compute. Either ovs-flows are iptables are used for the actual filtering.</font></li></ul><div><font color="#000000"><br></font></div><div><font color="#000000">At least, that's what I think. I'll run some tests in the lab!</font></div><div><img src="cid:ii_l0mzmu0l1" alt="image.png" style="width: 648px; max-width: 100%;"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 9, 2022 at 4:51 AM Gaël THEROND <<a href="mailto:gael.therond@bitswalk.com" rel="noreferrer" 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"><div dir="auto">I’ve made few test this morning, disabling port security on the MGMT port of VM-A (bastion) indeed did the trick and the traffic started to flow correctly.</div><div dir="auto"><br></div><div dir="auto">I’ve then tested to enable it back and set the allowed_pairs with subnet, it works too, so the issue is definitely what you were pointing out so big shout out to you as this options is so deeply burried on the config/ui that I didn’t thought of it more than that.</div><div dir="auto"><br></div><div dir="auto">Yeah regarding k8s that what I was suspecting, thanks for the confirmation.</div><div dir="auto"><br></div><div dir="auto">However, there is one thing that I can’t get my head around with my simple router installation.</div><div dir="auto"><br></div><div dir="auto">If VM-X send a ping for let say <a href="http://google.com" rel="noreferrer" target="_blank">google.com</a> on its gateway (VM-A), the packet goes with VM-X mac/ip header, then VM-A thanks to the ip_forward know that this packet is belonging to another nic which is having the appropriate default gareway. At this point, we didn’t touched anything on the packet (to my knowledge) so once we reach the SNAT our packet header source IP is changed with the external router connected nic IP, then it flow through dns resolver that answer this IP, once the nic get this response, it just forward it back to the MGMT nic of the bastion which in turn answer to the VM-X mgmt nic without doing any spoofing etc.</div><div dir="auto"><br></div><div dir="auto">I’m feeling that I miss something on the way in here, what did I missed on this flow? At which step VM-A is breaking the law? At forward step?</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 9 mars 2022 à 03:20, Laurent Dumont <<a href="mailto:laurentfdumont@gmail.com" rel="noreferrer" 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">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" rel="noreferrer" 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"><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" rel="noreferrer" 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" rel="noreferrer" 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" rel="noreferrer" 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" rel="noreferrer" 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>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>