Bug #4296
closed
Using the same FQDN in multiple aliases causes static entries to be lost
0%
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
Updated by Chris Buechler over 9 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
Updated by Ermal Luçi over 9 years ago
- Status changed from Confirmed to Feedback
Workaround has been put in place.
Updated by Chris Buechler over 9 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.
Updated by Bipin Chandra over 9 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
Updated by Jim Pingle over 9 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.
Updated by Ermal Luçi over 9 years ago
- Status changed from Confirmed to Feedback
A conditional branch did not have the proper test.
Updated by Jim Pingle over 9 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.