Project

General

Profile

Bug #4296

Using the same FQDN in multiple aliases causes static entries to be lost

Added by Jim Pingle about 4 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
High
Assignee:
Ermal Luçi
Category:
Rules/NAT
Target version:
Start date:
01/25/2015
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.2
Affected Architecture:

Description

If aliases exist that have both FQDN entries and IP address or network entries, and the same FQDN entries are in multiple aliases, the alias is eventually cut down to only the resolved FQDN entries and the static entries are lost.

It is OK immediately after a filter reload, but eventually only the FQDN resolved entries remain.

One pair of aliases that can exhibit this behavior is:

        <alias>
            <name>AdminHosts</name>
            <address>10.93.223.0/25 10.93.223.128/27 10.93.221.0/27 10.93.223.192/26 10.93.220.30/32 server2.example.com 10.48.84.252/32 10.43.6.66/32 10.43.22.43/32 10.68.6.8/32 server1.example.com 10.19.14.160/28 192.0.2.0/24 192.168.10.0/24 10.95.22.253/32</address>
            <descr><![CDATA[Hosts that can access remote admin systems]]></descr>
            <type>network</type>
            <detail><![CDATA[Blah||Blah||Blah||Blah||Blah||Blah||Blah||Blah||Blah||Blah||Blah||Blah||Blah||Blah||Blah]]></detail>
        </alias>
        <alias>
            <name>Jim</name>
            <address>server1.example.com server2.example.com 10.68.6.8/32 10.19.14.160/28 192.0.2.0/24</address>
            <descr><![CDATA[Jim]]></descr>
            <type>network</type>
            <detail><![CDATA[Blah||Blah||Blah||Blah||Blah]]></detail>
        </alias>

DNS entries exist for server1.example.com (10.42.42.11) and server2.example.com (10.42.42.12)

: cat /var/etc/filterdns.conf 
pf server2.example.com AdminHosts
pf server1.example.com AdminHosts
pf 10.93.223.0/25 AdminHosts
pf 10.93.223.128/27 AdminHosts
pf 10.93.221.0/27 AdminHosts
pf 10.93.223.192/26 AdminHosts
pf 10.93.220.30/32 AdminHosts
pf 10.48.84.252/32 AdminHosts
pf 10.43.6.66/32 AdminHosts
pf 10.43.22.43/32 AdminHosts
pf 10.68.6.8/32 AdminHosts
pf 10.19.14.160/28 AdminHosts
pf 192.0.2.0/24 AdminHosts
pf 192.168.10.0/24 AdminHosts
pf 10.95.22.253/32 AdminHosts
pf server1.example.com Jim
pf server2.example.com Jim
pf 10.68.6.8/32 Jim
pf 10.19.14.160/28 Jim
pf 192.0.2.0/24 Jim

And this results in:

: pfctl -T show -t Jim
   10.42.42.11
   10.42.42.12

Associated revisions

Revision f087d453 (diff)
Added by Renato Botelho about 4 years ago

Do not start filterdns during boot until a proper fix is done. Ticket #4296

Revision e691957f (diff)
Added by Renato Botelho about 4 years ago

Do not start filterdns during boot until a proper fix is done. Ticket #4296

History

#1 Updated by Ermal Luçi about 4 years ago

  • Assignee set to Ermal Luçi

#2 Updated by Chris Buechler about 4 years ago

An easily and quickly replicable test case, add two aliases, testalias1 and testalias2.

testalias1 contents:
1.2.3.4/32
4.3.2.1/32
example.com/32

testalias2 contents:
9.8.7.6/32
8.7.6.5/32
example.com/32

Save and apply changes. It might be fine at this point, or might be missing the static entries. If the static entries are present, edit both testalias1 and testalias2 and add a second hostname to both. Then apply changes and check the table contents and the static entries will be missing. You'll have logs along the lines of:

Mar 11 19:43:07    filterdns: Different hostnames(4.3.2.1 - example.com) resolve to same ip address
Mar 11 19:43:07    filterdns: Different hostnames(4.3.2.1 - example.com) resolve to same ip address
Mar 11 19:43:07    filterdns: Different hostnames(9.8.7.6 - example.com) resolve to same ip address
Mar 11 19:43:07    filterdns: Different hostnames(9.8.7.6 - example.com) resolve to same ip address
Mar 11 19:43:07    filterdns: Different hostnames(8.7.6.5 - example.com) resolve to same ip address
Mar 11 19:43:07    filterdns: Different hostnames(8.7.6.5 - example.com) resolve to same ip address

#3 Updated by Ermal Luçi about 4 years ago

  • Status changed from Confirmed to Feedback

Workaround has been put in place.

#4 Updated by Chris Buechler about 4 years ago

  • Status changed from Feedback to Resolved

this is fixed. It appears there may be some issue during package reinstallation, judging by what Jim P saw in testing, though I couldn't seem to replicate that. I suspect that's a separate issue if it's replicable at all.

#5 Updated by Bipin Chandra about 4 years ago

i believe this issue still persists as of 2.2.1 alix nanobsd when u have aliases with both ip and fqdn in more than one alias and for me the issue started showing up after a while

#6 Updated by Jim Pingle about 4 years ago

  • Status changed from Resolved to Confirmed
  • Target version changed from 2.2.1 to 2.2.3

Reopening this since it's still broken even on 2.2.2. Renato had a lead on a fix, which I confirmed worked, but Ermal had some issues with how it was implemented.

For those running AMD64 on 2.2.x, a patched binary may be used for testing:

fetch -qo /root/filterdns.fixed http://files.pfsense.org/jimp/filterdns.fixed
chmod 555 /root/filterdns.fixed
killall -9
mv /usr/local/sbin/filterdns /usr/local/sbin/filterdns.orig
cp -p /root/filterdns.fixed /usr/local/sbin/filterdns

And then edit/save/apply an alias in the GUI.

#7 Updated by Ermal Luçi almost 4 years ago

  • Status changed from Confirmed to Feedback

A conditional branch did not have the proper test.

#8 Updated by Jim Pingle almost 4 years ago

  • Status changed from Feedback to Resolved

Looks good. All of my former problem test cases check out, all of the entries are present at boot time, after filter sync, and after several resolve intervals.

Also available in: Atom PDF