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?
