Project

General

Profile

Bug #4746

captive portal allowed hostnames not loaded into table at boot time

Added by Chris Buechler over 4 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Captive Portal
Target version:
Start date:
06/04/2015
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.2.x
Affected Architecture:

Description

Configure CP with one or more passthrough hostnames, and filterdns runs correctly and logs that it's adding entries:

Jun  4 20:13:29 pfs22-CPtest1 filterdns:     adding entry 208.123.73.73 to table 3 on host connect.pfsense.org
Jun  4 20:13:29 pfs22-CPtest1 filterdns:     adding entry ::2610:160:11:11:0:0 to table 3 on host pfsense.org
Jun  4 20:13:29 pfs22-CPtest1 filterdns:     adding entry 208.123.73.69 to table 3 on host pfsense.org
Jun  4 20:13:29 pfs22-CPtest1 filterdns:     adding entry 208.123.73.73 to table 4 on host connect.pfsense.org
Jun  4 20:13:31 pfs22-CPtest1 filterdns:     adding entry 208.123.73.69 to table 4 on host pfsense.org

but it's not actually in the table after boot.

# ipfw -x 2 table all list
---table(0)---
0.0.0.0/0 49
---table(3)---
---table(4)---

Edit and save one of the entries and they all are loaded into the tables correctly. Reboot and they're gone again.

Associated revisions

Revision fabb4b03 (diff)
Added by Ermal Luçi over 4 years ago

Ticket #4746 Correctly set global variables to be used by hostnames cod epaths

Revision 3378289a (diff)
Added by Ermal Luçi over 4 years ago

Ticket #4746 Correctly set global variables to be used by hostnames cod epaths

History

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

  • Status changed from Confirmed to Feedback

Actually filterdns was not updated with changes done to ipfw patches for 10.1.
Now it should properly do its task.

#2 Updated by Chris Buechler over 4 years ago

this change could also be what completely broke CP (see #4751)

#3 Updated by Chris Buechler over 4 years ago

  • Status changed from Feedback to Confirmed

no change here. Logs show during boot:

Jun 17 21:19:25 pfs22-CPtest3 filterdns:     adding entry ::2610:160:11:11:0:0 to table 3 on host pfsense.org
Jun 17 21:19:25 pfs22-CPtest3 filterdns:     adding entry 208.123.73.69 to table 3 on host pfsense.org
Jun 17 21:19:25 pfs22-CPtest3 filterdns:     adding entry ::2610:160:11:11:0:0 to table 4 on host pfsense.org
Jun 17 21:19:25 pfs22-CPtest3 filterdns:     adding entry 208.123.73.69 to table 4 on host pfsense.org

but a 'table all list' comes back empty. Restart filterdns and it logs same again, but the tables are again all empty.

#4 Updated by Chris Buechler over 4 years ago

no change from last comment. filterdns is running with the correct instance ID for -y, logs that it's adding entries like shown in previous comment, but tables end up empty. Go into the CP instance, edit and save one of the hostname entries, and the IPs are added to the tables.

#5 Updated by Chris Buechler over 4 years ago

  • Assignee deleted (Ermal Luçi)

#6 Updated by Chris Buechler over 4 years ago

  • Target version changed from 2.2.3 to 2.3

#7 Updated by Davide Cottignoli over 4 years ago

As stated in version 2.2.3 changelog, this bug has to be resolved but now, it doesn't work also if you add FQDN in the hostname table and don't reboot o restart the service. Only IP address table works.

#8 Updated by Phillip Davis over 4 years ago

Yes, the 2.2.3 New Features and Changes page says that this is fixed in 2.2.3, but here in Redmine it says target 2.3
https://doc.pfsense.org/index.php/2.2.3_New_Features_and_Changes
Which is it? Or half and half?

#9 Updated by Jim Thompson about 4 years ago

  • Assignee set to Luiz Souza

#10 Updated by Davide Cottignoli about 4 years ago

Is there a workaround for this bug in 2.2.2-2.2.4 ?

#11 Updated by Jonatan Hazell about 4 years ago

We got the same issue. I can add/delete allowed hostnames but they are not loaded, not even by reloading the service.

Any work around for 2.2.4?

#12 Updated by Jonatan Hazell about 4 years ago

If we try to delete Allowed hostnames, this is the result I get in the logs: (the list is empty in GUI though...)

Oct 19 14:19:06 filterdns: failed to resolve host msftncsi.com will retry later again.
Oct 19 14:19:06 filterdns: COULD NOT clear entry 0:0:2a02:26f0:e6:: from table 3 on host www.msftncsi.com will retry later
Oct 19 14:19:06 filterdns: clearing entry 0:0:2a02:26f0:e6:: from table 3 on host www.msftncsi.com
Oct 19 14:19:06 filterdns: COULD NOT clear entry 0:0:2a02:26f0:e6:: from table 3 on host www.msftncsi.com will retry later
Oct 19 14:19:06 filterdns: clearing entry 0:0:2a02:26f0:e6:: from table 3 on host www.msftncsi.com
Oct 19 14:19:06 filterdns: adding entry ::2001:16d8:1:2:0:0 to table 3 on host www.msftncsi.com
Oct 19 14:19:06 filterdns: adding entry ::2001:16d8:1:2:0:0 to table 3 on host www.msftncsi.com
Oct 19 14:19:06 filterdns: COULD NOT clear entry 0:0:2a02:26f0:e6:: from table 4 on host www.msftncsi.com will retry later
Oct 19 14:19:06 filterdns: clearing entry 0:0:2a02:26f0:e6:: from table 4 on host www.msftncsi.com
Oct 19 14:19:06 filterdns: COULD NOT clear entry 0:0:2a02:26f0:e6:: from table 4 on host www.msftncsi.com will retry later
Oct 19 14:19:06 filterdns: clearing entry 0:0:2a02:26f0:e6:: from table 4 on host www.msftncsi.com
Oct 19 14:19:06 filterdns: adding entry ::2001:16d8:1:2:0:0 to table 4 on host www.msftncsi.com
Oct 19 14:19:06 filterdns: adding entry ::2001:16d8:1:2:0:0 to table 4 on host www.msftncsi.com
Oct 19 14:19:06 filterdns: failed to resolve host msftncsi.com will retry later again.
Oct 19 14:19:06 filterdns: COULD NOT clear entry ::2a02:26f0:41:29d:0:0 from table 4 on host www.apple.com will retry later
Oct 19 14:19:06 filterdns: clearing entry ::2a02:26f0:41:29d:0:0 from table 4 on host www.apple.com
Oct 19 14:19:06 filterdns: COULD NOT clear entry ::2a02:26f0:41:28a:0:0 from table 4 on host www.apple.com will retry later
Oct 19 14:19:06 filterdns: clearing entry ::2a02:26f0:41:28a:0:0 from table 4 on host www.apple.com
Oct 19 14:19:06 filterdns: COULD NOT clear entry ::2a02:26f0:41:29a:0:0 from table 4 on host www.apple.com will retry later
Oct 19 14:19:06 filterdns: clearing entry ::2a02:26f0:41:29a:0:0 from table 4 on host www.apple.com
Oct 19 14:19:06 filterdns: COULD NOT clear entry ::2a02:26f0:41:29d:0:0 from table 3 on host www.apple.com will retry later
Oct 19 14:19:06 filterdns: clearing entry ::2a02:26f0:41:29d:0:0 from table 3 on host www.apple.com
Oct 19 14:19:06 filterdns: COULD NOT clear entry ::2a02:26f0:41:28a:0:0 from table 3 on host www.apple.com will retry later
Oct 19 14:19:06 filterdns: clearing entry ::2a02:26f0:41:28a:0:0 from table 3 on host www.apple.com
Oct 19 14:19:06 filterdns: COULD NOT clear entry ::2a02:26f0:41:29a:0:0 from table 3 on host www.apple.com will retry later
Oct 19 14:19:06 filterdns: clearing entry ::2a02:26f0:41:29a:0:0 from table 3 on host www.apple.com
Oct 19 14:19:06 filterdns: adding entry ::2a02:26f0:18:18c:0:0 to table 3 on host www.apple.com
Oct 19 14:19:06 filterdns: adding entry ::2a02:26f0:18:1a1:0:0 to table 3 on host www.apple.com
Oct 19 14:19:06 filterdns: adding entry ::2a02:26f0:18:18c:0:0 to table 4 on host www.apple.com
Oct 19 14:19:06 filterdns: adding entry ::2a02:26f0:18:1a1:0:0 to table 4 on host www.apple.com

#13 Updated by Jonatan Hazell about 4 years ago

Sorry for spamming. I have not added any IPv6 addresses so it's very strange that they are added at all?
This might be another issue maybe?

#14 Updated by Luiz Souza about 4 years ago

Jonatan Hazell wrote:

Sorry for spamming. I have not added any IPv6 addresses so it's very strange that they are added at all?
This might be another issue maybe?

No this is okay. The v6 address you see, comes from the hostnames you added in 'allowed hostnames'.

#15 Updated by Luiz Souza about 4 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100

Fixed in 2.3 and 2.2.x.

There were two bugs here:

- A few malformed rules in the initialisation rules (at system startup), was breaking the parsing of rules (2.3 specific);

- filterdns was not adding the resolved address to ipfw tables.

This is why the CP tables are empty after a reboot. At the system startup the system skips the hostnames as the network may need a few seconds to initialise. It is a filterdns task update those tables as soon as the network come up.

#16 Updated by Jonatan Hazell about 4 years ago

Thanks.
We're running 2.2.4 and it is still not working, can't add Allowed Hostnames: they are listed in GUI but not loaded.
I've tried rebooting and restarting CP service + filter reload, doesn't help.

#17 Updated by Jonatan Hazell about 4 years ago

Actually, pfSense has loaded ONE of hostnames, but no more (we got about 10 hostnames listed).

#18 Updated by Kill Bill about 4 years ago

Obviously it will NOT be working in a version released months before the fix?! Use the latest 2.2.5 snapshot.

#19 Updated by Jonatan Hazell about 4 years ago

Updated to 2.2.2-DEVELOPMENT (20151019-1916), it is still not working. Only a few of the Allowed Hostnames are working, seems random.

Resolver Log still shows problems with clearing entries:

Oct 26 11:03:23     filterdns: adding entry ::2610:160:11:11:0:0 to table 3 on host www.pfsense.org
Oct 26 11:03:23     filterdns: adding entry 208.123.73.69 to table 3 on host www.pfsense.org
Oct 26 11:03:23     filterdns: adding entry ::2610:160:11:11:0:0 to table 4 on host www.pfsense.org
Oct 26 11:03:23     filterdns: adding entry 208.123.73.69 to table 4 on host www.pfsense.org
Oct 26 11:01:11     filterdns: COULD NOT clear entry 23.5.108.224 from table 4 on host www.apple.com will retry later
Oct 26 11:01:11     filterdns: clearing entry 23.5.108.224 from table 4 on host www.apple.com

Nothing is added when I try to add www.pfsense.org for example. The entry does not show up when I run ipfw -x 2 table all list. It should resolve to 208.123.73.69.

#20 Updated by Kill Bill about 4 years ago

You need a snapshot that had a chance of including the patch; i.e., the one built AFTER the patch was committed. I thought it'd be very obvious, but apparently you decided that using a week old one would be a great idea. Sigh. You can check what's included by

cat /etc/version.lastcommit

#21 Updated by Chris Buechler about 4 years ago

  • Status changed from Feedback to Resolved
  • Target version changed from 2.3 to 2.2.5

Kill Bill: be nice, please.

Jonatan: use the newest available 2.2.5 snapshot and this will work.

Confirmed fixed. There is an outstanding issue in that functionality with IPv6, opened #5345 for that.

#22 Updated by Jonatan Hazell about 4 years ago

Confirmed working here. Thank you!

Kill Bill: Actually, I chose the latest snapshot, the same day I got the reply here. I didn't check the lastcommit though, will do that from now on. Thanks for the info.

Also available in: Atom PDF