Support for proxy_protocol

[yrutschle]

Splitting from #482

[Proxy protocol] is a really simple proxy protocol and there are many examples of code.

Ok, there actually is a library that implements it (https://github.com/kosmas-valianos/libproxyprotocol).

I guess it could be useful to have:

• downstream support: sslh adds the proxy information when connecting to the target. We can specify this with a simple boolean in the protocols section:

protocols:
(
     { name: "ssh"; service: "ssh"; host: "localhost"; port: "22"; 
       keepalive: true; fork: true; tfo_ok: true },
     { name: "tls"; host: "localhost"; port: "4443"; proxy_protocol: true; },  # when forwarding e.g. to nginx
    [...]

that way the downstream process is aware of the client IP.

• upstream support: when sslh is placed e.g. after nginx, specified in the listen section:

listen:
(
   { host: "localhost"; port: "443"; },
   { host: "localhost"; port: "444"; proxy_protocol: true }
);

Here we'd have a "raw" connection on port 443, while 444 would expect a proxy_protocol header. This would change sslh's behaviour in two ways:

• log client IP from the proxy information instead of the socket information
• forward client IP in downstream connections that also support proxy_protocol.
  It might also be possible to use the client IP connection as transparent proxy source IP for downstream connections that wouldn't support proxy_protocol, but I'm not sure.

[yrutschle]

I understand there is no version negociation, so the protocol version needs to be specified in the configuration, so instead it'd be something like proxy_protocol: 1;.

[kosmas-valianos]

Completely unaware of the internals of the project here but just to mention that both PROXY protocol v1 and v2 have a "signature". The code can always use the pp_parse_hdr() to inspect. In case there is no PROXY protocol data then the func will return 0.

[yrutschle]

Thanks for the feedback. It's become clear to me, in fact: You can think of sslh as an intermediate proxy that takes fowarding decisions (e.g. based on SNI in TLS, pick which Web server to connect to).
So the configuration setting would be:

• On the client-facing side, do I want to support PP at all? (and then find whichever version it is)
• On the backend server side, so I want to add PP, and if yes which version?

I guess there could be a special "pass through" mode as well, where client-side PP information is passed to the backend server without touching it. In fact, there could be a trivial sslh probe to dissect a PP header and forward based on the PP target field.

[kosmas-valianos]

I guess there could be a special "pass through" mode as well, where client-side PP information is passed to the backend server without touching it. In fact, there could be a trivial sslh probe to dissect a PP header and forward based on the PP target field.

I think that's the best. In the receiving case you can just always look if the message has PP. In case it has it means it came from yet another proxy with PP enabled. Then you can proxy the message as is. There is no point in parsing the PP header nor generating a new one. Pass through.

Now in the case that a message arrives and doesn't have PP, sslh can generate one itself. That's the part that could be configurable i.e. if you enable PP in sslh it will add a PP header in case the received message doesn't have already. As for the version it is advised to use the v2 as the v1 is kinda phased out but that can be simply a parameter of the configuration. pp: v1/v2

So in summary:

1. Check if the msgs have PP. If they have, proxy normally no matter what the configuration says about PP
2. If they msgs don't have PP and the PP is enabled in sslh then generate and add it (version according to the parameter)
3. If they msgs don't have PP and the PP is disabled in sslh then proxy normally

[yrutschle]

No, number 1 is problematic in the (common) case where sslh is Internet-facing: it gives attackers a vector to target any IP. So a default configuration must not enable PP on the client side, and client-side must only be enabled with sufficient warning that sslh is either internal, or surrounded by enough firewalling.

Also, I think there might be use cases where sslh would receive PP-enabled message, and forwarded them to servers that do not support PP.

That's a lot of combinations :-)

[kosmas-valianos]

I was thinking it more like nginx. It has configuration where you can enable PP at the accepting/receiving side and has configuration to enable PP when proxying to the upstream side. These are 2 complete distinct cases! They are explained here

• The PROXY protocol enables NGINX and NGINX Plus to receive client connection information passed through proxy servers and load balancers such as HAproxy and Amazon Elastic Load Balancer (ELB).
• For a TCP stream, the PROXY protocol can be enabled for connections between NGINX and an upstream server

It's a good read up for inspiration for configuration, usage etc.

[yrutschle]

I just pushed to branch proxyprotocol an experimental version to support proxyprotocol v1 on the backend server side, by adding proxy_protocol: 1; (for version 1) to the appropriate target entry, e.g.:

protocols:
(
     { name: "ssh";  host: "localhost"; port: "9000"; fork: true; transparent: true; resolve_on_forward: true; },
[...]
     { name: "tls";  host: "localhost"; port: "4444"; proxyprotocol: 1;  },
[...]

It seems to work with Apache by adding RemoteIPProxyProtocol On in a site section. As indicated above (and in INSTALL.md) it requires https://github.com/kosmas-valianos/libproxyprotocol which is unfortunately not present in Debian.

I'm interested in feedback!

[cronzevid]

Hey, thanks for the amazing software! I just happened to set up an env, that requires exactly these features, so I tested it out. Unfortunately, I could not get it to work, but I may have easily missed something.

My setup is single-node K3S:

k3s version v1.32.3+k3s1 (079ffa8d)
go version go1.23.6

My own sslh chart, it is pretty basic and uses hostPort. No Services or LoadBalancers.

relevant values.yaml part

image:
  repository: ghcr.io/yrutschle/sslh
  tag: master

config: |
  foreground: true;

  listen:
  (
      { host: "0.0.0.0"; port: "443"; keepalive: true;}
  );

  protocols: (
      {   name: "tls";
          host: "x-ui.web-services.svc.cluster.local";
          port: "41480";
          sni_hostnames: [ "yahoo.com", "www.yahoo.com"];
      },
      {   name: "tls";
          host: "traefik.kube-system.svc.cluster.local";
          port: "443";
          sni_hostnames: [ "*" ];
          proxyprotocol: 2;
      }
  );

Ingress-controller is the default traefik, specifically helm.sh/chart=traefik-34.2.1:

relevant values.yaml part

    ports:
      web:
        port: 8888
        forwardedHeaders:
          insecure: true
        redirections:
          entryPoint:
            to: websecure
            scheme: https
            permanent: true
      websecure:
        port: 4433
        forwardedHeaders:
          insecure: true
        proxyProtocol:
          insecure: true

Port 4433 is mapped via Service, so don't mind that.

And resulting access_log in traefik is this:

10.42.0.241 - - [29/Apr/2025:20:44:00 +0000] "POST /getSecretStatus HTTP/2.0" 200 61 "-" "-" 8 "web-services-x-ui@kubernetes" "http://10.42.0.194:36384" 2ms
Where 10.42.0.241 is sslh's pod IP, and which is <remote_IP_address> for traefik logs format.

I've tried using different configurations, such as switching from tls to http in sslh's config, trying different proxyprotocol versions and different images (2.2.1, master). None of these worked, so I tried to do some debugging. I know this looks ugly as hell, but I think it gets the job done:

tcpdump -i veth272c0e8a -vvvv -n host 10.42.0.232 -X | sed 's# ##g' | grep 0d0a0d0a

So here veth272c0e8a is sslh pod's interface on host system, 10.42.0.232 is IP of this pod and the rest is my attempt to filter out proxyprotocol's signature in HEX. I tried different combinations of this sig multiple times, and seem to find none - so I assumed that sslh never sends it in the first place.

Please let me know if I could be of any help, or if this setup/debug misses something!

[deividxyz]

Hi! Thank you for this awesome software.

I wonder if this option can be added into the command line parameters. Right now I'm using sslh-select head-2025-09-10 running in a Docker container (docker tag: yrutschle/sslh:latest). I don't know if this will be added into a future version but it would be awesome to have this integrated as a CMD parameter. I'm currently using sslh with Traefik and it works great, but without proxyprotocol is not possible to filter spam/hacker IPs.

Thank you in advance!

[yrutschle]

Hello @deividxyz , can you not pass a configuration file to your Docker?
Using the command line when dealing with lists (of listening endpoint or target protocols, in this case) is awkward and inconvenient...

[deividxyz]

UPDATE, now fixed, see docker compose below.

Hi, I've tried passing the cfg file with docker but gives I/O error, see below:

Executing with user 'sslh': sslh --foreground --config=/etc/sslh/sslh.cfg
/etc/sslh/sslh.cfg:file I/O error

My sslh.cfg is below:

listen:
(
    { host: "0.0.0.0"; port: "443"; },
    { host: "[::]"; port: "443"; }
);

protocols:
(
     { name: "ssh"; service: "ssh"; host: "192.168.88.8"; port: "22"; fork: true; },
     { name: "openvpn"; host: "192.168.88.1"; port: "1194"; },
     { name: "tls"; host: "192.168.88.8"; port: "4333"; log_level: 0; proxyprotocol: 2; }
);

Config file can be read from container and has 644 permissions on it. Docker Compose is the following:

networks:
  containers:
    external: true
    name: "containers"

services:
  sslh:
    command: "--foreground --listen=0.0.0.0:443 --config=/etc/sslh/sslh.cfg"
    container_name: "sslh"
    hostname: "sslh"
    image: "ghcr.io/yrutschle/sslh:latest"
    networks:
      - "containers"
    ports:
      - "443:443/tcp"
    volumes:
      - "/share/homes/deivid/deivid/sslh:/etc/sslh"

But when I just use the command, it works (almost equal as the example in the main readme):

--foreground --listen=0.0.0.0:443 --tls=nginx:443 --openvpn=openvpn:1194

EDIT

UPDATE: I fixed it moving the config file in the container outside /etc/sslh to just /:

networks:
  containers:
    external: true
    name: "containers"

services:
  sslh:
    command: "--foreground --config=/sslh.cfg"
    container_name: "sslh"
    hostname: "sslh"
    image: "ghcr.io/yrutschle/sslh:latest"
    networks:
      - "containers"
    ports:
      - "443:443/tcp"
    volumes:
      - "./sslh.cfg:/sslh.cfg"