PF Traffic seems slower

[d3crypt]

I recently started using the PF firewall on my server, instead of using no firewall at all (yes, this was stupid). I have noticed that traffic seems to be going much slower than usual. I really doubt that this would be a network problem because It is a VPS on Digital Ocean.

Here is my /etc/pf.conf

###########################
# d3crypt PF Ruleset  #
###########################

### macro name for external interface
ext_if="vtnet0"
int_if ="lo0"

### drop blocked packets
set block-policy drop

### all external traffic on external interface is normalized
### and fragmented packets are reassembled
scrub in on $ext_if all fragment reassemble

### default policy to block all
block in all

### exercise antispoofing on the external interface, but add local
### loopback interface as an exception, to prevent services
### utilizing the local loop from being blocked accidentally
set skip on $int_if
antispoof for $ext_if inet

### block anything coming from sources that we have no back routes for
block in from no-route to any

### block packets that fail a reverse path check. we look up the routing
### table, check to make sure that the outbound is the same as the source
### it came in on. if not, it is probably source address spoofed.
block in from urpf-failed to any

### block probes that can possibly determine our operating system by disallowing
### certain combinations that are commonly used by nmap, queso and xprobe2, who
### are attempting to fingerprint the server.
### * F : FIN  - Finish; end of session
### * S : SYN  - Synchronize; indicates request to start session
### * R : RST  - Reset; drop a connection
### * P : PUSH - Push; packet is sent immediately
### * A : ACK  - Acknowledgement
### * U : URG  - Urgent
### * E : ECE  - Explicit Congestion Notification Echo
### * W : CWR  - Congestion Window Reduced
block in quick on $ext_if proto tcp flags FUP/WEUAPRSF
block in quick on $ext_if proto tcp flags WEUAPRSF/WEUAPRSF
block in quick on $ext_if proto tcp flags SRAFU/WEUAPRSF
block in quick on $ext_if proto tcp flags /WEUAPRSF
block in quick on $ext_if proto tcp flags SR/SR
block in quick on $ext_if proto tcp flags SF/SF

table <bruteforce> persist file "/var/db/blacklist"
block quick from <bruteforce>

### all incoming ssh
pass in on $ext_if proto tcp to any port ssh flags S/SA keep state \
(max-src-conn 10, max-src-conn-rate 10/5, overload <bruteforce> flush)


pass out quick on $ext_if proto { tcp, udp, icmp } to any

 

[SirDice]

Try turning off TSO on your network interface and see if that improves anything. I had a similar issue, enabling PF would significantly impact network performance.

ifconfig vtnet0 -tso

 

[d3crypt]

I tried that and It doesn't seem to make much of a difference. Thanks for trying though.

 

[kbw]

That seems like a lot of work/packet. You should expect it to be slower than doing nothing. How much slower is it?

 

[d3crypt]

That seems like a lot of work/packet. You should expect it to be slower than doing nothing. How much slower is it?

At least a 5-6 seconds longer on every network action. It's pretty bad. Could you suggest any rule changes?

 

[kbw]

I am sorry for not getting back to you sooner. The short answer is, I don't know. Sadly, it takes me forever to make PF do what I want it to do.

As you can measure the delay, or at least notice such a huge delay, I'd suggest trying some testing.
1. Start by looking at CPU usage to see if it's spiking during testing for these delays. Does it spike?
2. Remove some of the rules to see if they impact thru-put. I'd start with those flags.