dlundquist / sniproxy

Proxies incoming HTTP and TLS connections based on the hostname contained in the initial request of the TCP session.
BSD 2-Clause "Simplified" License
2.53k stars 397 forks source link

Failed to initialize listener #0 -- returned -3 #24

Closed ghost closed 11 years ago

ghost commented 11 years ago

Hi,

i'm trying to setup sniproxy, but I keep receiving an error when running it:

root@hestia:/# sniproxy
Failed to initialize listener #0 -- returned -3:
listener 1.2.3.4 8443 {
        protocol tls
        table https

My config looks like this:

user daemon
table http {
    testdomain\.com * 80
}

table https {
       testdomain\.com * 443
}

listener 1.2.3.4 8080 {
    proto http
    table "http"
}
listener 1.2.3.4 8443 {
    proto tls
    table "https"
}

This is in the syslog:

Sep 16 04:49:47 hestia sniproxy: Parsed testdomain.com * 443
Sep 16 04:49:47 hestia sniproxy: Parsed testdomain.com * 80
Sep 16 04:49:47 hestia sniproxy: bind failed

1.2.3.4 is the IP of the server.

What means the returned -3? How can I trace why sniproxy can't create the listner?

Thank you!!

dlundquist commented 11 years ago

Sounds like you have another process listening on port 8443: https://github.com/dlundquist/sniproxy/blob/c49ac6b8/src/listener.c#L267-L270

Check the output of netstat -lptn for another process listening on port 8443.

ghost commented 11 years ago

I was trying to run Sniproxy twice. My mistake :)

It all works great now. Requests are getting proxied. But, for some reason, from 1 computer it doesn't work, and I receive this in the log:

Sep 16 21:05:22 hestia sniproxy: parse() returned -5 Sep 16 21:05:23 hestia sniproxy: Request did not begin with TLS handshake. Sep 16 21:05:23 hestia sniproxy: Unable to parse request from 5.6.7.8:50257

Does this mean that the client uses an old browser or something?

dlundquist commented 11 years ago

@mitch2k That indicates the initial data in the TCP session was not a TLS handshake, it could be the browser on that machines attempted a HTTP connection to an HTTPS site or something more complicated. I would suggest tcpdump and wireshark to troubleshoot this further.