Bug 2269002 - iptables drop rules are not applied consistently by tripleo-ansible
Summary: iptables drop rules are not applied consistently by tripleo-ansible
Keywords:
Status: CLOSED DUPLICATE of bug 2276865
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: tripleo-ansible
Version: 17.1 (Wallaby)
Hardware: All
OS: All
high
high
Target Milestone: z4
: 17.1
Assignee: Brendan Shephard
QA Contact: David Rosenfeld
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-03-11 13:07 UTC by Alex Stupnikov
Modified: 2024-12-23 09:24 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-08-14 11:31:46 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-31601 0 None None None 2024-03-11 13:09:42 UTC

Description Alex Stupnikov 2024-03-11 13:07:47 UTC
Description of problem:
Firewall rules to drop packets always get appended to the end of the chain instead of adding them where their rule id suggests. Here is an example from customer's lab:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED /* 000 accept related established rules ipv4 */
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            ctstate NEW /* 001 accept all icmp ipv4 */
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate NEW /* 002 accept all to lo interface ipv4 */
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22 ctstate NEW /* 003 accept ssh from all ipv4 */
...
LOG        all  --  0.0.0.0/0            0.0.0.0/0            ctstate NEW limit: avg 20/min burst 15 /* 998 log all ipv4 */ LOG flags 0 level 4
DROP       all  --  0.0.0.0/0            0.0.0.0/0            state NEW /* 999 drop all ipv4 */
DROP       all  --  0.0.0.0/0            0.0.0.0/0            ctstate NEW /* 999 drop all ipv4 */
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpts:5900:6293 ctstate NEW /* 199 nova_libvirt reject vnc port range from others ipv4 */
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpts:61152:61215 ctstate NEW /* 199 nova_libvirt reject live migration port range from others ipv4 */
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:16514 ctstate NEW /* 199 nova_libvirt reject libvirtd port from others ipv4 */
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:25672 ctstate NEW /* 099 reject rabbitmq inter-node from others ipv4 */
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:5672 ctstate NEW /* 099 reject rabbitmq from others ipv4 */
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:4369 ctstate NEW /* 099 reject rabbitmq epmd from others ipv4 */

From tripleo-ansible code it looks like this drop rules are appended, while others are implicitly inserted
https://github.com/openstack-archive/tripleo-ansible/blob/stable/wallaby/tripleo_ansible/ansible_plugins/action/tripleo_iptables.py#L185


Both THT environment file with ExtraFirewallRules definition and resulting output of iptables command are attached to support case.


Version-Release number of selected component (if applicable):
RHOSP 17.1

How reproducible:
Add a mixture of drop and accept firewall rules via ExtraFirewallRules, then deploy.

Actual results:
DROP rules were added to the end of iptables INPUT chain, while ACCEPT rules were added according to their numbers.

Expected results:
Both DROP and ACCEPT rules were added according to their numbers.

Comment 11 Brendan Shephard 2024-07-30 23:56:01 UTC
This issue should now be resolved by:
https://bugzilla.redhat.com/show_bug.cgi?id=2276865

We render the rules for nftables fresh on each execution. This should now ensure that DROP rules are applied consistently.

Comment 12 pweeks 2024-08-14 11:31:46 UTC

*** This bug has been marked as a duplicate of bug 2276865 ***


Note You need to log in before you can comment on or make changes to this bug.