Failed to import the iplist

[AlexNBY]

Hi,

after running the "geoip-shell-install.sh" and answering the questions i got this error message:

Parsing ip list for 'DE_ipv4'... Ok.
Validating 'DE_ipv4'... Ok.
Validated subnets for 'DE_ipv4': 10649.

Parsing ip list for 'DE_ipv6'... Ok.
Validating 'DE_ipv6'... Ok.
Validated subnets for 'DE_ipv6': 3025.

Adding ip set 'DE_4_2024-10-31'... netlink: Error: Could not process rule: Message too long
Destroying temporary ipsets...
apply: Error: Failed to import the iplist from '/tmp/geoip-shell/DE_ipv4.iplist' into ip set 'DE_4_2024-10-31'.
manage: Warning: Discrepancy detected between the firewall state and the config file.
manage: Warning: missing ip lists in the firewall: 'DE_ipv4 DE_ipv6'
manage: Error: Failed to apply geoip-shell config.
install: Error: geoip-shell-manage.sh exited with error code 1.
root@nginx:~/geoip-shell-0.5.10# sh geoip-shell-install.sh 

i hope someone can help me

[friendly-bits]

Hi, what's the output of sudo sysctl -a | grep wmem

[AlexNBY]

sysctl: Zugriff verweigert auf Schlüssel »kernel.apparmor_display_secid_mode«
sysctl: Zugriff verweigert auf Schlüssel »kernel.apparmor_restrict_unprivileged_io_uring«
sysctl: Zugriff verweigert auf Schlüssel »kernel.apparmor_restrict_unprivileged_userns_complain«
sysctl: Zugriff verweigert auf Schlüssel »kernel.apparmor_restrict_unprivileged_userns_force«
sysctl: Zugriff verweigert auf Schlüssel »kernel.cad_pid«
sysctl: Zugriff verweigert auf Schlüssel »kernel.unprivileged_userns_apparmor_policy«
sysctl: Zugriff verweigert auf Schlüssel »kernel.usermodehelper.bset«
sysctl: Zugriff verweigert auf Schlüssel »kernel.usermodehelper.inheritable«
net.ipv4.tcp_wmem = 4096        16384   4194304
net.ipv4.udp_wmem_min = 4096
vm.lowmem_reserve_ratio = 256   256     32      0       0
sysctl: Zugriff verweigert auf Schlüssel »vm.mmap_rnd_bits«
sysctl: Zugriff verweigert auf Schlüssel »vm.mmap_rnd_compat_bits«
sysctl: Zugriff verweigert auf Schlüssel »vm.stat_refresh«

Zugriff verweigert auf Schlüssel = permission denied
maybe the problem is, that its a unprivileged lxc container?

[friendly-bits]

This definitely has something to do with running inside a container, but I'm not entirely sure what's causing this. References to this error message I can find are all related to using large sets inside a container. The suggested workarounds are to increase the value of wmem.max on the host. I think it's safe to try this (on the host):
sudo sysctl -w net.core.wmem_max=16777216
If that works, add this line to /etc/sysctl.conf on the host:

net.core.wmem_max = 16777216

to make this permanent.

References:
https://www.reddit.com/r/Proxmox/comments/scnoav/lxc_container_debian_11_nftables_geoblocking/
http://git.netfilter.org/nftables/commit/?id=375505a4a8068bf7cb623e18c3aedb831c17fd0e

If this doesn't work, you could try with a newer kernel...

[AlexNBY]

unfortunately increasing the value did not worked and i already have the newest kernel.
i will try it again with a privileged container and will let you know

[friendly-bits]

I'm not sure if updating the wmem_max value takes immediate effect inside the container. One thing you could try would be restarting the container after issuing the command sudo sysctl -w net.core.wmem_max=16777216 on the host.

Also, what's the output of sudo nft --version?

[AlexNBY]

It works now! First I changed the value on the host and restarted the container. Unfortunately, that didn't help. Then I started the container as privileged, which didn't help either.
Then I noticed that the checkbox for "nesting" was checked (I don't know why it was activated). I unchecked it and then it worked. It seems to be a wild combination of everything.

I would like to thank you for your help and your great project.
Is there a way I can buy you a coffee?

[friendly-bits]

Glad you got it working! No need to buy a coffee. Your research may help other people and that's a welcome contribution. I'll link to this issue somewhere in the readme.

[patanne]

FWIW. beginning with debian 11 – actually the version of systemd in debian 11 – nesting is needed to provide access to /proc & /sys to get around major issues with apparmor. the bug(s) has existed for years. i know the issue still exists in debian 12. i do not know if apparmor is fixed and so i am not certain what will come in debian 13.

the large army of people (like me) who use proxmox depend on nesting as a workaround. because this is such a problem, when you create a container of debian 11 or 12 in proxmox 7 or 8, nesting is on by default. so, for now, turning off nesting is not a realistic solution. i would love to use this product, but for me this matter is not closed.

[friendly-bits]

Hi @patanne, are you getting the same error netlink: Error: Could not process rule: Message too long?
If so, could you try with only one country code, and pick some very small country? For example, North Korea :) You could configure in blacklist mode so you don't allow access from that country. I just want to see if there is maybe a workaround of splitting the list into smaller ipsets.

[friendly-bits]

I took a brief look at Proxmox documentation and they regard nftables support as "tech preview" and "not suited for production use": link.

So I wonder if configuring geoip-shell to use iptables+ipset may work around the issue?

geoip-shell configure -w ipt

Also @patanne what kernel are you running on the host?

[patanne]

it took me a few days to get back to this.

• north korea worked without using your iptables suggestion.
• the proxmox 8 kernel is 6.8.12-8-pve.
• after installing the necessary packages required by your iptables suggestion, geoip-shell configure -w ipt worked.

while iptables worked, it is not the best answer simply because the world is trying to move on to nftables. debian 13 (trixie) should release this quarter. proxmox is very good about releasing an update as soon as the latest distro ships. given that trixie will be the latest debian has until 2027, and that it won't be long before i can test it, i will wait until trixie ships to see if this is fixed. if not i will use iptables in my LXC containers.

thank you for the suggestions.

[friendly-bits]

Good to know that using iptables works around the issue. I think this is a good reason to report a bug to the netlink developers:

https://bugzilla.kernel.org/

(You will need to create a Bugzilla account which is somewhat tedious but possible)

Ultimately, to me this looks like a bug in the nftables kernel component.

[friendly-bits]

Also @patanne, could you specify which packages you installed besides ipset? This may help other people having a similar issue.