update timeout of an ipset entry

[alvaro]

I have been trying to figure out how to update the timeout of an ipset entry, with no luck so far, when using native ipset I would just simply use:

$ ipset add foo 192.168.0.5 -exist

but firewalld doesn't seems to implement this feature according to the manual (man), which is a pretty useful and common.
ip2ban seems to bypass firewalld ipset implmentation and just use it natively, so have I tried but with no success:

ipset creation:
ipset create foo hash:ip timeout 300

direct rule:
firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p TCP -m multiport --dports 22,443 -m set --match-set foo src -j ACCEPT

ipset add
ipset add foo 192.120.11.1

https requests and ssh connection attemp are dropped with no route to host.
as soon as I disable firwalld i can succeffule send request and connecto to ssh.

* I'm using the default zone:
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp0s3
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

firewall-cmd --direct --get-all-rules:
ipv4 filter INPUT 0 -p TCP -m multiport --dports 22,443 -m set --match-set foo src -j ACCEPT

what I'm doing wrong, is this possible with firewalld?

thanks in advance

remember to take care of yourself (stay home, wash your hands and so on)

[Eric Garver]

On Sun, Apr 05, 2020 at 08:58:20PM -0000, alvaro  wrote:
> I have been trying to figure out how to update the timeout of an ipset entry, with no luck so far, when using native ipset I would just simply use:
>
> $ ipset add foo 192.168.0.5 -exist
>
> but firewalld doesn't seems to implement this feature according to the manual (man), which is a pretty useful and common.

Correct. firewalld does

# ipset add foo 192.168.0.5

That is, it omits "-exist". But in some cases people actually want an
error if the entry is already present. firewalld allows querying if the
entry is there. So maybe try this:

# firewall-cmd --ipset foo --query-entry=192.168.0.5 || firewall-cmd --ipset foo --add-entry=192.168.0.5
> ip2ban seems to bypass firewalld ipset implmentation and just use it natively, so have I tried but with no success:
>
> ipset creation:
> ipset create foo hash:ip timeout 300
>
> direct rule:
> firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p TCP -m multiport --dports 22,443 -m set --match-set foo src -j ACCEPT
>
> ipset add
> ipset add foo 192.120.11.1
>
> https requests and ssh connection attemp are dropped with no route to host.
> as soon as I disable firwalld i can succeffule send request and connecto to ssh.

What version of firewalld are you using? If you're using the nftables
backend this makes sense. See the CAVEATS section of
firewalld.direct(5).
Or see here:

https://github.com/firewalld/firewalld/blob/e887c16512abd6a3051b0519ee9af344...
> I'm using the default zone:
>
> public (active)
>   target: default
>   icmp-block-inversion: no
>   interfaces: enp0s3
>   sources:
>   services: cockpit dhcpv6-client ssh
>   ports:
>   protocols:
>   masquerade: no
>   forward-ports:
>   source-ports:
>   icmp-blocks:
>   rich rules:
>
> firewall-cmd --direct --get-all-rules:
> ipv4 filter INPUT 0 -p TCP -m multiport --dports 22,443 -m set --match-set foo src -j ACCEPT

For what it's worth you can do the same thing with a rich rule. Which is
preferable over direct rules. And avoids the issue I linked above.

# firewall-cmd --zone public --add-rich-rule='rule family=ipv4 source ipset=foo service name=ssh accept'
    # firewall-cmd --zone public --add-rich-rule='rule family=ipv4 source ipset=foo service name=https accept'