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
--Apple-Mail=_E1BA6BFD-395A-4B96-A10D-E47864322801 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 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). >=20 > For instance, 175.178.167.241 is in table(3), while 175.178.0.0/16 is = present in table(1). >=20 > 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. >=20 > 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= --Apple-Mail=_E1BA6BFD-395A-4B96-A10D-E47864322801 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dus-ascii"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: = after-white-space;"><div><br><blockquote type=3D"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=3D"p1">To add = more detail:</p><p class=3D"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=3D"p1">These commands restores = access for the IP:</p><p class=3D"p1">ipfw table 3 delete = 175.178.167.241</p><p class=3D"p1">ipfw table 3 add = 175.178.167.241</p></div></body></html>= --Apple-Mail=_E1BA6BFD-395A-4B96-A10D-E47864322801--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BFBEBAE0-E768-4E8D-9DB6-0AAD9D0EF931>