* Nerius Landys <lan...@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, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
