[Bug 294541] Sporadic "cannot allocate memory" from pf

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294541

            Bug ID: 294541
           Summary: Sporadic "cannot allocate memory" from pf
           Product: Base System
           Version: 15.0-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: perandersson@outlook.com

I'm having sporadic "cannot allocate memory" from pf when loading a table with
ip 750 000 DDoS addresses. Sometimes it works, sometimes it doesn't.

SPORADIC ERR MSG:
# service pf reload
/usr/local/etc/pf.conf:36: cannot define table ddos: Cannot allocate memory
pfctl: Syntax error in config file: pf rules not loaded

It doesn't seem to be related to the VM-ware VPS RAM memory, as changing the
amount doesn't make the sporadic errors go away.

Note: I'm not sure this on my end or not.

=> /etc/sysctl.conf:
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.tcp.drop_synfin=1
net.pf.request_maxcount=7500000
kern.maxfiles=25000

=> /usr/local/etc/pf.conf:
set limit table-entries 7500000
table <ddos> persist file "/usr/local/etc/pf.ddos.list"
block in quick from <ddos> to any

# pfctl -sm
states        hard limit   100000
src-nodes     hard limit    10000
frags         hard limit     5000
table-entries hard limit  7500000
anchors       hard limit        0
eth-anchors   hard limit        0

# pfctl -sa
INFO:
Status: Enabled for 2 days 01:32:59           Debug: Urgent

State Table                          Total             Rate
  current entries                       58
  searches                         8875032           49.8/s
  inserts                           205628            1.2/s
  removals                          205570            1.2/s
Counters
  match                             375590            2.1/s
  bad-offset                             0            0.0/s
  fragment                               0            0.0/s
  short                                  0            0.0/s
  normalize                              2            0.0/s
  memory                                 0            0.0/s
  bad-timestamp                          0            0.0/s
  congestion                             0            0.0/s
  ip-option                              0            0.0/s
  proto-cksum                            0            0.0/s
  state-mismatch                       123            0.0/s
  state-insert                           0            0.0/s
  state-limit                            0            0.0/s
  src-limit                              0            0.0/s
  synproxy                               0            0.0/s
  map-failed                             0            0.0/s
  translate                              0            0.0/s

TIMEOUTS:
tcp.first                   120s
tcp.opening                  30s
tcp.established           86400s
tcp.closing                 900s
tcp.finwait                  45s
tcp.closed                   90s
tcp.tsdiff                   30s
sctp.first                  120s
sctp.opening                 30s
sctp.established          86400s
sctp.closing                900s
sctp.closed                  90s
udp.first                    60s
udp.single                   30s
udp.multiple                 60s
icmp.first                   20s
icmp.error                   10s
other.first                  60s
other.single                 30s
other.multiple               60s
frag                         60s
interval                     10s
adaptive.start            60000 states
adaptive.end             120000 states
src.track                     0s

The firewall never loads on boot, there is always error message during boot.
To load the ddos table after boot, I always need to:

1. Remark the table <ddos> in /usr/local/etc/pf.conf
2. Restart pf with "service pf restart"
3. After being disconnected, log in back again, and run "service pf restart" or
"service pf start".

-- 
You are receiving this mail because:
You are the assignee for the bug.