🚀 go-pugleaf

> Is there a way to get synproxy to send the RST (I _think_ that's what it
> is called) when no service is running on that port?  Or is this a feature?
> Or is there a reason it behaves this way?  Intentional, bug, oversight,
> or missing modifier to my rule?

Hrm I think, after doing a little bit more research, I understand why this
isn't possible.  Maybe you can tell me if I'm right.  Seems that
synproxy completes a TCP connect handshake completely with the client
before even sending anything to the actual service it's proxying.
This is the whole purpose of synproxy.  So, it has a completed handshake,
the client thinks he's "connected", and pf tries to "connect" to the
underlying service, but receives an RST or whatnot, which means
the service isn't running.  It's probably too late to send an RST
to the client at this point, so pf just lets the connection from the
client "hang".

I suppose there's not way to get around this problem...  Any thoughts?
Maybe ask the operating system if the port is "bound" before completing
the handshake with the client, otherwise send RST to the client?