0

I have two Ubuntu 16.04 servers, one on a little intel atom itx box on my local network and one hosted as a VPS. Both were installed fresh within the last week. Both are generally the same configuration except more efforts have gone into hardening the publicly accessible VPS. Neither have had the kernel recompiled. both have generally the same set of packages installed.

And yet... one of them, the VPS, rather insists that it's netfilters can't match against ipsets.

wolferz@unipuma ~ $ sudo shorewall check
Checking using Shorewall 5.1.6.1...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
Checking /etc/shorewall/zones...
Checking /etc/shorewall/interfaces...
Determining Hosts in Zones...
Locating Action Files...
Checking /etc/shorewall/policy...
Adding Anti-smurf Rules
Checking TCP Flags filtering...
Checking Kernel Route Filtering...
Checking Martian Logging...
Checking MAC Filtration -- Phase 1...
Checking /etc/shorewall/blrules...
   ERROR: ipset names in Shorewall configuration files require Ipset Match in your kernel and iptables /etc/shorewall/blrules (line 39)

The configuration I intend to use depends heavily on ipsets for dynamic blacklisting and whitelisting of large sets of IPs. Because netfilter doesn't lend itself well to being altered often or having massive lists of rules (one for each ip... often thousands).

Without ipset matching, there is no moving forward here. Despite the fact that I'm using Shorewall to manage netfilter and ipsets this does not appear to be a Shorewall problem. Unless it's detection is askew somehow... but I'm not sure how to confirm it's output.

Here's what Shorewall detects as the kernel's netfilter capability on the VPS.

wolferz@unipuma ~ $ sudo shorewall version
5.1.6.1

wolferz@unipuma ~ $ sudo shorewall show -f capabilities | grep IPSET
IPSET_MATCH=                <== this is the problem
IPSET_MATCH_COUNTERS=       <== this is not great either
IPSET_MATCH_NOMATCH=        <== this is not great either
IPSET_V5=Yes
OLD_IPSET_MATCH=

wolferz@unipuma ~ $ sudo shorewall6 version
5.1.6.1

wolferz@unipuma ~ $ sudo shorewall6 show -f capabilities | grep IPSET
IPSET_MATCH_COUNTERS=       <== normal for ipv6
IPSET_MATCH_NOMATCH=        <== normal for ipv6
IPSET_MATCH=Yes             <== correct
IPSET_V5=Yes
OLD_IPSET_MATCH=

wolferz@unipuma ~ $ uname --kernel-release
4.4.0-93-generic

wolferz@unipuma ~ $ ipset --version
ipset v6.29, protocol version: 6

wolferz@unipuma ~ $ iptables --version
iptables v1.6.0

wolferz@unipuma ~ $ ip6tables --version
ip6tables v1.6.0

Where it says IPSET_MATCH= and has nothing following it, it should show IPSET_MATCH=Yes instead. It fails on the VPS, not the local server. Even curiouser, ip6tables reports ipset match support where iptables does not.

I didn't originally have Shorewall on the local server (though I planned to)... so I went ahead and installed it. But I was in a hurry and installed it from apt, giving me Shorewall version 5.0.4. When it reported that it had full ipset match capability I thought it might be something specific to Shorewall 5.1.6.1. So I used apt to remove 5.0.4 and installed 5.1.6.1 from tarballs as I had on the vps. Both 5.0.4 and 5.1.6.1 give the same output.

wolferz@khaos ~ $ sudo shorewall version
5.1.6.1

wolferz@khaos ~ $ sudo shorewall show -f capabilities | grep IPSET
IPSET_MATCH_COUNTERS=Yes
IPSET_MATCH_NOMATCH=Yes
IPSET_MATCH=Yes
IPSET_V5=Yes
OLD_IPSET_MATCH=

wolferz@khaos ~ $ sudo shorewall6 version
5.1.6.1

wolferz@khaos ~ $ sudo shorewall6 show -f capabilities | grep IPSET
IPSET_MATCH_COUNTERS=
IPSET_MATCH_NOMATCH=
IPSET_MATCH=Yes
IPSET_V5=Yes
OLD_IPSET_MATCH=

wolferz@khaos ~ $ uname --kernel-release
4.4.0-93-generic

wolferz@unipuma ~ $ ipset --version
ipset v6.29, protocol version: 6

wolferz@unipuma ~ $ iptables --version
iptables v1.6.0

wolferz@unipuma ~ $ ip6tables --version
ip6tables v1.6.0

Same distro, same release, same kernel. Ok, so I thought, maybe the template they installed the VPS from had been fiddled with it. I decided to check for differences in installed modules:

wolferz@unipuma ~ $ sudo ls -R -D /lib/modules/4.4.0-93-generic/kernel/ | grep -P '\.ko$' | sort > unipuma_sorted_modules.list

... scp it to the other host ...

wolferz@khaos ~ $ sudo ls -R -D /lib/modules/4.4.0-93-generic/kernel/ | grep -P '\.ko$' | sort > khaos_sorted_modules.list

wolferz@khaos ~ $ diff --brief --report-identical-files khaos_sorted_modules.list unipuma_sorted_modules.list

Files khaos_sorted_modules.list and unipuma_sorted_modules.list are identical

Then I checked the actual config for the kernel I'm using:

wolferz@unipuma ~ $ sudo cat /boot/config-4.4.0-93-generic | grep -P '(?:NETFILTER|IPSET)' | sort > unipuma_kernel_config.list

wolferz@khaos ~ $ sudo cat /boot/config-4.4.0-93-generic | grep -P '(?:NETFILTER|IPSET)' | sort > khaos_kernel_config.list

wolferz@khaos ~ $ diff --brief --report-identical-files khaos_kernel_config.list unipuma_kernel_config.list
Files khaos_kernel_config.list and unipuma_kernel_config.list are identical

Well ok then. Color me confused. Same kernel. Same modules. Same Config. Different capabilities. Wut?

And... just to cut this line of thinking off at the pass... it's not the vhost either. I have a third server running CentOS6 with this same version of shorewall (and older versions of netfilter/iptables/ipset) which does not have this problem. It's hosted on the same physical machine using the same virtualization (KVM) as the Ubuntu 16.04 vps above.

...Help?

closed as off-topic by Jeff Schaller, Stephen Rauch, Satō Katsura, Scott, Anthon Sep 11 '17 at 7:20

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Jeff Schaller, Stephen Rauch, Satō Katsura, Scott
If this question can be reworded to fit the rules in the help center, please edit the question.

  • Please add the exact command you are trying that fails, together with that exact error message, and also, please tell which of the two boxes that it fails in. – Ralph Rönnquist Sep 7 '17 at 8:34
  • I've added more information at the head to explain the problem in more depth. I apologize, I thought I had already made the issue clear. I've been at this for about a day and there's a lot more I've tried. And a lot of fruitless research. It's an overwhelming amount of information. I'm trying to limit myself to just what is needed to convey the problem... and apparently went too far the other way. – Cliff Armstrong Sep 7 '17 at 8:54
0

Well ok then. Thanks for all the great ideas. Couldn't have done it without y'alls help.

The issue was something stupid simple, just as I knew it would be. In the shorewall.conf file I had the following line:

IPTABLES=/sbin/ip6tables

Problem is... that's the shorewall.conf file. Not the shorewall6.conf file. I had copied it over when I started configuring the ipv4 half and, apparently, missed that particular '6'.

The corrected line is:

IPTABLES=/sbin/iptables

Hence why the issue behaved like an iptables issue... it kinda was. So yeah... 3 days later...

Not the answer you're looking for? Browse other questions tagged or ask your own question.