Date: Sun, 13 Jul 2025 23:53:25 +0300 From: Christos Chatzaras <chris@cretaforce.gr> To: freebsd-net <freebsd-net@freebsd.org> Cc: FreeBSD Questions Mailing List <freebsd-questions@freebsd.org> Subject: Re: Issues with IPFW skipto Rule and Whitelisting Logic Message-ID: <BFBEBAE0-E768-4E8D-9DB6-0AAD9D0EF931@cretaforce.gr> In-Reply-To: <3A01EF48-EBE8-48C3-9C66-6A250A240341@cretaforce.gr> References: <3A01EF48-EBE8-48C3-9C66-6A250A240341@cretaforce.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] > 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 [-- Attachment #2 --] <html><head><meta http-equiv="content-type" content="text/html; charset=us-ascii"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br><blockquote type="cite"><div><div>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).<br><br>For instance, 175.178.167.241 is in table(3), while 175.178.0.0/16 is present in table(1).<br><br>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.<br><br>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.<br></div></div></blockquote></div><br><div><p class="p1">To add more detail:</p><p class="p1">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).</p><p class="p1">These commands restores access for the IP:</p><p class="p1">ipfw table 3 delete 175.178.167.241</p><p class="p1">ipfw table 3 add 175.178.167.241</p></div></body></html>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BFBEBAE0-E768-4E8D-9DB6-0AAD9D0EF931>