Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Alias Table entries grow slowly

    Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
    4 Posts 4 Posters 1.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      phil.davis
      last edited by

      Example: I have an alias "RemoteSites" that has the DynDNS names of all the remote sites that connect in to a central pfSense OpenVPN server. The Alias contains names like:
      site1.dyndns-ip.com
      site2.dyndns-ip.com
      site3.dyndns-ip.com

      A firewall rule allows access from "RemoteSites" into the various OpenVPN site-to-site server listening ports.
      pfSense at each remote site has DynDNS setup so that it keeps its site_n_.dyndns-ip.com IP address up-to-date.
      When the remote pfSense comes up it updates its DynDNS address and starts trying to connect its OpenVPN client to the server site.
      Some time in the next 5 minutes, filterdns wakes up, discovers that an IP address in the "RemoteSites" alias has changed, and adds the new IP address to the alias table in pf. When the remote site tries to connect again, it is allowed in and the OpenVPN comes up.

      The "feature" is that the old IP address/es of that site from yesterday, last week, last month… are left in the table (until the OpenVPN server pfSense end next reboots). So someone else who gets allocated one of those old IP addresses would be allowed into the OpenVPN server ports.
      Admittedly, the security risk is rather low - an attacker would have to be using addresses from the same ISP's DHCP pool and get one of my sites old addresses given to them, then they would have to know the OpenVPN password/secret/key anyway!

      I can see that there might be other use cases of sites that have lots of changing but valid IPs, returning only a subset (or only 1 of them) in response to each DNS query. In that case it could be handy to accumulate the set of all IP addresses ever known for that name.

      After all that, my question is:
      Is it the intended behaviour that filterdns, over time, gradually adds to the list of IP addresses that have matched the names in the Alias list?

      Would it be reasonable/useful to add an option when defining an Alias Table so the user can choose if the table should accumulate over time, or only retain the most recent IP addresses known?

      As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
      If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

      1 Reply Last reply Reply Quote 0
      • D
        dhatz
        last edited by

        @phil.davis:

        Would it be reasonable/useful to add an option when defining an Alias Table so the user can choose if the table should accumulate over time, or only retain the most recent IP addresses known?

        That might be an interesting feature.

        There could a script that periodically expires IPs in tables updated by filterdns if they've not been referenced for X seconds e.g.

        /sbin/pfctl -t table_name -T expire 86400

        1 Reply Last reply Reply Quote 0
        • B
          bardelot
          last edited by

          @dhatz:

          There could a script that periodically expires IPs in tables updated by filterdns if they've not been referenced for X seconds e.g.

          /sbin/pfctl -t table_name -T expire 86400

          With cron you won't even need an additional script. Just install the cron package and add a new entry using the expiretable command.

          e.g. /usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 RemoteSites

          1 Reply Last reply Reply Quote 0
          • E
            eri--
            last edited by

            With latest snapshots those entries will be cleaned up.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.