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.

[patanne]

no changes happened on the host. in the LXC container, iptables & ipset. that's it.

with respect to some bug somewhere...

i began with someone experiencing exactly what i am facing.
https://www.reddit.com/r/Proxmox/comments/scnoav/lxc_container_debian_11_nftables_geoblocking/

that led me to someone claiming to have solved the problem in nftables. they submitted the patch on 2023-04-07.
https://marc.info/?l=netfilter-devel&m=168090739511495&w=2

i traced the code at netfilter.org. the change was committed on 2023-04-24. this submission was 2 months before the release of debian 12, so even if netfilter.org had released the change, there was no way it could have made it into the release of the latest debian distro.
https://git.netfilter.org/nftables/commit/src/mnl.c?id=375505a4a8068bf7cb623e18c3aedb831c17fd0e

i traced further. that commit was included in the release of 2023-07-14. it was labeled v.1.0.8.
https://git.netfilter.org/nftables/commit/?id=6493bf4abe6e6f05565db507d2124b1aebc70ec9

the version of nftables in debian 12 (bookworm) is 1.0.6-2+deb12u2. an updated nftables in not in bookworm backports. the version of nftables in debian 13 (trixie) is 1.1.1-1. so this should be solved when trixie rolls and proxmox releases VE v.9.

FWIW. this problem does not exist at all, at lease not when using the US only in a whitelist, if the LXC container is privileged.

[friendly-bits]

@patanne thank you for the research.

In the meantime, I'm thinking to implement a more nuanced approach to setting the default firewall backend utility. Currently the code simply checks whether nftables is available an if so, it defaults to nftables. The implementation I'm considering would rather:

1. Check if any active iptables rules are present and if so, default to iptables.
2. Check if running under LXC container - if so then check if nftables version is lower than 1.0.8 - if so then default to iptables.

Does this sound reasonable?

[patanne]

agreed.

there are two caveats to bullet point 2, though. first, iptables may not be installed. second, the container may be privileged, at which time the point may be moot. in the case of bullet point 2, possibly display a warning to the user, leading them to this issue.

learning whether iptables is installed is easy enough.

learning if we are in a lxc container can be achieved via systemd-detect-virt.

we can know if the container is privileged or not via the ownership of /proc. it will be owned by root if it is privileged and nobody:nogroup if unprivileged.

[friendly-bits]

Hi @patanne, thank you for the information.

I've had 0 experience with Proxmox or LXC until a few hours ago, but now I installed Proxmox and created a Debian Bookworm LXC container from a template. I tested both a privileged and an unprivileged container, with an without nesting. I did not find that nesting made any difference at all: in all cases, if the container was privileged then geoip-shell could create large nftables sets, otherwise it couldn't. iptables +ipset worked with all combinations.

So unless you can confirm that nesting indeed makes a difference in your setup, I'm not seeing a need to check for nesting (which I was planning initially). Rather, should simply check for the container being privileged.

[patanne]

In a previous post here I mentioned that nesting was needed to get around a clash between apparmor and the container accessing /proc & /sys. A while back I did the research on this to my satisfaction but didn't keep my research, so I have no links to point you to. A telltale that you have run into the problem is to fire up an unprivileged container with nesting turned off. It will boot normally, but after you login it will take 1-5 min to get a shell prompt. The system behaves as if it is hung, when in fact it is waiting for certain blocked operations to time out.

To be fair, I have not tested this in a while. Debian Bookworm is up to version 12.10. I probably last tested the need for nesting on 12.5. Could something have changed? Sure. Proxmox just released 8.4. They use their own kernel. When I last tested geoip-shell with nftables, a few weeks ago, Proxmox was still at version 8.3.1. nftables was still failing for me at that time.

When it comes to security there are the doomsday people who tell you we are all going to die if your password is only 14 characters long, not 15. I am not one of those people. However, a privileged container has the root user mapped properly into the host, as opposed to being mapped to 'nobody' when unprivileged. If you are running containers in the double digits on a single host that is a recipe for disaster. Forget security. If they can all issue changes to /proc & sysctl how can you guarantee performance? How do you find the culprit? privileged is a bad idea en mass.

[friendly-bits]

When I last tested geoip-shell with nftables, a few weeks ago, Proxmox was still at version 8.3.1. nftables was still failing for me at that time.

To clarify: was the container privileged? Did you ever succeed in running geoip-shell with nftables and a large ip list in an unprivileged LXC container?

I'm asking because as I wrote above, at least with the current version of Proxmox and in my setup, nftables won't accept large sets in an unprivileged container, regardless of nesting or any other options I've tried (while iptables + ipset works fine with large iplists under all conditions).

When it comes to security

As a non-user of Proxmox and LXC who doesn't really understand all of the underlying technology, I don't have much to contribute to the discussion about privileged containers security, and I think this issue is not the right place to discuss it. My concern here is detecting conditions under which geoip-shell is likely to fail, warn the user about the existence of these conditions and which workarounds are possible (currently, it looks like they'll either need to use iptables or a privileged container - maybe nftables 1.0.8 will change that?). I am not going to recommend users to use a privileged container - I just want to give them the information.

(BTW for cases where both iptables and nftables are available and existing iptables rules are found, geoip-shell will ask the user which firewall backend should be used, after issuing the appropriate warnings - at least this is my plan for now)

[patanne]

Proxmox 8.4 shipped on 2025-04-09, a week ago. I have not had time to test geoip-shell with it. Two weeks ago, because of our discussion here, I did retest nftables with an unprivileged Debian 12.10 container on Proxmox 8.3.1. The test was not successful.

[friendly-bits]

So to me this sounds like regardless of nesting, currently one can only load large nft sets when using a privileged container (at least with nftables versions lower than 1.0.8). It is possible that earlier Proxmox kernel versions had an issue with privileged container and nesting, but currently this does not seem to be the case. So for now, to my understanding, we only have 1 report about nesting having any effect on this, and I'm not sure whether that was a genuine issue or a user mistake. So unless more information is provided, I will ignore nesting when checking for nftables backend compatibility. Since I am not certain that nftables v1.0.8 will actually fix this issue, for now I'll implement a warning during initial setup (or when firewall backend change is requested) when running in an unprivileged container and nftables is one of the possible firewall backends, regardless of nftables version.

If anyone has further information, it will help if you post an update here.