Re: TCP reverse proxy
you're right but this works only with a single protocol managed by haproxy, doesn't it ? My idea was to have an ACL for each of these standard protocols in order to have a specific backend. Regards, Emmanuel *Adoptez l'éco-attitude.* N'imprimez ce courriel que si c'est vraiment nécessaire 2012/5/7 Willy Tarreau w...@1wt.eu Hi Emmanuel, On Fri, Apr 20, 2012 at 09:02:07AM +0200, Emmanuel Bézagu wrote: As haproxy already accepts to reverse proxy ssl and ssh, would it be possible to support protocols as OpenVPN, tinc or XMPP ? Haproxy will work with any TCP-based protocol which does not report addresses or ports inside the payload. For instance, it works well on SSH, SMTP, LDAP, RDP, PeSIT, SSL, etc... but not on FTP, most RPC, etc... In general, any protocol which can easily be translated will work. I think this is the case for all those above, but you might prefer testing to be sure. Regards, Willy
Re: TCP reverse proxy
On 8 May 2012 20:24, Emmanuel Bézagu emmanuel.bez...@gmail.com wrote: you're right but this works only with a single protocol managed by haproxy, doesn't it ? My idea was to have an ACL for each of these standard protocols in order to have a specific backend. 1) That's why there are different ports for different protocols; just put haproxy on each protocol's native port; 2) MY EYES THEY BURN! Seriously, Comic Sans when posting to mailing lists? Didn't your mother teach you /any/ manners? ;-) J 2012/5/7 Willy Tarreau w...@1wt.eu Hi Emmanuel, On Fri, Apr 20, 2012 at 09:02:07AM +0200, Emmanuel Bézagu wrote: As haproxy already accepts to reverse proxy ssl and ssh, would it be possible to support protocols as OpenVPN, tinc or XMPP ? Haproxy will work with any TCP-based protocol which does not report addresses or ports inside the payload. For instance, it works well on SSH, SMTP, LDAP, RDP, PeSIT, SSL, etc... but not on FTP, most RPC, etc... In general, any protocol which can easily be translated will work. I think this is the case for all those above, but you might prefer testing to be sure. Regards, Willy -- Jonathan Matthews Oxford, London, UK http://www.jpluscplusm.com/contact.html
Re: TCP reverse proxy
On Tue, May 08, 2012 at 08:35:26PM +0100, Jonathan Matthews wrote: On 8 May 2012 20:24, Emmanuel Bézagu emmanuel.bez...@gmail.com wrote: you're right but this works only with a single protocol managed by haproxy, doesn't it ? My idea was to have an ACL for each of these standard protocols in order to have a specific backend. 1) That's why there are different ports for different protocols; just put haproxy on each protocol's native port; I think understand what Emmanuel is trying to do : use a single incoming port for multiple protocols when it's not easy/possible to open more. Sometimes you really need this on home networks. But even in professional networks you might need to control that the incoming traffic is what you expect it to be. Emmanuel, with 1.5-dev9 that I just released a few minutes ago, you can have your ACLs match arbitrary payload contents. However this means that your protocols need to talk first (eg: not like SSH/SMTP/FTP) and that you know what to check there at precise locations. 2) MY EYES THEY BURN! Seriously, Comic Sans when posting to mailing lists? Didn't your mother teach you /any/ manners? ;-) Jonathan, are you reading a mailing list in HTML ? Seriously ? Didn't your mother tell you that reading mails in HTML format was the best way to catch malware and to contribute to botnets, especially when these are public lists ? Shame on you both then ! :-) Willy
Re: TCP reverse proxy
Hi Emmanuel, On Fri, Apr 20, 2012 at 09:02:07AM +0200, Emmanuel Bézagu wrote: As haproxy already accepts to reverse proxy ssl and ssh, would it be possible to support protocols as OpenVPN, tinc or XMPP ? Haproxy will work with any TCP-based protocol which does not report addresses or ports inside the payload. For instance, it works well on SSH, SMTP, LDAP, RDP, PeSIT, SSL, etc... but not on FTP, most RPC, etc... In general, any protocol which can easily be translated will work. I think this is the case for all those above, but you might prefer testing to be sure. Regards, Willy
