https://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162018-03-31T14:45:24ZpfSense bugtrackerpfSense - Bug #6799: Negating ``<interface> net`` when a VIP exists on the interface results in unintended behaviorhttps://redmine.pfsense.org/issues/6799?journal_id=361722018-03-31T14:45:24ZJim Thompsonjim@netgate.com
<ul><li><strong>Assignee</strong> set to <i>Anonymous</i></li></ul> pfSense - Bug #6799: Negating ``<interface> net`` when a VIP exists on the interface results in unintended behaviorhttps://redmine.pfsense.org/issues/6799?journal_id=361732018-03-31T14:51:59ZJim Thompsonjim@netgate.com
<ul></ul><p>LAN Interface: 172.25.232.1/24<br />IP Alias VIP on LAN: 10.10.10.10/32</p>
<p>You’ve defined LAN here to include both.</p>
<p>So the question seems to be one of POLA violation. Possible that a warning suffixes.</p> pfSense - Bug #6799: Negating ``<interface> net`` when a VIP exists on the interface results in unintended behaviorhttps://redmine.pfsense.org/issues/6799?journal_id=361742018-03-31T15:20:43ZChris Linstruth
<ul></ul><p>Understood.</p>
<p>The usual reason is that is what pfBlockerNG's DNSBL does by default - places a 10.10.10.X IP Alias VIP on the LAN interface.</p>
<p>I believe that VIP should be on Localhost, not an actual interface. Localhost is not an available selection in the DNSBL configuration for the VIP, however. And that would only cover that specific case.</p> pfSense - Bug #6799: Negating ``<interface> net`` when a VIP exists on the interface results in unintended behaviorhttps://redmine.pfsense.org/issues/6799?journal_id=418242019-08-20T13:16:46ZJim Pingle
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Not a Bug</i></li></ul><p>Adding alias nets to the interface macros was deliberate, so I'd say the only problem here is that pfBlocker won't let you put the VIP on localhost, which isn't a base system issue.</p> pfSense - Bug #6799: Negating ``<interface> net`` when a VIP exists on the interface results in unintended behaviorhttps://redmine.pfsense.org/issues/6799?journal_id=418312019-08-20T13:29:04ZChris Linstruth
<ul></ul><p>I believe that the negate address match rules not "blocking" any traffic is worth a deeper look. This wasn't really a report on the package, but a report on that behavior. That was simply the method that alias was installed on the interface in the first place in that case.</p> pfSense - Bug #6799: Negating ``<interface> net`` when a VIP exists on the interface results in unintended behaviorhttps://redmine.pfsense.org/issues/6799?journal_id=418412019-08-20T13:43:58ZJim Pingle
<ul><li><strong>Subject</strong> changed from <i>VIP outside of LAN subnet results in LAN net expansion causing unexpected traffic to pass</i> to <i>Using NOT (!) with interface subnet macros results unexpected traffic passing when multiple subnets are included in the macro (i.e. VIP subnets)</i></li><li><strong>Status</strong> changed from <i>Not a Bug</i> to <i>New</i></li></ul><p>OK, I was going mostly off the subject + comments which didn't mention the negate specifically. Updated subject.</p> pfSense - Bug #6799: Negating ``<interface> net`` when a VIP exists on the interface results in unintended behaviorhttps://redmine.pfsense.org/issues/6799?journal_id=587612022-02-07T14:18:01ZMarcos M
<ul></ul><p>I was able to reproduce this on 22.01 when using macros, but not when using aliases. Regarding pfBlockerNG, the VIP defaults to localhost now.</p>
<p>Perhaps the long-term solution is to use aliases instead of macros in these scenarios.</p>
<p>Docs redmine <a class="issue tracker-4 status-3 priority-4 priority-default closed" title="Todo: Feedback on Firewall — Configuring firewall rules (Resolved)" href="https://redmine.pfsense.org/issues/12770">#12770</a></p> pfSense - Bug #6799: Negating ``<interface> net`` when a VIP exists on the interface results in unintended behaviorhttps://redmine.pfsense.org/issues/6799?journal_id=686832023-07-24T15:55:32ZMarcos M
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>Assignee</strong> set to <i>Marcos M</i></li></ul> pfSense - Bug #6799: Negating ``<interface> net`` when a VIP exists on the interface results in unintended behaviorhttps://redmine.pfsense.org/issues/6799?journal_id=687202023-07-27T00:52:47ZMarcos M
<ul><li><strong>Subject</strong> changed from <i>Using NOT (!) with interface subnet macros results unexpected traffic passing when multiple subnets are included in the macro (i.e. VIP subnets)</i> to <i>Negating ``<interface> net`` when a VIP exists on the interface results in unintended behavior</i></li><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Pull Request Review</i></li></ul><p><a class="external" href="https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/1050">https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/1050</a></p> pfSense - Bug #6799: Negating ``<interface> net`` when a VIP exists on the interface results in unintended behaviorhttps://redmine.pfsense.org/issues/6799?journal_id=688952023-08-05T16:33:37ZKris Phillips
<ul></ul><p>Tested and reproduced. Also tested with patch applied.</p>
<p>Steps to reproduce:</p>
<p>1. Create a LAN rule with Source Any and Destination !LAN Subnets with Allow<br />2. Create a LAN rule with Source Any and Destination LAN Subnets with Block</p>
<p>Without the patch applied, pinging from a LAN host to the LAN interface IP works, even though the rules above would seemingly mean this should be denied.</p>
<p>Pinging with the patch applied after a manual filter reload, pings to the LAN interface don't work as one would expect based on the syntax of the rules. However, pings to 8.8.8.8 work just fine.</p>
<p>Tested with patch applied/not applied on Aug 4th builds of 23.09.</p> pfSense - Bug #6799: Negating ``<interface> net`` when a VIP exists on the interface results in unintended behaviorhttps://redmine.pfsense.org/issues/6799?journal_id=689292023-08-07T19:15:07ZMarcos M
<ul><li><strong>Status</strong> changed from <i>Pull Request Review</i> to <i>Feedback</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>Applied in changeset <a class="changeset" title="Use pf macros for <interface> subnets. Fix #6799 This changes the behavior of '<if> subnet' in ge..." href="https://redmine.pfsense.org/projects/pfsense/repository/2/revisions/85c4a8de0016bc4d192b60fd384af56aa4ba1376">85c4a8de0016bc4d192b60fd384af56aa4ba1376</a>.</p> pfSense - Bug #6799: Negating ``<interface> net`` when a VIP exists on the interface results in unintended behaviorhttps://redmine.pfsense.org/issues/6799?journal_id=700162023-09-30T09:14:39ZAzamat Khakimyanov
<ul></ul><p>Tested on 23.05_1 and on 23.09-DEV ()</p>
<p>I was able to reproduce this issue on 23.05_1 but on 23.09-DEV adding a VIP on LAN had no effect on firewall rule created on LAN with 'LAN net' alias as a Source.</p>
<p>I would say it should be re-tested one more time when 23.09-DEV becomes next stable version.</p> pfSense - Bug #6799: Negating ``<interface> net`` when a VIP exists on the interface results in unintended behaviorhttps://redmine.pfsense.org/issues/6799?journal_id=704382023-10-27T06:18:43ZLev Prokofev
<ul></ul><p>Works as expected on the current Beta build, VIP has not affected the rules.<br /><pre><code class="xml syntaxhl">23.09-BETA (amd64)
built on Mon Oct 23 20:01:00 MSK 2023
FreeBSD 14.0-CURRENT
</code></pre></p> pfSense - Bug #6799: Negating ``<interface> net`` when a VIP exists on the interface results in unintended behaviorhttps://redmine.pfsense.org/issues/6799?journal_id=704402023-10-27T12:43:58ZJim Pingle
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li><li><strong>Target version</strong> set to <i>2.8.0</i></li><li><strong>Plus Target Version</strong> set to <i>23.09</i></li></ul> pfSense - Bug #6799: Negating ``<interface> net`` when a VIP exists on the interface results in unintended behaviorhttps://redmine.pfsense.org/issues/6799?journal_id=706572023-11-06T15:22:39ZJim Pingle
<ul><li><strong>Target version</strong> changed from <i>2.8.0</i> to <i>2.7.1</i></li></ul>