I'm trying to understand the correlation of the parameters hashsize, maxelem and bucketsize for ipsets and their behavior if and if not referenced by iptables. With "understand" I also mean "derive meaningful recommendations and implications for setup planning". Probably the easiest is maxelem, but as I found contradicting information, I want to clarify as well: This is the maximum amount of elements stored in the set, completely independent of the other values. It's specified during the create command and cannot be adjusted later on. bucketsize for itself is probably easy enough by itself as well. Assuming it's set to 2 and we have two elements which generate the same hash, the bucket is full. It becomes more interesting later on. hashsize is described as the initial hash size of the set. It's also mentioned that to avoid clashes and a limited number of chaining (what is this? Is chaining referring to the bucket?) doubling of the hash size is performed. Assuming I have hashsize 64, maxelem 1000 and bucketsize 2 I understand the hashtable has 64 lines/fields and the corresponding memory reserved. Assuming I add elements which generate perfectly spread hashes, adding the 65th element would fill the first bucket. With the 128th element being added, all buckets would be full. It becomes interesting when the 129th element is added. It would be added to a already full bucket and therefore leading to the hashsize being doubled, making it 128. This would trigger a re-hashing of all elements and assuming a perfect spread, putting a single element per bucket, except one bucket which as 2 elements. Assuming a not perfect spread, leading to three elements in a bucket, this would lead to another round of doubling and rehashing, getting us to 256 hashsize and respectively higher memory usage. Let's call this process **resizing** for reference below. This pretty much goes on, until we want to add the 1001th element, which is blocked due to maxelem being reached, no respect given to the other properties. If an iptable references the ipset, resizing does not happen, no matter what. The theoretical maximum of elements stored in an ipset is therefore the lower of 'maxelem' or 'hashsize * bucketsize'. Performance implications: Hashing is about O(1), so the hashsize does not affect the performance really. Compare operations may be required for each entry in the bucket, which are always in addition to the hash operation, so the bigger the bucketsize, the slower. Memory implications: The higher the hashsize, the more memory needs to be reserved. I would have assumed that doubling the hashsize doubles the memory but a test with ipset v7.19 revealed that for hashsize <= 1024 the Size in memory: is always 456. The following table show the consumption on an empty set and with one element: |hashlen|Empty Set (Bit in memory) |Empty Set. Diff to prev.| Mem with 1 ele.| Element Mem. in Bit | |-|-|-|-|-| |<=1024|456|-|504|48| |2048|480|24|528|48| |4096|528|48|576|48| |8192|624|96|672|48| |16384|816|192|864|48| |...|...|...|...|48| |1048576 (2^20)|25008|...|...|48| |16777216 (2^24)|393648|...|...|48| From the numbers I derive that on any modern system which is not **very** restricted on memory, I don't see any reason to not use the biggest meaningful hashsize and smallest possible bucketsize. So the overall memory consumption depends **way** more on the amount of stored elements than the hashlen **Personal recommendation and interpretation**: I would derive a rule of thump of "Amount of expected entries * 8" for hashsize and a bucketsize of 14. This should leave one with very good performance, reasonable memory consumption and especially very unlikely issues with restriction put in place by iptables, which makes resizing of existing sets impossible while referenced. Bucketsize 14 does not have any effect really if only one entry is in, and with using the maximum, making it very unlikely issues ever occur - so nothing lost, especially as extending hashsize not possible once referenced by iptables. Now the question(s): - Is my interpretation of the parameters and their mutual impact correct? - Is anything off with my interpretation of the memory results? I wonder especially as 1024 is very little (would cover ~125 entries in my recommendation).

I am trying to write an iptables rule using ipset with one rule matching *src* or *dst* (or both). This iptables -A FORWARD -m set --match-set src,dst -j DROP does **not** work since it applies only if both *src* AND *dst* are in the *name_of_ipset*. I know that I could simply double the rule via iptables -A FORWARD -m set --match-set src -j DROP iptables -A FORWARD -m set --match-set dst -j DROP but I hope that there is **something more simple**?!

I'm trying to move an ipset to an nftables set:

[my-host]# ipset-translate restore <<< 'create foonet_iface hash:net,iface family inet hashsize 1024 maxelem 65536'
add table inet global
add set inet global foonet_iface { type ipv4_addr . ifname; size 65536; flags interval; }
[my-host]# ipset-translate restore <<< 'create foonet_iface hash:net,iface family inet hashsize 1024 maxelem 65536' | xargs -d '\n' -n1 nft
Error: Could not process rule: Operation not supported
add set inet global foonet_iface { type ipv4_addr . ifname; size 65536; flags interval; }
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[my-host]#

The equivalent seems to be a set of type ipv4_addr . ifname with the interval flag. But I don't seem to be able to create it. Kernel version is 5.4

I'm trying to configure a firewall (using iptables on a Docker host) that allows inbound HTTP and HTTPS from everywhere, SSH from a certain set of IPs and no other incoming connections. I liked what I read about ipset, as it seems to be easier to configure than raw iptables and also allows easier automated re-configuration of sets. But somehow it does not seem to work: I'm not able to connect via HTTPS, albeit port 443 should be open. SSH connections work (albeit I haven't tried to lock myself out). While trying to debug this issue, I added counters to the various sets in ipset. But they stay at 0, albeit the counters in iptables increase. Why aren't my connections counted in ipset? Are there other/better ways for debugging list:set? And how can I fix it? Here is the firewall script (intention: allow port 22 from 93.241.223.2, anything on port 80 and 443, and nothing else):

#!/bin/sh

# suffix for set names, to avoid overwriting old sets
timestamp=$(date +%s)

# allow HTTP in general (duplicate sets are due to automated generation of script)
ipset create mds-c-allowhttp4-$timestamp bitmap:port range 0-1024 counters
ipset add mds-c-allowhttp4-$timestamp 80
ipset add mds-c-allowhttp4-$timestamp 443
ipset create mds-c-allowhttp6-$timestamp bitmap:port range 0-1024 counters
ipset add mds-c-allowhttp6-$timestamp 80
ipset add mds-c-allowhttp6-$timestamp 443

# create set with allowed IPv4 ssh connections
ipset create mds-c-allowssh4-$timestamp hash:ip,port family inet counters
ipset add mds-c-allowssh4-$timestamp 93.241.223.2,22
# create set with allowed IPv6 ssh connections
ipset create mds-c-allowssh6-$timestamp hash:ip,port family inet6 counters

# create union of allowed sets
ipset create mds-c-allowcombined-$timestamp list:set counters
ipset add mds-c-allowcombined-$timestamp mds-c-allowhttp4-$timestamp
ipset add mds-c-allowcombined-$timestamp mds-c-allowhttp6-$timestamp
ipset add mds-c-allowcombined-$timestamp mds-c-allowssh4-$timestamp
ipset add mds-c-allowcombined-$timestamp mds-c-allowssh6-$timestamp
# create mds-allowcombined if not already there
ipset create mds-allowcombined list:set counters
# activate new sets
ipset swap mds-c-allowcombined-$timestamp mds-allowcombined

# add iptables rule if not already there
iptables -C DOCKER-USER -i eth0 -m set ! --match-set mds-allowcombined src,dst -j DROP || iptables -I DOCKER-USER -i eth0 -m set ! --match-set mds-allowcombined src,dst -j DROP
ip6tables -C INPUT -i eth0 -m set ! --match-set mds-allowcombined src,dst -j DROP || ip6tables -I INPUT -i eth0 -m set ! --match-set mds-allowcombined src,dst -j DROP

Here's the output from "ipset --list":

Name: mds-c-allowhttp4-1712053688
Type: bitmap:port
Revision: 3
Header: range 0-1024 counters
Size in memory: 16608
References: 1
Number of entries: 2
Members:
80 packets 0 bytes 0
443 packets 0 bytes 0

Name: mds-c-allowhttp6-1712053688
Type: bitmap:port
Revision: 3
Header: range 0-1024 counters
Size in memory: 16608
References: 1
Number of entries: 2
Members:
80 packets 0 bytes 0
443 packets 0 bytes 0

Name: mds-c-allowssh4-1712053688
Type: hash:ip,port
Revision: 6
Header: family inet hashsize 1024 maxelem 65536 counters bucketsize 12 initval 0xac582e33
Size in memory: 280
References: 1
Number of entries: 1
Members:
93.241.223.2,tcp:22 packets 0 bytes 0

Name: mds-c-allowssh6-1712053688
Type: hash:ip,port
Revision: 6
Header: family inet6 hashsize 1024 maxelem 65536 counters bucketsize 12 initval 0x0bd9d478
Size in memory: 216
References: 1
Number of entries: 0
Members:

Name: mds-allowcombined
Type: list:set
Revision: 3
Header: size 8 counters
Size in memory: 336
References: 2
Number of entries: 4
Members:
mds-c-allowhttp4-1712053688 packets 0 bytes 0
mds-c-allowhttp6-1712053688 packets 0 bytes 0
mds-c-allowssh4-1712053688 packets 0 bytes 0
mds-c-allowssh6-1712053688 packets 0 bytes 0

And here's the output from iptables --list --verbose:

Chain INPUT (policy ACCEPT 14268 packets, 12M bytes)
 pkts bytes target     prot opt in     out     source               destination
11611   11M f2b-sshd   tcp  --  any    any     anywhere             anywhere             multiport dports ssh

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 8765  525K DOCKER-USER  all  --  any    any     anywhere             anywhere
 1939  116K DOCKER-ISOLATION-STAGE-1  all  --  any    any     anywhere             anywhere
    0     0 ACCEPT     all  --  any    docker0  anywhere             anywhere             ctstate RELATED,ESTABLISHED
    0     0 DOCKER     all  --  any    docker0  anywhere             anywhere
    0     0 ACCEPT     all  --  docker0 !docker0  anywhere             anywhere
    0     0 ACCEPT     all  --  docker0 docker0  anywhere             anywhere
    0     0 ACCEPT     all  --  any    br-34e695d35afc  anywhere             anywhere             ctstate RELATED,ESTABLISHED
    0     0 DOCKER     all  --  any    br-34e695d35afc  anywhere             anywhere
 1939  116K ACCEPT     all  --  br-34e695d35afc !br-34e695d35afc  anywhere             anywhere
    0     0 ACCEPT     all  --  br-34e695d35afc br-34e695d35afc  anywhere             anywhere

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  !br-34e695d35afc br-34e695d35afc  anywhere             172.18.0.2           tcp dpt:snpp
    0     0 ACCEPT     tcp  --  !br-34e695d35afc br-34e695d35afc  anywhere             172.18.0.2           tcp dpt:https
    0     0 ACCEPT     tcp  --  !br-34e695d35afc br-34e695d35afc  anywhere             172.18.0.2           tcp dpt:http

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DOCKER-ISOLATION-STAGE-2  all  --  docker0 !docker0  anywhere             anywhere
 1939  116K DOCKER-ISOLATION-STAGE-2  all  --  br-34e695d35afc !br-34e695d35afc  anywhere             anywhere
 1939  116K RETURN     all  --  any    any     anywhere             anywhere

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  any    docker0  anywhere             anywhere
    0     0 DROP       all  --  any    br-34e695d35afc  anywhere             anywhere
 1939  116K RETURN     all  --  any    any     anywhere             anywhere

Chain DOCKER-USER (1 references)
 pkts bytes target     prot opt in     out     source               destination
 6826  409K DROP       all  --  eth0   any     anywhere             anywhere             ! match-set mds-allowcombined src,dst
 1939  116K RETURN     all  --  any    any     anywhere             anywhere

Chain f2b-sshd (1 references)
 pkts bytes target     prot opt in     out     source               destination
11522   11M RETURN     all  --  any    any     anywhere             anywhere

Recently in an Ubuntu 20.04 box from fail2ban I got the following error: 2023-07-13 06:57:05,129 fail2ban.actions : NOTICE [nginx-http-auth] Ban 2600:1005:b02d:3b6a:c1e:4a7e:6a9f:ccc4 2023-07-13 06:57:05,151 fail2ban.utils : ERROR 7f106882c6c0 -- exec: ipset create f2b-nginx-http-auth-v6 hash:ip timeout 600 family inet6 ip6tables -w -I ban -m set --match-set f2b-nginx-http-auth-v6 src -j REJECT --reject-with icmp6-port-unreachable 2023-07-13 06:57:05,152 fail2ban.utils : ERROR 7f106882c6c0 -- timed out after 0 seconds. 2023-07-13 06:57:05,353 fail2ban.utils : ERROR ipset create f2b-nginx-http-auth-v6 hash:ip timeout 600 family inet6 ip6tables -w -I ban -m set --match-set f2b-nginx-http-auth-v6 src -j REJECT --reject-with icmp6-port-unreachable -- failed with [Errno 3] No such process 2023-07-13 06:57:05,353 fail2ban.utils : ERROR 7f106882c6c0 -- killed with SIGTERM (return code: -15) 2023-07-13 06:57:05,354 fail2ban.actions : ERROR Failed to execute ban jail 'nginx-http-auth' action 'iptables-ipset-proto6-allports' info 'ActionInfo({'ip': '2600:1005:b02d:3b6a:c1e:4a7e:6a9f:ccc4', 'family': 'inet6', 'fid': at 0x7f1068839750>, 'raw-ticket': at 0x7f1068839e10>})': Error starting action Jail('nginx-http-auth')/iptables-ipset-proto6-allports: 'Script error' actionstart from **/etc/fail2ban/action.d/iptables-ipset-proto6-allports.local** actionstart = ipset create hash:ip timeout -I -m set --match-set src -j My understanding about the issue is that fail2ban is failing to execute ipset / ip6tables (deadlock?) Is there is a way to relax fail2ban settings so it retries multiple times or allows a longer timeout before exiting.

Senior programmer here but hate the linux networking limitations which make things difficult compared to all programming languages. Practically I need to make **policy based routing** that allows specific lan ip addresses to pick specific outgoing interface (let's say eth5). Even ipset is not powerful enough in my situation. I want to allow all lan ips that first octate is "10" and the last octate is ending up with "9". That would be 10.*.*.??9 or in javascript if(ip.match("\10\..*\.(\d+9|9)\g")) ...USE eth5 Does anyone knows some kind of trick to achive that ? That would be probably thounsands of IP CIDR if we have to stick with CIDR, which is insanity. Thanks

what exactly are the practical differences between iptables recent module and ipset ? I know recent module only allows IPs, whereas ipset allows subnets. But other than this, what is the main practical difference? Is it performance? Which one of those should I use?

I'm building a captive portal (yeah, just-another ;) ) and now I'm trying to handle the core feature, the iptables rules.  Based on ipset I have a list of valid mac-addresses with name allow-mac.  So this is the current config (stripped to the problem itself):

echo 1 >/proc/sys/net/ipv4/ip_forward

ipset create allow-mac hash:mac counters
ipset add allow-mac XX:XX:XX:XX:XX:XX

IPT="/usr/sbin/iptables"

WAN="eth0"
LAN="eth1"

$IPT -P FORWARD DROP
$IPT -t nat -A POSTROUTING -o $WAN -j MASQUERADE
$IPT -I FORWARD -i $LAN -m set --match-set allow-mac src -j ACCEPT

This should work but it didn't! so, if I change the default FORWARD chain to ACCEPT and change the rule to the inverse:

$IPT -P FORWARD ACCEPT
$IPT -I FORWARD -i $LAN -m set ! --match-set allow-mac src -j DROP

I have the desired result, and only clients with known MAC-address in list can forward. So my question, why is it not working in the first setup? And my second missing feature is, if the counters module is already added, but now the "upload" traffic from client is counted, how can (in a separated counter) I also count the download traffic as well?

So, Keenetic Hopper with Entware. I have written several scripts for selective routing. All these scripts work fine, no runtime errors, and the routing works. Ping via Wireguard works fine, but problems occur when I go into the browser, everything is very slow. To be honest I have no idea what the problem could be, the only thing is if I turn off my scripts and set wireguard as the priority connection in the web interface, all the traffic will go through wireguard normally, without any problems or lags, I think the problem is in my routing. There are my scripts:

# /opt/etc/ndm/fs.d/100_hirkn-ipsets.sh

#!/bin/sh

[ "$1" != "start" ] && exit 0

echo " --- HIRKN ENTRY POINT --- "

RKN_SET_FILE="/opt/root/rkn.lst"
GOOGLE_SET_FILE="/opt/root/google.lst"
CUSTOM_SET_FILE="/opt/root/custom.lst"

function create_ipset()
{
        IPSET_NAME=$1
        ipset create $IPSET_NAME hash:net family inet -!
}

function fill_ipset()
{
        FILE="$1"
        IPSET_NAME="$2"
        data=$(cat $FILE)
        for row_data in $data
        do
                ipset add $IPSET_NAME ${row_data} -!
        done
}

function create_and_fill_ipset() {
        IPSET_NAME="$1"
        FILE="$2"
        create_ipset $IPSET_NAME
        fill_ipset $FILE $IPSET_NAME
}

if [ -z "$(ip route list table 1)" ]; then
    ip rule add fwmark 1 table 1
    ip route add default dev nwg0 table 1
fi

create_ipset "HIRKN"
create_ipset "HIGOOGLE"
create_ipset "HICUSTOM"

#fill_ipset $RKN_SET_FILE "HIRKN"
#fill_ipset $GOOGLE_SET_FILE "HIGOOGLE"
#fill_ipset $CUSTOM_SET_FILE "HICUSTOM"

#create_and_fill_ipset "HIRKN" $RKN_SET_FILE
#create_and_fill_ipset "HIGOOGLE" $GOOGLE_SET_FILE
#create_and_fill_ipset "HICUSTOM" $CUSTOM_SET_FILE

exit 0

# /opt/etc/ndm/netfilter.d/99_hirkn-fwmarks.sh

#!/bin/sh

[ "$type" != "iptables" ] && exit 0
[ "$table" != "mangle" ] && exit 0

echo "HIRKN: Creating $type rule on table $table !"

[ -z "$(iptables-save | grep HIRKN)" ] && \
	iptables -w -A PREROUTING -t mangle -m set --match-set HIRKN dst,src -j MARK --set-mark 1
[ -z "$(iptables-save | grep HIGOOGLE)" ] && \
	iptables -w -A PREROUTING -t mangle -m set --match-set HIGOOGLE dst,src -j MARK --set-mark 1
[ -z "$(iptables-save | grep HICUSTOM)" ] && \
	iptables -w -A PREROUTING -t mangle -m set --match-set HICUSTOM dst,src -j MARK --set-mark 1

exit 0

I mostly use the HIRKN set, it's formed from `rkn.lst`, which is taken from here: https://antifilter.download/list/allyouneed.lst If anyone has any guesses, I'd love to hear about it! P.S.: The number of records in the set has no effect, one record or 10000 is the same

This is on a router. I have $mac as the MAC of one client and $set is an ipset of type hash:net. My intention is to deny access to all networks in $set, except for $mac who can access the networks.

-A lan_forward -m mac ! --mac-source $mac -m set --match-set $set dst -j REJECT

But this isn't working. It blocks $set for everyone no matter what the MAC address is. What is the problem? When I turn it into a LOG target I see this:

[ 4128.497456] Blocked website: IN=lanbridge OUT=tun0 MAC=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=192.168.1.186 DST=XXX.XXX.XXX.XXX LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=21305 DF PROTO=TCP SPT=40030 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0

I can confirm with tcpdump that it is rejecting the connection with TCP RST despite having the whitelisted MAC. EDIT! I found out the problem: My problem was that I had more than one rule:

-A lan_forward -m mac ! --mac-source $mac1 -m set --match-set $set dst -j REJECT
-A lan_forward -m mac ! --mac-source $mac2 -m set --match-set $set dst -j REJECT
-A lan_forward -m mac ! --mac-source $mac3 -m set --match-set $set dst -j REJECT

So even if the first matched, the second would fail and reject. I almost decided to use MARK but I don't think this is a proper use of packet marking, so instead I just ACCEPT all outgoing from all the MACs, then block all outgoing to the networks specified in the ipset. I just have to remember not to add anything after the ACCEPT rule that I want to apply to any of the MACs I'm filtering.

I'm running Debian 8.11 with iptables v1.4.21 and ipset v6.23, protocol version: 6. I'm trying to block access to certain ports for all but a small set of hosts, but it doesn't seem to be working. First of all, I put a small list of IP addresses into an ipset list called allowed-hosts. Then, after running sudo /sbin/iptables -F and sudo /sbin/iptables -X, I issue the following commands: sudo /sbin/iptables -I INPUT -p tcp -m multiport --destination-port 110,143,993,995 -j DROP sudo /sbin/iptables -I INPUT -p tcp -m multiport --destination-port 110,143,993,995 -m set --match-set allowed-hosts src -j ACCEPT However, even after doing this, clients from IP addresses that are not present allowed-hosts are still successfully connecting to all of the named ports. There are no other iptables rules in effect. Here are the results of sudo /sbin/iptables -L ... Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT tcp -- anywhere anywhere multiport dports pop3,imap2,imaps,pop3s match-set allowed-hosts src DROP tcp -- anywhere anywhere multiport dports pop3,imap2,imaps,pop3s Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination And here are the results of sudo /sbin/iptables-save ... # Generated by iptables-save v1.4.21 on Wed Jun 8 11:53:09 2022 *security :INPUT ACCEPT [16777464:2727427757] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [18889599:33356814491] COMMIT # Completed on Wed Jun 8 11:53:09 2022 # Generated by iptables-save v1.4.21 on Wed Jun 8 11:53:09 2022 *raw :PREROUTING ACCEPT [21444955:3000669583] :OUTPUT ACCEPT [18889599:33356814491] COMMIT # Completed on Wed Jun 8 11:53:09 2022 # Generated by iptables-save v1.4.21 on Wed Jun 8 11:53:09 2022 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT # Completed on Wed Jun 8 11:53:09 2022 # Generated by iptables-save v1.4.21 on Wed Jun 8 11:53:09 2022 *mangle :PREROUTING ACCEPT [21444955:3000669583] :INPUT ACCEPT [21444952:3000669415] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [18889599:33356814491] :POSTROUTING ACCEPT [18889599:33356814491] COMMIT # Completed on Wed Jun 8 11:53:09 2022 # Generated by iptables-save v1.4.21 on Wed Jun 8 11:53:09 2022 *filter :INPUT ACCEPT [2130649:527089827] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [4465281:1887206637] -A INPUT -p tcp -m multiport --dports 110,143,993,995 -m set --match-set allowed-hosts src -j ACCEPT -A INPUT -p tcp -m multiport --dports 110,143,993,995 -j DROP COMMIT # Completed on Wed Jun 8 11:53:09 2022 What might I be doing incorrectly? Thank you in advance. \*\***UPDATE**\*\* First of all, "src" indeed is being specified, contrary to what was suggested in the comment below. It appears in the "... src -j ACCEPT" line, above. Secondly, the syntax of these iptables commands that I am using comes from what is shown both in the iptables docs and in discussions that were found via web searches. Thirdly, look above at the iptables -L output. This clearly shows that connections to the ports should be accepted from source=anywhere to destination=anywhere for the IP addresses in the allowed-hosts list. This also clearly shows that connections to the ports should be dropped from source=anywhere to destination=anywhere for the IP addresses that are **not** in the allowed-hosts list. At least that's what iptables seems to be telling me. However, connections to these ports from IP addresses that are not in the allowed-hosts list are still being accepted on my machine. Also, if I do ipset test allowed-hosts aaa.bbb.ccc.ddd, where "aaa.bbb.ccc.ddd" represents an IP address which is **not** in allowed-hosts, I properly get this following output: aaa.bbb.ccc.ddd is NOT in set allowed-hosts. And if I do ipset test allowed-hosts www.xxx.yyy.zzz, where "www.xxx.yyy.zzz" represents an IP address which **is** in allowed-hosts, I properly get this following output: www.xxx.yyy.zzz is in set allowed-hosts. Looking at the output from iptables-save, above, what else in my configuration could be causing these connections to ports not in allowed-hosts to be accepted? Thank you again, in advance.

with firewalld I can make a rule like this: (note the invert="True") firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.100.0/24" invert="True" drop' and I can specify that for certain sources I need them treated as part of a zone with this: firewall-cmd --permanent --zone=external --add-source=ipset:knowns Is it possible to invert this and say make sure any ip that is not in the ipset is treated as a part of another specified zone? I have had a look at the man page, and I can not find any indication whether this is possible.

I am using Debian 8 linux. I'm trying to block input access to a few ports for most IP addresses, except for a small, select list of IP addresses. I am doing the following, but it does not seem to work: % sudo /sbin/iptables -v -A INPUT -p tcp -m set '!' --match-set allow-list src -m multiport --dports 110,143,993,995 -j DROP Whenever there is an access attempt to any of those ports from an IP address that is not in allow-list, that attempt is still succeeding. These are the first few lines of allow-list: % sudo /sbin/ipset list allow-list Name: allow-list Type: hash:net Revision: 6 Header: family inet hashsize 16384 maxelem 262144 Size in memory: 687888 References: 2 Members: 125.8.0.0/13 160.94.0.0/15 104.37.68.0/22 205.233.22.0/23 [ ... more CIDR entries ... ] And this is the current iptables configuration: % sudo /sbin/iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination DROP tcp -- anywhere anywhere ! match-set allow-list src multiport dports pop3,imap2,imaps,pop3s Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination What am I doing incorrectly? Thank you very much in advance.

I have this range of IPS 197.192.x.x that is brute force attacking my pop/imap/smtp servers day after day. I have this ipset in place that is blocking every IP that tries to hack on my server. I would like to block access for pop/smtp/imap for all IPs starting with 197.192 To do this, I have typed this command: ipset -A myIpset 197.192.0.0/24 but this added 65536 IPs to my ipset, making it huge and now I cannot add more IPs to it. Is there another way to do this in a more elegant way?

I am using iptables with ipset on an Ubuntu server firewall. I am wondering if there is a command for importing a file containg a list of ip's to ipset. To populate an ipset, right now, I am adding each ip with this command: ipset add manual-blacklist x.x.x.x It would be very helpfull if I can add multiple ip's with a single command, like importing a file or so. At command for ip in cat /home/paul/ips.txt; do ipset add manual-blacklist $ip;done I get this response resolving to IPv4 address failed to parse 46.225.38.155 for each ip in ips.txt I do not know how to apply it.

I am looking for a ready-made script that able to block blacklisted ipv6 address, like https://github.com/trick77/ipset-blacklist script. That is script is perfect, but it is not able to block ipv6 :( Thx! Robert

I have a whitelist of ip addresses I'm storing in a ipset. I want to craft an iptables rule for my input chain where any IP NOT on the whitelist gets dropped immediately and no rules further down the chain get considered. If a ip matches an address on the whitelist then it continues down the Chain, checking other rules. If I just put a default policy of DROP and an ALLOW rule based on the whitelist, ip addresses not on the whitelist might be compared against other rules in the chain and allowed through based on those criteria, which I do not want. I also don't want to immediately let through traffic matching the whitelist rule (I guess whitelist is a but of a misnomer here) but, rather, apply the traffic to further scrutiny. Does iptables support this "DROP on not match" logic?

I have an ipset in-use for my firewall. It was created using set-type "nethash". Turns-out this list will only contain individual ip addresses, making set-type "iphash" more efficient (per man page, anyway). I tried swapping the current list with a new one with the correct set-type, but this is apparently not allowed. I also tried deleting the current list to recreate it with the different settings, but it is in-use by my firewall (as it should be). Is there a way to force --swap an ipset? Or is there a way to change an existing set to a new set-type? I haven't been able to find a way. Thanks.

I decided to use iptables and ipset to read text file that contains source ip and destination port. I want to drop these flows. Is it possible and how to write command to perform this? The file is: 192.45.67.89,22 54.123.212.51,22 123.12.15.46,23 ...

Is there a way to add 0.0.0.0/0 to ipset type hash:net,port? It appears to only support prefix lengths of 1-32 but what if I want an entry in my ipset hash to support all ip traffic on a given port? For example ipset create testset hash:net,port ipset add testset 0.0.0.0,22 iptables -I INPUT 1 -m set --match-set testset src, src -j ACCEPT iptables -I INPUT 2 -j LOG --log-prefix "** FIREWALL **" will do nothing. SSH traffic will hit the firewall and generate a log. 0.0.0.0/0 isn't accepted as valid CIDR notation, though it seems they added it to hash:net,iface in revision 2. I'm aware I could store the port in a bitmap:port and apply it to it's own iptables rule. However, I specifically would like to store ports in a hash as some ports may care about src ip address and others won't and I don't want to maintain a separate set for 0.0.0.0/0.