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

    Cannot define table bogonsv6

    Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
    16 Posts 4 Posters 4.4k 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.
    • B
      bardelot
      last edited by

      There exists no traditional IPv6 bogons list only the full version, so I assume this was the reason to transition the IPv4 list to the full one as well. Here's the previously mentioned commit.

      The IPv6 list currently contains around 65'000 and the IPv4 list around 5000 entries. Lookups against tables are very fast and the lookup time on a table with 50'000 entries is only slightly more than for one holding 50 entries. If you still prefer the old IPv4 list you can disable bogons filtering on the interface and instead add a custom firewall rule on top using the old URL with an URL table alias.

      The update interval of the bogons list should indeed be decreased as a monthly schedule for a full bogons list, which may get updated multiple times a day, is too low.

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

        It would seem to me that having a basic version of the bogons list should be the pfsense default, and those who wish to to use the full version (and update it every few days) can do so via a url-alias/cron job. And probably offer gzipped versions in addition to .txt.

        Otherwise bogon downloads from files.pfsense.org will soon consume over 1 TeraByte/month (rough estimate based on the number of pfsense "live installs" and ~1MB per bogons/bogonsv6) for little to none apparent benefits …

        1 Reply Last reply Reply Quote 0
        • N
          NOYB
          last edited by

          My understanding is that an appropriate update interval is under investigation.  There is typically a significant lag between addresses being assigned and removed from the bogons list and becoming an active site.  Probably doesn't need updated as frequently as it may seem.  Don't panic.

          If you want to use one of the other bogon lists, perhaps the easiest way would be to edit the /etc/rc.update_bogons.sh script.

          If you want a different update schedule that can be changed in /etc/crontab and cron section of /cf/conf/config.xml

          I've seen an increase in the bogon blocks with the full list.  I think it is overall a positive change.

          1 Reply Last reply Reply Quote 0
          • N
            NOYB
            last edited by

            @bardelot:

            How much memory does your system have? If I remember correctly the default tables-entries should be 200'000 unless you have less than 100MB of RAM in which case it is 100'000.

            I've also seen this issue on system with more than 4GB RAM.  Seems like there may be a variable somewhere that needs to be of a larger type.

            http://php.net/manual/en/language.types.integer.php

            "
            The size of an integer is platform-dependent, although a maximum value of about two billion is the usual value (that's 32 bits signed). 64-bit platforms usually have a maximum value of about 9E18. PHP does not support unsigned integers. Integer size can be determined using the constant PHP_INT_SIZE, and maximum value using the constant PHP_INT_MAX since PHP 4.4.0 and PHP 5.0.5.
            "

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

              @NOYB:

              My understanding is that an appropriate update interval is under investigation.  There is typically a significant lag between addresses being assigned and removed from the bogons list and becoming an active site.  Probably doesn't need updated as frequently as it may seem.  Don't panic.

              True, an advanced dropdown option to change the bogons update interval from monthly, weekly (default) to daily might be appropriate for most users. I also see the transition to the full bogons list as inevitable now that all IPv4 addresses have been assigned.

              @NOYB:

              I've also seen this issue on system with more than 4GB RAM.  Seems like there may be a variable somewhere that needs to be of a larger type.

              If 200'000 entries is the required minimum on all systems now, one could change the following code in filter.inc

              	/* User defined maximum table entries in Advanced menu. */
              	if ($config['system']['maximumtableentries'] <> "" && is_numeric($config['system']['maximumtableentries']))
              		$limitrules .= "set limit table-entries {$config['system']['maximumtableentries']}\n";
              
              

              to

              	/* User defined maximum table entries in Advanced menu. */
              	$maxentries = is_numeric($config['system']['maximumtableentries']) ? $config['system']['maximumtableentries'] : "200000";
              	$limitrules .= "set limit table-entries {$maxentries}\n";
              
              
              1 Reply Last reply Reply Quote 0
              • N
                NOYB
                last edited by

                As mentioned by cmb in another thread, the bandwidth required to support more frequent updates needs to be considered as well.  Going from once a month to once a day is x30.  However once a day is almost certainly overkill.  Major sites just don't come and go that quickly.  Even once addresses have ben assigned.

                I'm confident they will figure it out and have an appropriate update schedule.

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

                  @NOYB:

                  Major sites just don't come and go that quickly.  Even once addresses have ben assigned.

                  It's not 'major sites' that I'm worried about. I can imagine a case where a roadwarrior has been assigned a dynamic IP from a newly acquired IP range (formerly bogon) by his ISP, and is trying to connect to a pfsense VPN but is blocked by his office's pfSense default block bogon WAN rule.

                  Edit: Also with the latest changes the uptime / reliability of files.pfsense.org server has become a (greater) issue; that server will need to distribute TeraBytes worth of bogons/bogonsv6 data every month to 150K+ "live installs" and that functionality can't be easily delegated to dozens of mirrors due to security concerns.

                  1 Reply Last reply Reply Quote 0
                  • N
                    NOYB
                    last edited by

                    I would consider an ISP that's getting directly assigned IP's to be a major site.  And they are not typically going to be moving that quickly.

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

                      Well it seems to me that unless the bogons update frequency is increased to at least weekly updates (or default is switched back to the basic version of the bogon files), it could result to infrequent and hard-to-troubleshoot connectivity issues for some people.

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

                        I've also seen this issue on system with more than 4GB RAM.  Seems like there may be a variable somewhere that needs to be of a larger type.

                        Indeed, FreeBSD uses a 32-bit integer to determine the physical memory size in bytes 1 and thus pf fails to correctly set the table-entries limit 2. Submitted the previous patch to bump the default value to 200000.

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