Forum Replies Created
I know this is an old thread, but has anyone had any success with a proxy in front of cerberus? I’ve been tasked with implementing this type architecture and hoping to be able to find a solution that doesn’t involve replacing cerberus.
I’ve configured a Citrix ADC as a reverse proxy for HTTPS and SFTP connections. It works fine except that I don’t currently have a way for the IP Manager to understand the source IP of SFTP connections. HTTPS handles this with a header (X-Forwarded-For).
I recently tried to get this working (for SFTP) as well and believe it may be a feature request at this point.
We use Citrix ADCs for reverse proxy and after following their documentation for TCP/IP header insertion in TCP payload, I found that Cerberus denies connections made with this feature enabled and generates the error “Connection is not an SSH 2.0 connection”. Remove the header insertion and connections come through just fine, except that the true client IP is not known by Cerberus and the IP manager will block the reverse proxy IP instead.
If this is on the development team’s radar or if someone is accomplishing this with Citrix ADCs or other reverse proxies I’d love to hear more.
My Cerberus version is 18.104.22.168 which appears to be the latest.
The actual packet received by the Cerberus server has X-Forwarded-For in it, but the Cerberus Log is not referencing it. Not sure what I could tell the reverse proxy vendor given the fact that the header is being appended properly. Perhaps I’m missing something or there is a bug in this version of Cerberus… does the case sensitivity of the header field matter in any way?
Update: I blocked my IP and verified it is processing the X-Forwarded-For properly – so it is just the Log that is not representing that information apparently.
I added a HTTP version of my configuration so I could inspect the packets easily and verified X-Forwarded-For is in the received packets. Unfortunately, the Cerberus Log is still showing the Netscaler’s SNIP instead of the X-Forwarded-For IP.
Thanks for your reply. Good to know it should be working for HTTPS – now to figure out why it isn’t.