Re: [E] Problems Configuring ATS Layer 4 routing as outbound Proxy

[Alan Carroll <so...@verizonmedia.com>]

A few notes -

The SNI configuration will have no effect on this scenario. Here is a
diagram of the what happens when using an explicit proxy -

https://www.planttext.com/?text=LP11IyD048NlyoiUwLLBqPvoa6giA9P4I3n8o66JRDE5TLSckuR-UuS42xqCotnlthoTtHWKX_XjYLGNF2Fv73NZST0k950ZegBEky3U8gbO7O-cGwdvL_ECmqYYDE6Cv5ctHhcvsyzFegXm-o0QfCYAFDzd5QPfMYzuxNb8jzjx8X7Kgu6rTet85oeZLVQ1yYkVkVJ5BCNTPeFYdMXW7tyGedFQedwonlLuyJmfxeqRccLrlMfjrCr_0ciaAbxtXqD1pWSDDiCf22dpDvmqwnkqCK0GHic2zeph7yz1BgQNd5V6SewUQ2TLZle7

ATS never sees the "Client HELLO" as such, it's just bytes it forwards to
the upstream, and therefore never sees the SNI. SNI based configuration is
only useful if ATS is an implicit proxy.

Testing locally, your scenario works fine for me on master. I will try to
set up to test 9.0.1. Further testing was able to mimic your error by
selecting a port that is not in service on debian.org. Sadly, it appears
that ATS only goes so far as to send a SYN to the upstream - if that is
successful it responds with "200 OK". If the upstream doesn't like that SYN
(in my case, because there is nothing listening on that port) then it sends
a RESET but only after the user agent has sent its Client HELLO. ATS then
closes the connection to the user agent (because of the RESET) with the
result being the same as your reported error.

From what I can tell,"130.89.148.77" is a valid address for a Debian server
in Europe, so that seems reasonable.

The mystery here is why ATS apparently sends a packet with a zero port.
That shouldn't even make it past the next router, but perhaps that is what
is sending the RESET. I don't see that locally even using the same
"CONNECT" request.

Re: [E] Problems Configuring ATS Layer 4 routing as outbound Proxy

[Alan Carroll <so...@verizonmedia.com>]

I can't find a 9.0.1 tag for Traffic Server - did you mean 9.0.1-rc0?
Testing with that I don't see the same problem - it works fine. Are you
running any plugins?

At this point, the best I can suggest is to enable the debug tag "http" and
let me see that output. It should contain the upstream IP address and port
to which ATS tries to connect.