🚀 go-pugleaf

* Nerius Landys <landys@nerius.com> [2010-10-20 22:30]:
> >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".

that's about right

> I suppose there's not way to get around this problem...

right.

> Maybe ask the operating system if the port is "bound" before completing
> the handshake with the client, otherwise send RST to the client?

askin before isn't possible. you do not know that the backend will
accept a connection based on a previous connection being accepted. and
doing a check before replying with a syn defeats the prupose anyway.

sending an RST back if the backend doesn't accept the connection,
well, we could do that, but it still doesn't solve anything - clients
treat "established connection terminated" very differently then
"connection not accepted".

there is no way to "solve" this. synproxy is not for everyday use.

-- 
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting