Does GEOIP still work for MANGLE PREROUTING rules?

I’ve got a script which is trying to add the following rule:
iptables -t mangle -A PREROUTING -i green0 -m geoip --destination-country EU -j MARK --set-mark 15

This rule worked pretty fine. But since some weeks I’m getting the following error:
iptables v1.8.7 (legacy): Couldn’t load match `geoip’:No such file or directory

Does this relate to the ongoing change from IPTABLES to NFTABLES within the kernel?
And if so, any idea how to deal with it for the time being?

Couldn’t find any hint in the forum.

Best regards

this might help:

there was a change in how iptables worked in ipfire a while ago, with a kernel upgrade if i remember correctly. Anyway you might try changing

iptables -t mangle -A PREROUTING -i green0 -m geoip --destination-country EU -j MARK --set-mark 15


iptables -t mangle -A PREROUTING -i green0 -m geoip --dst-cc EU -j MARK --set-mark 15

Also i would look in the documentation for your current linux kernel version of iptabels to see what is said about config parameters

hope that helps


1 Like

There are many more usecases for GEOIP, not just blocking :grinning:
Nevertheless, your hint triggered a different idea for me :+1: for another problem.

this sounds like small adjustments but great impacts :wink:
will give it a trial :smiley:

With the Core Update 162 the 3.18 version of xtables-addons were installed. This might be the cause, as in this package a lot of interesting features are managed.

As said, will give your proposal a chance

1 Like

Tried your proposal, but w/o success. Will now follow the kernel route.

IPFire has switched from xt_geoip to ipset with core165 so -m geoip is not supported with current kernels.


Hi Arne,
thank you for this hint :pray: It looks like the missing piece (I searched for “xtables” in the release notes :flushed:)
Will take a detailed look into ipset now :smiley:

My mistake. After reading Arne.F’s note I realized I looked at the wrong set of notes.

iptables -t mangle -A PREROUTING -i green0 -m geoip --destination-country EU -j MARK --set-mark 15

should probably read

iptables -t mangle -A PREROUTING -i green0 -m set --match-set EU -j MARK --set-mark 15

or something like that. Sorry for the mistake.


1 Like

Thanks a lot for your great support and no worries for the “mistake” (all good), it put me on the right track :slight_smile:
And I was distracted a little bit, but pulled it up again now for a short test.

Your proposed change is missing one variable, it was the 90% solution, and should look like this:
iptables -t mangle -A PREROUTING -i green0 -m set --match-set $variable src -j MARK --set-mark 15

$variable represents the set op IPs generated by the ipset. As my use case isn’t “blocking” I need to create my own list. Will take some time, due to priorities :stuck_out_tongue_winking_eye:
But will get there :slight_smile:

so I tried to get the rule (iptables -t mangle -A PREROUTING -i green0 -m set --match-set $variable dst -j MARK --set-mark 15 ) working.
So far without success.

In the rule from jaegers49 the “src” need to be exchanged by “dst” to address the destinated IPs, but this isn’t enough. I added a logging rule to check wether the packets from green0 for the destinated IPs are marked at all.
But if I address an address from my IPSET they don’t appear in the logs at all.
As I build my IPSET in the identical manner as the sets for the location blocking I wouldn’t assume the error there, as I see some marked packages in the logs, but not my requested ones.

Any ideas where to dig in? I couldn’t find any changes in the iptables chains so far.