Pls use ingress and custom and from anywhere option

I've used TCP/8080 but with a TLS listener as a work-around for this issue. It wasn't ideal, but it solved the problem and we had limited options as TCP/8080 was one of the few egress ports allowed. I think a better approach is adding a second ELB as you noted.

Hi

Check with 8080 port

Pls let me know is it https u r using as the port mentioned is secure one

In addition u can use Soap port in the protocol and port range definition

Other option is to use udp or icmp in addition to the prtocols used so that
from the pool of ports socket request will be. Handled

Regards
Sunil

--
Thanks & Regards
Sunil Babu K C
+91-81970-35608

Hi Shannon,

Same problem statement and solution/workaround here. Changing such a corporate setup usually is much more time consuming (if successful at all) compared to the changes in CF setup as you describe them below.

Regards,
Bernd

Bernd Krannich
Products & Innovation Technology
SAP SE
Dietmar-Hopp-Allee 16
69190 Walldorf Germany
mailto:bernd.krannich(a)sap.com
www.sap.com<applewebdata://52CF34BC-FCAD-4C8A-90F6-8A24A9EFD5CC/www.sap.com>

Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.

From: Shannon Coen <scoen(a)pivotal.io<mailto:scoen(a)pivotal.io>>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Date: Monday 25 April 2016 at 23:00
To: Cloud Foundry Dev <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] websockets and limitations of AWS ELB

I'm interested to hear from operators how you're supporting websockets for CF on AWS, both for user tailing of app logs from Loggregator, and for apps running on CF that take websocket requests.

Websockets are supported in CF by having a HTTP request containing the Upgrade header reach Gorouter, which will establish a TCP connection to the backend (app instance). Since we need Gorouter to handle the upgrade, your ELB must be configured to listen on a port in TCP mode. However, in TCP mode an ELB wouldn't be able to append the required X-Forwarded-For and X-Forwarded-Proto headers. Assuming you'll keep HTTP over TLS on port 443, you'll need to open an additional port on the ELB for websockets.

To support apps on PWS that take websocket requests, we've added port 4443 to the ELB in TCP mode. In response to feedback that this port is blocked to corporate firewalls, we run a second ELB just for Loggregator, listening on 443 in TCP mode. The domain name for Loggregator's route resolves to this second ELB.

How are you working around this limitation? Do your users have issues with configuring clients to make websocket requests on a non-standard port?

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

I'm interested to hear from operators how you're supporting websockets for
CF on AWS, both for user tailing of app logs from Loggregator, and for apps
running on CF that take websocket requests.

Websockets are supported in CF by having a HTTP request containing the
Upgrade header reach Gorouter, which will establish a TCP connection to the
backend (app instance). Since we need Gorouter to handle the upgrade, your
ELB must be configured to listen on a port in TCP mode. However, in TCP
mode an ELB wouldn't be able to append the required X-Forwarded-For and
X-Forwarded-Proto headers. Assuming you'll keep HTTP over TLS on port 443,
you'll need to open an additional port on the ELB for websockets.

To support apps on PWS that take websocket requests, we've added port 4443
to the ELB in TCP mode. In response to feedback that this port is blocked
to corporate firewalls, we run a second ELB just for Loggregator, listening
on 443 in TCP mode. The domain name for Loggregator's route resolves to
this second ELB.

How are you working around this limitation? Do your users have issues with
configuring clients to make websocket requests on a non-standard port?

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.