Public bug reported:
Ubuntu version:
# lsb_release -rd
Description: Ubuntu 24.04.4 LTS
Release: 24.04
Package version:
# apt-cache policy resource-agents-extra
resource-agents-extra:
Installed: 1:4.13.0-1ubuntu4
Candidate: 1:4.13.0-1ubuntu4
Version table:
*** 1:4.13.0-1ubuntu4 500
500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages
100 /var/lib/dpkg/status
Expected behavior:
Portblock blocks the port in question when asked to, and unblocks when
asked to.
Actual behavior:
Portblock blocks the port, but cannot unblock the port, and furthermore
duplicates the iptables rule blocking the port.
Analysis:
In the /usr/lib/ocf/resource.d/heartbeat/portblock script, during port
unblocking, iptables output is inspected to determine if the iptables
chain needs to be updated. Function chain_isactive() calls `iptables -n
-L INPUT` and uses the regex returned by function active_grep_pat() to
check if the rule in question is present. If the rule is present, it is
removed. If not, no removal attempt is made. Or, in the case of
blocking, the rule is added only if found to be absent.
The regex uses the "protocol" parameter, among other criteria, to be
sure that only the correct rule is matched. This parameter is defined as
a string and in all examples string names are used such as "tcp" and
"udp".
However, iptables no longer prints the stringified protocol name when
the `-n` flag is passed:
No -n flag:
# iptables -L INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP tcp -- anywhere k8snfs.scc.net.davepedu.com multiport
dports nfs
With -n flag:
# iptables -n -L INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP 6 -- 0.0.0.0/0 10.130.12.151 multiport dports
2049
This causes the portblock script to think that the rule is not present,
and thus does not attempt to remove the rule. In my use case, an NFS
server, this leaves port 2049 blocked and clients cannot connect.
Furthermore, the rule becomes duplicated since this check is also used
to determine if the rule is already present when blocking. Since the
rule is never found, it is added again.
At some point in the past, the `-n` flag in iptables did not cause the
protocol to be printed numerically in addition to port numbers, ip rdns,
etc. I can infer from this that the script was written for an older
version of iptables than what Ubuntu currently ships, but no longer
works with the version shipped on my OS version.
This bug can be trivially worked around by specifying the protocol
number instead of name when creating a portblock resource:
# pcs resource create portblock portblock \
action=block \
ip=10.0.0.0/8 \
portno=2049 \
protocol=6 <---- "6", instead of "tcp"
** Affects: resource-agents (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2145785
Title:
portblock does not work due to iptables changes
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/2145785/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
