Dynamic hosts not updating properly in "Allowed Hostnames"



  • A few days ago I upgraded from version 2.1.5 to version 2.2.4 (Which means I'm currently running 2.2.4).

    Almost immediately after the upgrade I started experiencing problems with dyndns hosts I'd added to the captive portal "Allowed Hostnames" section.

    I'm not exactly sure what the problem is, but here is what I've tried (no observable success with any of these):

    • Editing and saving the hostname

    • Deleting and re-adding the hostname

    • Renaming and adding a new hostname

    • Calling the computer horrible and insulting names

    There are only two leads I have as to where the problem lies:

    • Resolver logs complaining "filterdns: NOT clearing entry from table"

    • "ipfw -x 2 table all list" shows old addresses, but not current addresses

    I could not find anything related to this on the forums (this is not the issue where tables aren't updated after reboots).  Over time, the problem does seem to go away, but I'm not sure how or why.

    If I haven't provided enough info, please let me know what I should supply.

    Help me. some wan, you're my only hope!


  • Banned

    https://redmine.pfsense.org/issues/4746
    https://redmine.pfsense.org/issues/4931

    Move on to some alternative solutions, this won't work anytime soon.



  • @doktornotor:

    https://redmine.pfsense.org/issues/4746

    I mentioned that the addresses do appear in the table after a reboot, which means that it isn't #4746, or am I missing something?

    @doktornotor:

    https://redmine.pfsense.org/issues/4931

    I unfortunately do not understand how a problem with dhcp leases applies here.  It's well past bedtime, so that may not be surprising.  Could you please explain how this affects my issue?

    Thanks,

    Jason


  • Banned

    Hostnames in CP passthrough are broken. Clear enough now?



  • @doktornotor:

    Hostnames in CP passthrough are broken. Clear enough now?

    Then shouldn't there be an issue logged for "Hostnames in CP passthrough are broken" so that people who search for matching issues when experiencing a rather severe fault get a meaningful result rather than having to draw flaky conclusions from unrelated matches?

    @doktornotor:

    Move on to some alternative solutions, this won't work anytime soon.

    So what firewall solution do you suggest moving to?  Or is there another alternate solution?  Because I'm not sure how to find an alternate solution to the problem "stuff isn't working".  Maybe if I knew what stuff wasn't working it would be easier to find an alternate.  It's difficult to avoid the "not working stuff" if you do not know what to avoid.

    For example, is this a general problem with dynamic IPs updating?  Is it limited to the CP?  Are there existing workarounds?

    If you were trying to be helpful, then please provide or link to more information.  Because telling people to find an alternate solution to a problem that has only been identified as "something in the firewall isn't working" is a recommendation4 to find an alternate platform.

    If you're trying to show how special you are and how much you know, and what a cool person you are, you failed and ended up looking like a dick.  You look like a dick because I did research before posting, I specifically mentioned that my problem did not match existing issues, and mentioned how and why it didn't match.  And your response was that it matched the issue that I just showed it didn't match. (And for the record, the zones do, eventually update themselves.  It just takes a really long time).

    Now it would be great if I could get more info as to what is and isn't working, so that I can decide how to work around this problem.  Info that would be helpful include (but is not limited to):

    • Would a downgrade be the best option?  If so, what version should I downgrade to?

    • Is there a different way to do the same thing, for example using firewall rules instead of captive portal exclusions.

    • What is causing the problem, and are there unsupported ways to fix it that introduce other issues that may be more acceptable to me.

    • What is the ETA on getting this fixed?

    • Is there a manual way to fix the problem (which would be acceptable to me depending on when the patch is expected)?

    • etc…

    )Just for the record, I'm not trying to be nasty or difficult, but this is supposed to be a technical forum, and the only responses I've received have not provided any help at all.)



  • @rjdza:

    There are only two leads I have as to where the problem lies:

    • Resolver logs complaining "filterdns: NOT clearing entry from table"

    • "ipfw -x 2 table all list" shows old addresses, but not current addresses

    Try this one:
    Open /etc/inc/captiveportal.inc
    Goto line 617

    Look for this one :

    							mwexec("/sbin/ipfw -x {$cpzoneid}    {$g['tmp_path']}/macentry_{$cpzone}.rules.tmp");
    

    Change it to

    							mwexec("/sbin/ipfw -x {$cpzoneid} -q {$g['tmp_path']}/macentry_{$cpzone}.rules.tmp");
    

    The -q options seems important, but omitted here.

    Now, when you edit your "AllowedHostNames" ones  (Portal interface), all IP's (the ones from will "AllowedHostNames") will be present in the tables 3 and 4.

    But : when booting, nothings is inserted (yet). See function captiveportal_allowedip_configure_entry($ipent, $ishostname = false) for explanation.

    I understood that this should be the job of the task "filterdns", I've got one running with correct settings:

    73975  -  Is     0:00.38 /usr/local/sbin/filterdns -p /var/run/filterdns-cpzone1-cpah.pid -i 300 -c /var/etc/filterdns-cpzone1-captiveportal.conf -y 2 -d 1
    
    

    Even the resolver log shows these good looking:

    Aug 27 10:43:13 	filterdns: adding entry 90.45.217.219 to table 4 on host home.brit-hotel-fumel.fr
    Aug 27 10:43:13 	filterdns: adding entry 90.45.217.219 to table 3 on host xxx.xxx-hotel-fumel.fr
    Aug 27 10:43:12 	filterdns: adding entry 46.105.79.38 to table 4 on host xxx.me
    Aug 27 10:43:12 	filterdns: adding entry ::2001:41d0:2:927b:0:0 to table 4 on host xxxx.me
    Aug 27 10:43:12 	filterdns: adding entry 5.196.43.182 to table 3 on host xxx-domaine.fr
    Aug 27 10:43:12 	filterdns: adding entry ::2001:41d0:2:927b:0:0 to table 3 on host xxx-domaine.fr
    Aug 27 10:43:12 	filterdns: adding entry 5.196.43.182 to table 4 on host xxx-domaine.fr
    Aug 27 10:43:12 	filterdns: adding entry ::2001:41d0:2:927b:0:0 to table 4 on host xxx-domaine.fr
    Aug 27 10:43:12 	filterdns: adding entry 5.196.43.131 to table 4 on host xxx-hotel-fumel.fr
    Aug 27 10:43:12 	filterdns: adding entry ::2001:41d0:2:927b:0:0 to table 4 on host xxx-hotel-fumel.fr
    Aug 27 10:43:12 	filterdns: adding entry 46.105.79.38 to table 3 on host xxx.me
    Aug 27 10:43:12 	filterdns: adding entry ::2001:41d0:2:927b:0:0 to table 3 on host kroeb.me
    Aug 27 10:43:12 	filterdns: adding entry 5.196.43.131 to table 3 on host xxx-hotel-fumel.fr
    Aug 27 10:43:12 	filterdns: adding entry ::2001:41d0:2:927b:0:0 to table 3 on host xxx-hotel-fumel.fr
    

    The resolving part goes great (edit: although the IPv6 seem strange to me !) !
    The nasty one is : in reality, NOTHING gets inserted in tables 3 and 4 (ipfw) (my -x is 2, the Portal service firewall).
    This is what https://redmine.pfsense.org/issues/4746 is all about.

    I guess, when an IP changes in one of your Dyndns URL, the IP isn't updated in the tables neither.
    "fiilterdns" is broken, It can't "insert" into tables 3 & 4 using "ipfw".

    What up ? -q is missing there also ?? (this was a wild shot)

    My question : I tried to look at this "filterdns" in Git … I know it isn't a FreeBSD 'tool', so I guess its a pfSEnse utility.
    Probably written in C ... good. Was writing several years 'C' for a living.
    Where can I find it ? I just want to take a look at it.

    edit adding (trying to add) IPv6 in tables that are used, in my case, in the firewall ipfw working for a Captive Portal that doesn't know shit about Ipv6 is .. well .. suspect at least - useless at most ;)


  • Banned

    Yeah, adding IPv6 is completely useless, CP doesn't work with IPv6 at all.


Log in to reply