PF PF doesn't load at startup time in FreeBSD 10.1

S3TH76

Member


Messages: 29

Hi,

I have a problem with my PF it seems after all verification made with pfctl -vnf /etc/pf.conf NOT with the rulesets but number of tables and the size of it. Can be adjusted this situation? I can't control the size of tables for zones because are country based IP net blocks.

So first I tried:
Code:
#pfctl -nf /etc/pf.conf
#
...then:
Code:
#pfctl -vnf /etc/pf.conf
#
...and then:
Code:
# pfctl -sa /etc/pf.conf
nat on igb1 inet from 192.x.x.0/27 to ! (igb1) -> (igb1) round-robin
rdr on tun0 inet proto tcp from 172.x.x.x to (tun0) port = ssh -> 127.0.0.1 port 65535
rdr on tun0 inet proto tcp from any to (tun0) port = http -> 192.x.x.x
rdr on tun0 inet proto tcp from any to (tun0) port = https -> 192.x.x.x
rdr on igb1 inet proto tcp from any to (igb1) port = http -> 192.x.x.x
rdr on igb1 inet proto tcp from any to (igb1) port = https -> 192.x.x.x
rdr on igb1 inet proto tcp from any to (igb1) port = ssh -> 192.x.x.x

FILTER RULES:
scrub in all fragment reassemble
block drop in all
... (to much to write down, pf.conf is displayed in next code block) ...


State Table                          Total             Rate
[LEFT]  current entries                      10
  searches                       220516             0.2/s
  inserts                              5752             0.0/s
  removals                          5742             0.0/s
Counters
  match                             18891             0.0/s
  bad-offset                             0               0.0/s
  fragment                               0               0.0/s
  short                                     0               0.0/s
  normalize                              0               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                      1            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[/LEFT]

TIMEOUTS:
tcp.first                        5s
tcp.opening                  5s
tcp.established        1800s
tcp.closing                    5s
tcp.finwait                    5s
tcp.closed                     5s
tcp.tsdiff                      10s
udp.first                       10s
udp.single                     30s
udp.multiple                  30s
icmp.first                      20s
icmp.error                    10s
other.first                     10s
other.single                   20s
other.multiple                20s
frag                                4s
interval                          10s
adaptive.start             1500 states
adaptive.end               5000 states
src.track                     0s

LIMITS:
states          hard limit    10000
src-nodes     hard limit    10000
frags             hard limit     5000
table-entries hard limit   200000

TABLES:
blockedips
block_zone-br_1
block_zone-br_2
block_zone-cn_1
block_zone-cn_2
block_zone-ru_1
block_zone-ru_2
block_zone-tw_1
block_zone-tw_2
block_zone-us_1
block_zone-us_2
others2_block_zone
permit_ggle-bot

OS FINGERPRINTS:
710 fingerprints loaded
...without a single error so I will paste my pf.conf for more detailed info:

Code:
###Interfaces
localhost="127.0.0.1"
openvpn="1194"
nginx="192.X.X.X"
adm="192.X.X.X"

permit_vpn_ssh="172.X.X.X"
permit_ssh="{172.X.X.X, 85.X.X.X, X.X.X.X}"
permit_web="{86.X.X.X, 85.X.X.X, X.X.X.X}"
permit_ftp="{85.X.X.X, 86.X.X.X, X.X.X.X}"

###Tables
table <blockedips> persist file "/etc/pf/../../pf.blockedips.conf"
table <permit_ggle-bot> persist file "/etc/pf/../../pf.permit_ggl-bot.conf"

table <block_zone-cn_1> persist file "/etc/pf/../../IPDeny_CountryZones/cn.zone"
table <block_zone-cn_2> persist file "/etc/pf/../../IPDeny_CountryZones/cn-aggregated.zone"
table <block_zone-ru_1> persist file "/etc/pf/../../IPDeny_CountryZones/ru.zone"
table <block_zone-ru_2> persist file "/etc/pf/../../IPDeny_CountryZones/ru-aggregated.zone"

table <block_zone-us_1> persist file "/etc/pf/../../IPDeny_CountryZones/us.zone"
table <block_zone-us_2> persist file "/etc/pf/../../IPDeny_CountryZones/us-aggregated.zone"
table <block_zone-br_1> persist file "/etc/pf/../../IPDeny_CountryZones/br.zone"
table <block_zone-br_2> persist file "/etc/pf/../../IPDeny_CountryZones/br-aggregated.zone"
table <block_zone-tw_1> persist file "/etc/pf/../../IPDeny_CountryZones/tw.zone"
table <block_zone-tw_2> persist file "/etc/pf/../../IPDeny_CountryZones/tw-aggregated.zone"

table <others2_block_zone> persist file "/etc/pf/../../IPDeny_CountryZones/other/other2-ip-block.zone"

###no filter
set skip on lo0
set skip on lo1

###Options
set block-policy drop
set loginterface igb1

###Optimizations
set optimization aggressive
set timeout { frag 4, tcp.established 1800 }
set timeout { tcp.first 5, tcp.closing 5, tcp.closed 5, tcp.finwait 5 }
set timeout { udp.first 10, udp.single 30, udp.multiple 30 }
set timeout { other.first 10, other.single 20, other.multiple 20 }
set timeout { adaptive.start 1500, adaptive.end 5000 }

###Normalization
scrub in all

###NAT
nat on igb1 from 192.x.x.0/27 to !(igb1) -> (igb1)

###Redir
rdr on tun0 inet proto tcp from $permit_vpn_ssh to (tun0) port 22 -> $localhost port 65535
rdr on tun0 inet proto tcp from any to (tun0) port {80, 443} -> $nginx
rdr on igb1 inet proto tcp from any to (igb1) port  {80, 443}  -> $nginx
rdr on igb1 inet proto tcp from any to (igb1) port  22  -> $adm

###Base ruleset
block in all

###antispoof for all interfaces
block in quick from urpf-failed
antispoof for igb1 inet
antispoof log for $localhost

###Policy of blocking
block in log quick on igb1 from <blockedips> to any

###Blocking OTHERS
block in log quick on igb1 proto {tcp, udp, icmp, ipv6, icmp6} from <others1_block_zone> to any
block in log quick on igb1 proto {tcp, udp, icmp, ipv6, icmp6} from <others2_block_zone> to any

###Blocking CN
block in log quick on igb1 proto {tcp, udp, icmp, ipv6, icmp6} from <block_zone-cn_1> to any
block in log quick on igb1 proto {tcp, udp, icmp, ipv6, icmp6} from <block_zone-cn_2> to any

###Blocking RU
block in log quick on igb1 proto {tcp, udp, icmp, ipv6, icmp6} from <block_zone-ru_1> to any
block in log quick on igb1 proto {tcp, udp, icmp, ipv6, icmp6} from <block_zone-ru_2> to any

###Blocking US
block in log quick on igb1 proto {tcp, udp, icmp, ipv6, icmp6} from <block_zone-us_1> to any
block in log quick on igb1 proto {tcp, udp, icmp, ipv6, icmp6} from <block_zone-us_2> to any

###Blocking BR
block in log quick on igb1 proto {tcp, udp, icmp, ipv6, icmp6} from <block_zone-br_1> to any
block in log quick on igb1 proto {tcp, udp, icmp, ipv6, icmp6} from <block_zone-br_2> to any

###Blocking TW
block in log quick on igb1 proto {tcp, udp, icmp, ipv6, icmp6} from <block_zone-tw_1> to any
block in log quick on igb1 proto {tcp, udp, icmp, ipv6, icmp6} from <block_zone-tw_2> to any

###Accept

pass in log quick on igb1 proto tcp from <permit_ggle-bot> to $nginx port  {80, 443} flags S/SA keep state

pass  in quick on tun0 inet proto tcp from $permit_vpn_ssh to $localhost port  65535 keep state
pass  in quick on igb1 inet proto tcp from any to $adm  port  22 flags S/SA keep state

pass  in quick on igb1 inet proto tcp from $permit_ssh to (igb1)  port 65535 flags S/SA keep state

pass  in quick on igb1 inet proto tcp from any to $nginx port  {80, 443} flags S/SA keep state
pass  in quick on tun0 inet proto tcp from any to $nginx port  {80, 443} flags S/SA keep state
pass  in quick on igb1 inet proto udp from any to (igb1) port $openvpn
pass  out on igb1 all
Can anyone help me with my configuration? To make PF start at FreeBSD startup?

In this actual state of PF configuration at reboot of server it doesn't load at startup and my site doesn't start obviously, because of NAT that PF it make.

Any help is welcome.
 

gkontos

Daemon

Reaction score: 480
Messages: 2,153

If you want to have pf automatically start at boot time then you need to adjust your rc.conf like this:

Code:
pf_enable="YES" ### turn PF on when the computer boots.                         
pf_rules="/etc/pf.conf" ### define the rules for the firewall.
pf_flags="" ### additional flags (none).
pflog_enable="YES" ### turn on packet logging support.
pflog_logfile="/var/log/pflog" ### where to log data to, used with pflogd daemon.
pflog_flags="" ### additional flags (none).
 
OP
OP
S

S3TH76

Member


Messages: 29

First 2 are enabled in my /etc/rc.conf and last 4 are disabled because I don't need packet logging (too complicate for me to replay those packets...too many parameters to "play" with) I prefer a clear text (ascii) log system.
 
OP
OP
S

S3TH76

Member


Messages: 29

Exist a limit of space for buffers in RAM in function of how big are the tables with IP addresses?

The smaller tables (133bytes) can be loaded but more bigger tables (777kb) make PF not start at reboot of server. I know the values for tables are small but still I have problems at reboot...
 

Murph

Well-Known Member

Reaction score: 181
Messages: 297

Bug 192677 causes pfctl(8) to fail when loading larger tables. If memory serves, it hit somewhere around 50,000–65,000 table entries for me, but that number could very well vary significantly for different people / configurations / systems. It is fixed in releng/10.3, stable/10, and head as part of Bug 207463 / r296025.

Upgrade to 10.3, or backport r296025 at your own risk (unsupported, but 10.1 can probably work with 10.3's sys/netpfil/pf and sbin/pfctl, caveat emptor, should possibly not be attempted unless you are comfortable with hacking complex OS code).
 

kpa

Beastie's Twin

Reaction score: 1,807
Messages: 6,318

I did run into that limitation myself with the IPv6 bogon list (which is HUGE) on i386, I don't remember it being a problem on amd64 because of better kernel memory management.
 

Murph

Well-Known Member

Reaction score: 181
Messages: 297

I did run into that limitation myself with the IPv6 bogon list (which is HUGE) on i386, I don't remember it being a problem on amd64 because of better kernel memory management.
The bug in question was just bad logic, with the wrong size of buffer being allocated inside the kernel. It happens to work for smaller cases due to the way that malloc allocates memory, but is guaranteed to fail once you tip past the range. The failure case hit me running 10.2 on amd64 somewhere around 50,000–65,000 table entries (mostly IPv4 in that instance). This particular bug has nothing to do with the maximum kernel memory limit which could possibly be an issue on 32 bit architectures.
 
OP
OP
S

S3TH76

Member


Messages: 29

The bug in question was just bad logic, with the wrong size of buffer being allocated inside the kernel. It happens to work for smaller cases due to the way that malloc allocates memory, but is guaranteed to fail once you tip past the range. The failure case hit me running 10.2 on amd64 somewhere around 50,000–65,000 table entries (mostly IPv4 in that instance). This particular bug has nothing to do with the maximum kernel memory limit which could possibly be an issue on 32 bit architectures.
Indeed, this is my case too. I was having aprox. 200.000 ips(v4) in 10 tables.....


I have a FreeBSD 10.3-RELEASE-p2 on amd64 server.

So, exist an official patch or fix for this problem?

I read all those links, understood what is about it but because I'm not an advanced user in *NIX-like field or programming, I'm not feeling confortable until I know that someone else tried the fix and succeded.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 7,678
Messages: 30,591

I have a FreeBSD 10.3-RELEASE-p2 on amd64 server.

So, exist an official patch or fix for this problem?
If I read things correctly the patch is already implemented on 10-STABLE.
 

Murph

Well-Known Member

Reaction score: 181
Messages: 297

I have a FreeBSD 10.3-RELEASE-p2 on amd64 server.

So, exist an official patch or fix for this problem?
If you are running 10.3, you already have the fix for the problem I mentioned above. Your original post said 10.1, so you would have been hitting that problem. The number 200,000 is most likely the problem for you now on 10.3. Try adding set limit table-entries 1000000 to /etc/pf.conf (pick any number you want for the limit, as long as it's big enough to support your tables, and small enough to prevent you killing the system through excessive kmem).
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 7,678
Messages: 30,591

OP
OP
S

S3TH76

Member


Messages: 29

I added
Code:
set limit table-entries 1000000
to /etc/pf.conf in "Options" section an saved the file then executed service pf restart the response was strange for me:

Code:
#service pf restart
DIsabling pf
Enabling pfpfctl:Bad pool name.
/etc/pf.conf:40: unable to set limit tables-entries 1000000
pfctl: Syntax error in config file: pf rules not loaded
#
I tried with the limit set to 250000, with the same result(I tried 20.000,100.000,250.000).
So... I will comment it out until will get an answer about why it's happening this. Without this rule pfctl is working reasonablly.
 

Murph

Well-Known Member

Reaction score: 181
Messages: 297

I tried with the limit set to 250000, with the same result(I tried 20.000,100.000,250.000).
So... I will comment it out until will get an answer about why it's happening this. Without this rule pfctl is working reasonablly.
pfctl:Bad pool name.
That pool name error is something unrelated to tables and table limits.

/etc/pf.conf:40: unable to set limit tables-entries 1000000
You made a typo. The limit is table-entries (singular), not tables-entries (plural).

I'm slightly confused, however. You are now saying that "pfctl is working reasonably". If that is the case (no errors, PF starting correctly on boot, reloading correctly, etc), then you may not actually need to change the limit.

If you are still having a problem on FreeBSD 10.3, please be specific. You can confirm the current size of the tables (to determine if they are being correctly loaded) with pfctl -vvs Tables.
 
Top