https://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162018-07-26T03:45:29ZpfSense bugtrackerpfSense - Bug #8693: Filter rules error after deleting VIPhttps://redmine.pfsense.org/issues/8693?journal_id=372762018-07-26T03:45:29ZSeth Mosseth.mos@dds.nl
<ul></ul><p>It appears to be fixed in mainline. Inserting the extra address checks that are in current filter.inc on line 3657 and 3677 fix this issue.</p>
<p>Also, the missing keys 1 and 4 are actually the IPv6 vips on the interface. I still can't explain why the phantom mode variables are set though.</p> pfSense - Bug #8693: Filter rules error after deleting VIPhttps://redmine.pfsense.org/issues/8693?journal_id=372782018-07-26T07:26:15ZJim Pingle
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Duplicate</i></li><li><strong>Priority</strong> changed from <i>Very High</i> to <i>Normal</i></li><li><strong>Target version</strong> deleted (<del><i>2.4.4</i></del>)</li></ul><p>Hey Seth, long time no see!</p>
<p>We fixed this in <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: Rule Error On Upgrade 2.4.3 -> 2.4.3-p1 (Resolved)" href="https://redmine.pfsense.org/issues/8518">#8518</a> -- if you look at the last commit referenced on that ticket ( <a class="changeset" title="VIP mode is set unconditionally now, but this code was left behind on RELENG_2_4_3 and is causing..." href="https://redmine.pfsense.org/projects/pfsense/repository/2/revisions/c9159949e06cc91f6931bf2326672df7cad706f4">c9159949e06cc91f6931bf2326672df7cad706f4</a> ) you'll see the mode was being set by a couple lines of code that didn't get removed on RELENG_2_4_3 so the problem didn't appear in master, only in 2.4.3-p1. The added safety belts will prevent similar issues from causing invalid rules, and we've fixed a couple other edge cases that could land in similar trouble.</p> pfSense - Bug #8693: Filter rules error after deleting VIPhttps://redmine.pfsense.org/issues/8693?journal_id=384552018-09-20T14:57:49ZBrian Candlerb.candler@pobox.com
<ul></ul><p>FYI, I just got caught by this same problem, also on 2.4.3-p1. However in my case it was on my WAN interface where I had two IPv4 CARPs and one IPv6 CARP.</p>
<p>In this situation I got the same error message as reported by the OP; adding some debugging to filter.inc showed:</p>
<pre>
# $vips => array (
0 =>
'mode' => 'carp',
'ip' => 'x.x.x.237',
'sn' => '28',
1 =>
'mode' => 'carp',
'ip' => 'x.x.x.234',
'sn' => '28',
2 =>
'mode' => 'carp',
</pre>
<p>After removing the WAN CARP interface it was OK. So I made the change in commit c9159949, added back the IPv6 CARP, and now it generates the rules without this error.</p>