Re: Issues with IPFW skipto Rule and Whitelisting Logic

From: Vadim Goncharov <vadimnuclight_at_gmail.com>
Date: Sun, 13 Jul 2025 21:18:05 UTC
On Sun, 13 Jul 2025 23:53:25 +0300
Christos Chatzaras <chris@cretaforce.gr> wrote:

> > My intended logic is that any IP present in table(3) should always be
> > allowed, even if it or its subnet also appears in table(1).
> > 
> > For instance, 175.178.167.241 is in table(3), while 175.178.0.0/16 is
> > present in table(1).
> > 
> > After rebooting the server and populating the tables by running the update
> > script for the first time, access from 175.178.167.241 works correctly.
> > However, after subsequent runs of the update script - which only updates
> > unrelated entries and does not modify 175.178.167.241 or 175.178.0.0/16 -
> > access from 175.178.167.241 is no longer permitted.
> > 
> > Additionally, when this issue arises, adding 175.178.0.0/16 to table(3)
> > allows access again. Even after removing that entry, as long as
> > 175.178.167.241 remains in table(3) and I wait for any active sessions to
> > clear, access continues to work.  
> 
> To add more detail:
> 
> When this issue occurs, I can resolve it by just removing 175.178.167.241
> from table(3) and then immediately re-adding it to table(3).
> 
> These commands restores access for the IP:
> 
> ipfw table 3 delete 175.178.167.241
> 
> ipfw table 3 add 175.178.167.241

Did you try to remove `-q` from all your scripts and see if there are errors?
May be something in dmesg? Adding another log rules for your test IP? tcpdump?

-- 
WBR, @nuclight