postscreen_upstream_proxy_protocol with both proxied and unproxied clients

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

postscreen_upstream_proxy_protocol with both proxied and unproxied clients

Quanah Gibson-Mount-3
We recently deployed into AWS, and were following
<https://www.agari.com/scaling-postfix-on-aws-with-elastic-load-balancing/>.

However, we found that if we set postscreen_upstream_proxy_protocol=haproxy
we are then no longer able to connect directly to the MTAs to send mail.
Is there any ability to support a mixed mode, where some clients are coming
in via an upstream proxy and some are not?

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Manager, Systems Team
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration
A division of Synacor, Inc
Reply | Threaded
Open this post in threaded view
|

Re: postscreen_upstream_proxy_protocol with both proxied and unproxied clients

Wietse Venema
Quanah Gibson-Mount:
> We recently deployed into AWS, and were following
> <https://www.agari.com/scaling-postfix-on-aws-with-elastic-load-balancing/>.
>
> However, we found that if we set postscreen_upstream_proxy_protocol=haproxy
> we are then no longer able to connect directly to the MTAs to send mail.

Unlike XCLIENT, which sends information AFTER the SMTP handshake,
HaProxy cannot be used in mixed mode, because it sends information
BEFORE the SMTP handshake.

How would Postfix know that the client wants to send HaProxy
information before the SMTP handshake? If it could predict the
future, then I would be rich.

        Wietse

> Is there any ability to support a mixed mode, where some clients are coming
> in via an upstream proxy and some are not?
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Platform Architect
> Manager, Systems Team
> Zimbra, Inc.
> --------------------
> Zimbra ::  the leader in open source messaging and collaboration
> A division of Synacor, Inc
>
Reply | Threaded
Open this post in threaded view
|

Re: postscreen_upstream_proxy_protocol with both proxied and unproxied clients

Wietse Venema
Wietse Venema:

> Quanah Gibson-Mount:
> > We recently deployed into AWS, and were following
> > <https://www.agari.com/scaling-postfix-on-aws-with-elastic-load-balancing/>.
> >
> > However, we found that if we set postscreen_upstream_proxy_protocol=haproxy
> > we are then no longer able to connect directly to the MTAs to send mail.
>
> Unlike XCLIENT, which sends information AFTER the SMTP handshake,
> HaProxy cannot be used in mixed mode, because it sends information
> BEFORE the SMTP handshake.
>
> How would Postfix know that the client wants to send HaProxy
> information before the SMTP handshake? If it could predict the
> future, then I would be rich.
>
> > Is there any ability to support a mixed mode, where some clients are coming
> > in via an upstream proxy and some are not?

I suppose that one could configure a namaddr_list (and use IP address
patterns only) that skips the haproxy protocol handshake.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: postscreen_upstream_proxy_protocol with both proxied and unproxied clients

Quanah Gibson-Mount-3
--On Friday, June 24, 2016 12:26 PM -0400 Wietse Venema
<[hidden email]> wrote:
>
> I suppose that one could configure a namaddr_list (and use IP address
> patterns only) that skips the haproxy protocol handshake.

Ok, the problem is I have no way of knowing what clients will come in via
the haproxy or not. ;)  I think we'll just need to spin up different MTAs
that the haproxy points to, and then move our MX record, and move
everything off the direct connections.

Thanks!

--Quanah


--

Quanah Gibson-Mount
Platform Architect
Manager, Systems Team
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration
A division of Synacor, Inc
Reply | Threaded
Open this post in threaded view
|

Re: postscreen_upstream_proxy_protocol with both proxied and unproxied clients

evidex
In reply to this post by Quanah Gibson-Mount-3
We solved this problem by enabling postscreen on port 26, and forwarding port 25 on the ELB to port 26 on the instance, with Proxy Protocol enabled.

This allows our local clients to connect as normal via port 25 direct to the instance, and remote incoming mail to be processed by postscreen.