Blocking IP addresses with iptables

John Smith

unread,

Apr 1, 2021, 3:32:54 PM4/1/21

to

I have the following iptables rule:

iptables -A INPUT -p tcp -s 11.12.22/19 --dport 1234 -i eth0 -j
DROP

With this rule, what IP addresses will be blocked when trying to
establish a TCP connection on port 1234?

John Smith

unread,

Apr 1, 2021, 3:38:47 PM4/1/21

to

I am aware of the --src-range option to iptables - no need to
bring it up.

David W. Hodgins

unread,

Apr 2, 2021, 1:38:25 AM4/2/21

to

$ ipcalc -i 11.12.22.0/19
Address: 11.12.22.0
Network: 11.12.0.0/19
Netmask: 255.255.224.0 = 19
Broadcast: 11.12.31.255

Address space: Internet
Address class: Class A
HostMin: 11.12.0.1
HostMax: 11.12.31.254
Hosts/Net: 8190

Regards, Dave Hodgins

--
Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.

Carlos E.R.

unread,

Apr 2, 2021, 8:52:09 AM4/2/21

to

On 02/04/2021 07.38, David W. Hodgins wrote:
> On Thu, 01 Apr 2021 15:32:46 -0400, John Smith
> <12...@whatismyemailaddress.xyz> wrote:
>> I have the following iptables rule:
>> iptables -A INPUT -p tcp -s 11.12.22/19 --dport 1234 -i eth0 -j
>> DROP
>> With this rule, what IP addresses will be blocked when trying to
>> establish a TCP connection on port 1234?
>
> $ ipcalc -i 11.12.22.0/19

I didn't know this tool, I just installed it. But:

cer@Telcontar:~> ipcalc -i 11.12.22.0/19
Unknown option: -i

I have Version 0.41

--
Cheers, Carlos.

Allodoxaphobia

unread,

Apr 2, 2021, 8:58:24 AM4/2/21

to

Don't use iptables here, I use pf.
(I wonder if 11.12.22/19 should be 11.12.22.0/19)

But, 11.12.0.0/19 == 11.12.0.0 -> 11.12.31.255

https://www.ipaddressguide.com/cidr

Jonesy
--
Marvin L Jones | Marvin | W3DHJ.net | linux
38.238N 104.547W | @ jonz.net | Jonesy | FreeBSD
* Killfiling google & XXXXbanter.com: jonz.net/ng.htm

David W. Hodgins

unread,

Apr 2, 2021, 1:16:36 PM4/2/21

to

Mageia 7 has ...
$ ipcalc -v
ipcalc 0.2.0
On Mageia 8, which also has it working with -i ...
$ ipcalc -v
ipcalc 1.0.0

Marc Haber

unread,

Apr 2, 2021, 3:47:05 PM4/2/21

to

John Smith <12...@whatismyemailaddress.xyz> wrote:
>11.12.22/19

Don't do this. It's ambiguous. iptables will expand 11.12.22/19 to
11.12.22.0/19 and then apply the netmask, yielding 11.12.0.0/19:

|[9/6157]mh@drop:~ $ ipcalc 11.12.22.0/19
|Address: 11.12.22.0 00001011.00001100.000 10110.00000000
|Netmask: 255.255.224.0 = 19 11111111.11111111.111 00000.00000000
|Wildcard: 0.0.31.255 00000000.00000000.000 11111.11111111
|=>
|Network: 11.12.0.0/19 00001011.00001100.000 00000.00000000
|HostMin: 11.12.0.1 00001011.00001100.000 00000.00000001
|HostMax: 11.12.31.254 00001011.00001100.000 11111.11111110
|Broadcast: 11.12.31.255 00001011.00001100.000 11111.11111111
|Hosts/Net: 8190 Class A
|
|[10/6158]mh@drop:~ $

Other tools will expand 11.12.22 to 11.12.0.22:

|[10/6158]mh@drop:~ $ ping 11.12.22
|PING 11.12.22 (11.12.0.22) 56(84) bytes of data.

And also, please don't use real-life world-wide routable IP addresses
outside the link local, site local and documentation ranges or
examples and questions; the IP address you have used belongs to the
DoD's network 11.0.0.0/8.

in IPv6, there is defined behavior, you can write :: to insert as many
zeroes as needed to yield a full 128 bit address:

|[2/6160]mh@drop:~ $ sipcalc fec0:0:0:ffff::1
|-[ipv6 : fec0:0:0:ffff::1] - 0
|
|[IPV6 INFO]
|Expanded Address - fec0:0000:0000:ffff:0000:0000:0000:0001
|Compressed address - fec0:0:0:ffff::1
|Subnet prefix (masked) - fec0:0:0:ffff:0:0:0:1/128
|Address ID (masked) - 0:0:0:0:0:0:0:0/128
|Prefix address - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
|Prefix length - 128
|Address type - Site-Local Unicast Addresses
|Network range - fec0:0000:0000:ffff:0000:0000:0000:0001 -
| fec0:0000:0000:ffff:0000:0000:0000:0001
|
|-
|[3/6161]mh@drop:~ $

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Carlos E.R.

unread,

Apr 2, 2021, 4:44:09 PM4/2/21

to

On 02/04/2021 19.14, David W. Hodgins wrote:
> On Fri, 02 Apr 2021 08:49:07 -0400, Carlos E.R.
> <robin_...@es.invalid> wrote:
>> On 02/04/2021 07.38, David W. Hodgins wrote:
>>> On Thu, 01 Apr 2021 15:32:46 -0400, John Smith
>>> <12...@whatismyemailaddress.xyz> wrote:
>>>> I have the following iptables rule:
>>>> iptables -A INPUT -p tcp -s 11.12.22/19 --dport 1234 -i eth0 -j
>>>> DROP
>>>> With this rule, what IP addresses will be blocked when trying to
>>>> establish a TCP connection on port 1234?
>>> $ ipcalc -i 11.12.22.0/19
>
>> I didn't know this tool, I just installed it. But:
>> cer@Telcontar:~> ipcalc -i 11.12.22.0/19
>> Unknown option: -i
>>
>>
>> I have Version 0.41
>
> Mageia 7 has ...
> $ ipcalc -v
> ipcalc 0.2.0
> On Mageia 8, which also has it working with -i ...
> $ ipcalc -v
> ipcalc 1.0.0

Where did they got version 1 from? It is not on the official site:

http://jodies.de/ipcalc-archive/

Could you look at the package information to see if they mention another
URL, please?

Could be <https://github.com/nmav/ipcalc>, but they mention version
0.2.3... Ah, it is <https://gitlab.com/ipcalc/ipcalc>, that's 1.0.0

--
Cheers, Carlos.

David W. Hodgins

unread,

Apr 3, 2021, 2:16:14 AM4/3/21

to

Correct. On Mageia 7 ...
$ rpm -q -i ipcalc|grep ^URL
URL : https://github.com/nmav/ipcalc
On Mageia 8 ...
$ rpm -q -i ipcalc|grep ^URL
URL : https://gitlab.com/ipcalc/ipcalc

Carlos E.R.

unread,

Apr 3, 2021, 4:40:09 PM4/3/21

to

I found (someone told me) that openSUSE also packages "netcalc" which
contains "ipcalc" and "netcalc". Also an old version of "ipcalc", it
does not accept "-i".

cer@Telcontar:~> rpm -qi netcalc
Name : netcalc
Version : 2.1.6
Release : lp152.1.1
Architecture: x86_64
Install Date: 2021-04-03T22:27:18 CEST
Group : Unspecified
Size : 53782
License : BSD-3-Clause
Signature : DSA/SHA1, 2020-06-22T21:56:36 CEST, Key ID 382fb14c392ffa88
Source RPM : netcalc-2.1.6-lp152.1.1.src.rpm
Build Date : 2020-06-22T21:56:26 CEST
Build Host : lamb22
Relocations : (not relocatable)
Vendor : obs://build.opensuse.org/network:utilities
URL : https://github.com/troglobit/netcalc
Summary : IP subnet calculator
Description :
netcalc is an IP network calculator that can calcuate host IP ranges, subnet
masks, and split networks. It is a clone of sipcalc and uses the output
format
of ipcalc.
Distribution: network:utilities / openSUSE_Leap_15.2
cer@Telcontar:~>

--
Cheers, Carlos.

David W. Hodgins

unread,

Apr 3, 2021, 6:20:47 PM4/3/21

to

On Sat, 03 Apr 2021 16:39:28 -0400, Carlos E.R. <robin_...@es.invalid> wrote:
> netcalc is an IP network calculator that can calcuate host IP ranges, subnet
> masks, and split networks. It is a clone of sipcalc and uses the output
> format
> of ipcalc.
> Distribution: network:utilities / openSUSE_Leap_15.2
> cer@Telcontar:~>

Interesting. Mageia doesn't have netcalc, but does have sipcalc which I hadn't
heard of previously. It appears to have identical options. It's from
http://www.routemeister.net/projects/sipcalc

Jorgen Grahn

unread,

Apr 5, 2021, 10:36:06 AM4/5/21

to

On Fri, 2021-04-02, Marc Haber wrote:
> John Smith <12...@whatismyemailaddress.xyz> wrote:
>>11.12.22/19
>
> Don't do this. It's ambiguous. iptables will expand 11.12.22/19 to
> 11.12.22.0/19 and then apply the netmask, yielding 11.12.0.0/19:

...

> Other tools will expand 11.12.22 to 11.12.0.22:
>
> |[10/6158]mh@drop:~ $ ping 11.12.22
> |PING 11.12.22 (11.12.0.22) 56(84) bytes of data.

That's an example with an IPv4 address; it doesn't prove that omitting
the useless octets of an IPv4 network is ambiguous.

You may be right, but I'd like to see more evidence. I write things
like 10/8 and 192.168.1/24 all the time, but I can't easily supply any
evidence /that/ is correct.

Reading more, I see 'ping 11.12.22' must expand the address
according to the flexible and obsolete rules of inet_addr() and
inet_aton(). They accept all kinds of crazy formats from the
pre-CIDR days. While the /prefix-len syntax is, it seems to me,
a CIDR thing.

I agree it would mean disaster if you fed 11.12.22/19 into a
program which ended up feeding 11.12.22 into inet_aton(), but such
a program would need bug-fixing IMO.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Marc Haber

unread,

Apr 5, 2021, 2:02:40 PM4/5/21

to

Jorgen Grahn <grahn...@snipabacken.se> wrote:
>On Fri, 2021-04-02, Marc Haber wrote:
>> John Smith <12...@whatismyemailaddress.xyz> wrote:
>>>11.12.22/19
>>
>> Don't do this. It's ambiguous. iptables will expand 11.12.22/19 to
>> 11.12.22.0/19 and then apply the netmask, yielding 11.12.0.0/19:
>...
>> Other tools will expand 11.12.22 to 11.12.0.22:
>>
>> |[10/6158]mh@drop:~ $ ping 11.12.22
>> |PING 11.12.22 (11.12.0.22) 56(84) bytes of data.
>
>That's an example with an IPv4 address; it doesn't prove that omitting
>the useless octets of an IPv4 network is ambiguous.

Agreed.

>You may be right, but I'd like to see more evidence. I write things
>like 10/8 and 192.168.1/24 all the time, but I can't easily supply any
>evidence /that/ is correct.

I write /8 sloppily the same way, but wouldn't abbreviate /24's like
that. ping 10 will not even do the expected and insert the zeroes in
front:
|[7/6665]mh@drop:~ $ ping 10
|PING 10 (0.0.0.10) 56(84) bytes of data.

Those exaggerted abbreviations will de-rail network newbies even more
just after we have told them that they need to ditch that classful
thinking and those skills of dealing with classful networking such as
answering questions like "what's the netmask of 156.80.4.63" that they
were taught in school months ago and had exams in.

On Usenet, you just need to be careful since less knowledgeable people
will find your articles and paste your ideas into their systems.