)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"79e08dfd4ad028f4425a929e86f81175833f71c3","unresolved":true,"context_lines":[{"line_number":21,"context_line":"would ingress via an interface that neutron is not"},{"line_number":22,"context_line":"aware of, iptables would not match it, and the"},{"line_number":23,"context_line":"traffic would be accepted. Having a defined set of"},{"line_number":24,"context_line":"protected iptables chains helps to mitigate this"},{"line_number":25,"context_line":"potential security vulnerability."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Change-Id: I2addb7c9239e273d52e89c9bdd61e95354f813f5"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"4b6d2243_9eb11bf1","line":25,"range":{"start_line":24,"start_character":35,"end_line":25,"end_character":33},"updated":"2021-10-20 13:08:19.000000000","message":"Actually this patch is introducing a security vulnerability. Any egress/ingress traffic handled by the iptables FW should not be override by something like you propose. If the traffic you need to introduce in this VM does not match the SG rules created, add new ones.\n\nIf those SG rules are not valid, maybe use allowed-address-pairs. And if this is not enough, disable port security for a specific port.\n\nBut I don\u0027t recommend a feature like this.","commit_id":"208f57dda239815b4965f11ccebb271b49876638"},{"author":{"_account_id":33525,"name":"Anthony","email":"atimmins@datto.com","username":"atimmins"},"change_message_id":"183918fe892214742d068797897c3a5d43c68ac0","unresolved":true,"context_lines":[{"line_number":21,"context_line":"would ingress via an interface that neutron is not"},{"line_number":22,"context_line":"aware of, iptables would not match it, and the"},{"line_number":23,"context_line":"traffic would be accepted. Having a defined set of"},{"line_number":24,"context_line":"protected iptables chains helps to mitigate this"},{"line_number":25,"context_line":"potential security vulnerability."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Change-Id: I2addb7c9239e273d52e89c9bdd61e95354f813f5"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"2e499d69_f41c58c7","line":25,"range":{"start_line":24,"start_character":35,"end_line":25,"end_character":33},"in_reply_to":"4b6d2243_9eb11bf1","updated":"2021-10-20 13:44:17.000000000","message":"Thanks for taking a look at this! The specific problem we are facing is that we have routed traffic to a VM incoming via a Layer3 VXLAN interface. When this traffic hits iptables, the PHYSDEV-IN is the VXLAN interface, not the TAP interface for the VM. Therefore, none of the iptables rules created by neutron are matched, and the traffic is accepted. Ideally, we want this routed traffic to the VM to use the same iptables chains as bridged traffic. Rather than duplicating all of the rules, and changing PHYSDEV-IN to be the VXLAN interface instead of the TAP interface, it seems more efficient to simply redirect traffic to the existing chains.","commit_id":"208f57dda239815b4965f11ccebb271b49876638"}]}