Accept PROXY protocol

[Alan DeKok]

On Jul 22, 2021, at 7:22 AM, Lineconnect <nabble at felix.world> wrote:
> 
> we're running the FreeRADIUS server in a Kubernetes cluster and accepting only RadSec connections and forwarding the requests with Traefik as TCProute to FreeRADIUS. 
> However it would be nice to preserve the actual IP address of the sender in the requests. Traefik has the opportunity to forward the requests with the PROXY protocol. 
> Is there any change to accept and interpret the requests correct with the PROXY protocol in FreeRADIUS? Hopefully i haven't overlooked something in the documentation. 

  The documentation fully describes all of the features of the server.  If it doesn't say that the PROXY protocol is supported, it's because the PROXY protocol is not supported.

  We're happy to accept patches, though.

> After enabling i see only things like this('radiusd -fxxx'): 
> ```
> Thu Jul 22 10:12:01 2021 : Info: Ready to process requests
> Thu Jul 22 10:12:09 2021 : Debug:  ... new connection request on TCP socket
> Thu Jul 22 10:12:09 2021 : Debug: Listening on auth+acct from client (10.244.11.70, 36504) -> (*, 2083, virtual-server=felix-radsec)
> Thu Jul 22 10:12:09 2021 : Debug: Waking up in 0.4 seconds.
> Thu Jul 22 10:12:09 2021 : Debug: (0) (TLS) Initiating new session
> Thu Jul 22 10:12:09 2021 : Debug: (0) (TLS) Setting verify mode to require certificate from client
> Thu Jul 22 10:12:09 2021 : Debug: (0) Reading from socket 11
> READ FROM SSL 342
> 00: 50 52 4f 58 59 20 54 43 50 34 20 37 37 2e 34 37 

  That's just text "PROXY TCP ..."

> 10: 2e 36 38 2e 31 31 30 20 31 30 2e 32 34 34 2e 31 
> 20: 31 2e 37 30 20 34 34 33 34 35 20 32 30 38 33 0d 
> 30: 0a

  That's the rest of the PROXY header.

> 16 03 01 01 20 01 00 01 1c 03 03 01 87 ca 71 
> 40: 59 fb 6b f8 d3 bb cd d4 db d3 e1 08 1f 1b e2 fc 
...

  and presumably the SSL header.

  TBH, it's probably not too hard to add support for this.

  Right now, the server core assumes that the TCP connection IP/port is where the data comes from.  So it would have to separate the TCP connection from the client connection information.

  It's probably less than 1000 lines of code to add this for TCP/TLS connections.  But the developers are largely booked with a ton of other things, so this is on the "nice, but perhaps one day" list.

  If you're willing to start poking at it, you can open a GitHub PR for this.  Even if the code doesn't work perfectly, having *some* code means it's much more likely to get integrated into the server.

  Alan DeKok.