On 22 Jun 2026, nelgin said the following...

ipset is a command. The -A thing is something you put in your iptables.

this might not matter much if you fully dump and reload your firewall every time you change something (which can leave it wide open briefly!) but..

-A is add (to the bottom) -I is insert (on top or wherever)

that at least matters because iptables works top to bottom through the chain and will bail on the first matching rule.

say you have commands to accept telnet, ftp, binkd, etc then you DROP everything else (all pretty standard)

then you -A something (like dropping one pesky IP address temporarily) .. it goes BELOW the DROP mentioned above, so what happens is:

pesky IP connects, iptables goes down the list and finds YEAH, telnet is accepted, and then sends the connection along as if you had never blocked it.

-I will throw it on the TOP of the chain as the first thing to check (or a line number can be provided for where it should go)

the default examples in Mystic's Event Editor for example are useless because of this.

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)

Do your drops before you do the port commands, if you ban things.

---
■ Synchronet ■ DaRKLoRD BBS

On 22 Jun 2026, nelgin said the following...

ipset is a command. The -A thing is something you put in your iptables.

this might not matter much if you fully dump and reload your firewall every time you change something (which can leave it wide open briefly!) but..

-A is add (to the bottom) -I is insert (on top or wherever)

that at least matters because iptables works top to bottom through the chain and will bail on the first matching rule.

Say I have something like this in my rules.v4:

# Generated by iptables-save v1.8.11 (nf_tables) on Mon Aug 18 12:21:10 2025 *filter :INPUT ACCEPT [5477:286466] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT
[4483:9434151] COMMIT # Completed on Mon Aug 18 12:21:10 2025 # Generated by iptables-save v1.8.11 (nf_tables) on Mon Aug 18 12:21:10 2025 *nat :PREROUTING
ACCEPT [3:830] :INPUT ACCEPT [36:2810] :OUTPUT ACCEPT [136:8160] :POSTROUTING ACCEPT [136:8160] -A PREROUTING -d x.x.x.x/32 -p tcp -m tcp --dport 11 -j
REDIRECT --to-ports 1111 (etc. for other ports) COMMIT # Completed on Mon Aug 18 12:21:10 2025

Are you saying adding the line as an -A *above* the existing first -A line won't cause it to be first?

You have a badly configured firewall, should not have more than one COMMIT.

---
■ Synchronet ■ DaRKLoRD BBS

On 25 Jun 2026, Darksix said the following...

You have a badly configured firewall, should not have more than one COMMIT.

this is false. it seems you don't know what you're talking about.

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: cold fusion - cfbbs.net - grand rapids, mi

fusion wrote to Dumas Walker <=-

now we try:

iptables -I INPUT -s 71.95.196.34 -j DROP

and dump again:

*filter
-A INPUT -s 71.95.196.34 -j DROP
-A INPUT -p tcp --dport 23 -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "badguy: "
--log-level 7 -A INPUT -j REJECT
COMMIT

NOW the badguy gets the boot before we even check if the connection is going to port 23.

So -A adds it to the bottom of whatever group is belongs in, while -I adds
it to the top. Good to know!

-A PREROUTING -d x.x.x.x/32 -p tcp -m tcp --dport 11 -j REDIRECT --to-ports 1111

interestingly, this moves the connection's destination from the INPUT chain to the FORWARD chain because it's an alias for

-j DNAT --to-destination 127.0.0.1:1111

so nothing in INPUT will match it..

-I FORWARD -m set --match-set blacklist src -j DROP

The purpose of thta line is to route all incoming traffic on port 11 to
port 1111 (the one that synchronet is set to listen on).

Are you saying the *filter rules above this section will be ignored unless
I set them as "FORWARD" instead of "INPUT," even though these rules come
after the *filter section?

anyways, sorry if this is just rehashing stuff you already know :)

No, that I sure did not know!




... Isn't this where....
--- MultiMail/DOS v0.52
■ Synchronet ■ CAPCITY2 * Capitol City Online

On 25 Jun 2026, Dumas Walker said the following...

The purpose of thta line is to route all incoming traffic on port 11 to port 1111 (the one that synchronet is set to listen on).

Are you saying the *filter rules above this section will be ignored
unless I set them as "FORWARD" instead of "INPUT," even though these
rules come after the *filter section?

ah sorry my bad.. looking at it now the nat table will put the packets to INPUT (or automatically recognize 'localhost', 127.0.0.1, the ipv6 one.. etc) ..

but will move it to FORWARD if, for example, you have a separate BBS machine and IP that you forward (<- heh) the port to.

mine gets forwarded from a linux router to a win32 bbs machine so to block IPs i have to put it in the FORWARD section.

i guess the point i was trying to get across is it's pretty easy to accidentally put in do-nothing rules

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: cold fusion - cfbbs.net - grand rapids, mi

# Generated by iptables-save v1.8.11 (nf_tables) on Mon Aug 18 12:21:10 2025 *filter :INPUT ACCEPT [5477:286466] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT
[4483:9434151] COMMIT # Completed on Mon Aug 18 12:21:10 2025 # Generated by iptables-save v1.8.11 (nf_tables) on Mon Aug 18 12:21:10 2025 *nat :PREROUTING
ACCEPT [3:830] :INPUT ACCEPT [36:2810] :OUTPUT ACCEPT [136:8160] :POSTROUTING ACCEPT [136:8160] -A PREROUTING -d x.x.x.x/32 -p tcp -m tcp --dport 11 -j
REDIRECT --to-ports 1111 (etc. for other ports) COMMIT # Completed on Mon Aug 18 12:21:10 2025

Are you saying adding the line as an -A *above* the existing first -A line won't cause it to be first?

You have a badly configured firewall, should not have more than one COMMIT.

I didn't key that in there. iptables generated it that way. <shrugs>

$$
---
■ Synchronet ■ CAPCITY2 * Capitol City Online

fusion wrote to Dumas Walker <=-

The purpose of thta line is to route all incoming traffic on port 11 to port 1111 (the one that synchronet is set to listen on).

Are you saying the *filter rules above this section will be ignored
unless I set them as "FORWARD" instead of "INPUT," even though these
rules come after the *filter section?

ah sorry my bad.. looking at it now the nat table will put the packets
to INPUT (or automatically recognize 'localhost', 127.0.0.1, the ipv6 one.. etc) ..

No worries!

but will move it to FORWARD if, for example, you have a separate BBS machine and IP that you forward (<- heh) the port to.

I never could get "other machine" to work, and I bet that is why... I
wasn't using FORWARD!

i guess the point i was trying to get across is it's pretty easy to accidentally put in do-nothing rules

True. Turned out my *filter rules were logging, but I had forgot to go
back and add the DROP lines once I verified the filers were being hit. So
this discussion did bear some fruit for me after all. Thanks to you and
Neglin for following along on my train of thought.



... 2 + 2 = 5 for extremely small values of 5
--- MultiMail/DOS v0.52
■ Synchronet ■ CAPCITY2 * Capitol City Online

# Generated by iptables-save v1.8.11 (nf_tables) on Mon Aug 18 12:21:10 2025 *filter :INPUT ACCEPT [5477:286466] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT
[4483:9434151] COMMIT # Completed on Mon Aug 18 12:21:10 2025 # Generated by iptables-save v1.8.11 (nf_tables) on Mon Aug 18 12:21:10 2025 *nat
:PREROUTING ACCEPT [3:830] :INPUT ACCEPT [36:2810] :OUTPUT ACCEPT [136:8160] :POSTROUTING ACCEPT [136:8160] -A PREROUTING -d x.x.x.x/32 -p tcp -m tcp
--dport 11 -j REDIRECT --to-ports 1111 (etc. for other ports) COMMIT # Completed on Mon Aug 18 12:21:10 2025

Are you saying adding the line as an -A *above* the existing first -A line won't cause it to be first?

You have a badly configured firewall, should not have more than one COMMIT.

I didn't key that in there. iptables generated it that way. <shrugs>

That's kind of weird that it did COMMIT more than once, and also to the other fella, you can have more than one commit
but it should all be commited fully on one go if using iptables-save even if this is nftables wrapper. But I guess
still didn't change the fact it wasn't correct you could say besides the commit.

Hav G'day eh

---
■ Synchronet ■ DaRKLoRD BBS

On 27 Jun 2026, Darksix said the following...

That's kind of weird that it did COMMIT more than once, and also to the other fella, you can have more than one commit
but it should all be commited fully on one go if using iptables-save
even if this is nftables wrapper. But I guess
still didn't change the fact it wasn't correct you could say besides the commit.

again, this isn't correct.

root@orion:/home/alex# cat derp *nat

-A PREROUTING -i eth0 -p tcp --dport 23 -j REDIRECT --to-port 2323

# <--- missing COMMIT here

*filter

-A FORWARD -i eth0 -p tcp --dport 23 -j ACCEPT

COMMIT


....


root@orion:/home/alex# iptables-restore < derp Bad argument `*filter'
Error occurred at line: 7
Try `iptables-restore -h' or 'iptables-restore --help' for more information.


....


you cannot introduce a new table without COMMIT-ing the previous one. in this context the error is basically saying: *nat without COMMIT

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: cold fusion - cfbbs.net - grand rapids, mi