synproxy slowdown

baot · Nov 9, 2012

Hi. I've got a server running pf that has been displaying some odd (at least to me) behavior.

I use the "synproxy state"[1] option quite a few times in my config without any ill effects that I've noticed until now. I realized it was on every open port except for ssh, so I added it to my ssh line:

Code:

pass in on $ext_if proto tcp from any to $IP port 22 flags S/SA synproxy state

After doing so, scp/sftp/rsync have all slowed down to a crawl! I get ~1/4th the speed I usually do from the server with it enabled there. Remove it, speed goes back to normal. I'm using synproxy state with some other other services that send large amounts of data very quickly (http, torrents, etc) and none of them exhibit this slowdown, so I'm wondering why scp is so slow with it. Here's the rest of my pf.conf, if it matters:

Code:

ext_if = "bge0"
set block-policy drop
scrub in all
block in all
block in quick on $ext_if from any to 255.255.255.255
pass out on $ext_if from any to any
pass out keep state
set skip on lo0
block in quick from urpf-failed
antispoof quick for $ext_if
block in from no-route to any
block drop in log (all)  quick on $ext_if from { 10.0.0.0/8, 172.16.0.0/12, 255.255.255.255/32 } to any
block drop out log (all) quick on $ext_if from any to { 10.0.0.0/8, 172.16.0.0/12, 255.255.255.255/32 }
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
pass in on $ext_if proto tcp from any to $IP port 22 flags S/SA synproxy state
pass in on $ext_if proto tcp from any to $IP port 80 flags S/SA synproxy state
pass in on $ext_if proto tcp from any to $IP port 9999 flags S/SA synproxy state

[1] http://www.openbsd.org/faq/pf/filter.html

J65nko · Nov 10, 2012

From a thread on the OpenBSD misc mailing list:

Code:

> > > why syn proxy is not enabled by default ?
> > Because it has bad side-effects. Like accepting a connection before the
> > actual server accepted it. So it is hard to signal closed ports back.
> any other side-effect ?

claudio stated this way too nice.

let me be super clear here: if you are running synproxy permamnently,
you are an idiot.

why is synproxy there? if you are under a synflood-style attack and
need to protect a backend server, it can save your a**.
running synproxy to "protect" an OpenBSD machine, more so the local
host, is retarded and counterproductive.

think through how synproxy works. it accepts a connection on behalf of
the destination server. once the 3whs is complete, it tries to open a
connection to the backend. now if the backend doesn't take that
connection, the pf synproxy box can only drop the already established
connection. the semantics of establishing and dropping a connection vs
ot taking it from the beginning DO have different semantics. for
example, if you use round-robin dns, the client will NOT move on to
the next IP address if the connection had been accepted and dropped
later. moreover, you are drawing deliberate decisions by the actual
daemon, like the listen backlog, close to pointless. it gets worse
when some form of loadbalancing is in the picture.

synproxy is there because it ca save your a** WHEN YOU ARE UNDER
ATTACK. it is not suitable for all-time all-case use, and can't be.

it once again comes down to "think before pushing random buttons".

BTW this answer is from Henning Brauer one of the OpenBSD pf architects/committers

synproxy slowdown

baot

J65nko