Hi all,
exactly! I had a TAC for that last July!
The engineer told me that it had never been reported since my SR.
I will quote his exact words:
"There is a possibility to change the listening port, however this is
currently not supported. In order to change it you need to enable the
experimental menu:
https://<vcs_ip>/setaccess
pwd: qwertsys
Next in the menu CUCM/CUPS Proxy - HTTP proxy configuration you can
change it. Port 80 and 443 are used by the administration atm
(Maintenance -> Tools -> Port usage -> Local inbound ports).
For official support on this we need the enhancement to be added to the
product first.
"
The problem that i told him is that you cannot use 443 since it is
dedicated for the GUI...
BR
Antonis
On 27/2/2015 11:05 μμ, Ryan Ratliff (rratliff) wrote:
CSCup73547 is of interest here.
While you are playing with this check out the experimental section of
xconfig.
-Ryan
On Feb 27, 2015, at 3:31 PM, Justin Steinberg <[email protected]
<mailto:[email protected]>> wrote:
good write up.
I wonder what would happen if the _collab-edge._tls SRV returned port
443 with an internet firewall in front of Expressway translating 443
to 8443. I wonder whether the Jabber clients read the port from the
SRV or whether they have 8443 hardcoded.
I'll try to test that on my next deployment.
On Fri, Feb 27, 2015 at 2:02 PM, Anthony Holloway
<[email protected]
<mailto:[email protected]>> wrote:
All,
Just a heads up to my fellow techs, I am at Caribou Coffee today
and my Jabber will not sign in.
The user experience is as follows: Jabber discovers MRA
successfully, but when trying to authenticate it sends an auth
request to:
https://collab-edge.company.com:8443/oauthcb
The logs show that an HTTP timeout occurs: (Found
in C:\Users\<you>\AppData\Local\Cisco\Unified
Communications\Jabber\CSF\Logs\csf-unified.log)
2015-02-27 09:14:40,081 INFO [0x00000af0]
[etutils\src\http\CurlHttpUtils.cpp(1163)] [csf.httpclient]
[http::CurlHttpUtils::configureEasyRequest] - *-----* Making HTTP
request to: https://collab-edge.company.com:8443/oauthcb [3]
2015-02-27 09:14:40,081 INFO [0x00000af0]
[etutils\src\http\CurlHttpUtils.cpp(1738)] [csf.httpclient]
[http::CurlHeaders::CurlHeaders] - Number of Request Headers : 1
2015-02-27 09:14:40,081 DEBUG [0x00000af0]
[etutils\src\http\CurlHttpUtils.cpp(1345)] [csf.httpclient]
[http::CurlHttpUtils::configureEasyRequest] - Checking for proxy
information for request [3] ...
2015-02-27 09:14:40,081 DEBUG [0x00000af0]
[ts\csf-netutils\src\http\Request.cpp(83)] [csf.httpclient]
[http::Request::getProxy] - No Proxy will be used per
configuration of this request
2015-02-27 09:14:40,081 DEBUG [0x00000af0]
[etutils\src\http\CurlHttpUtils.cpp(1429)] [csf.httpclient]
[http::CurlHttpUtils::configureEasyRequest] - No proxy information
available [3].
2015-02-27 09:14:40,081 DEBUG [0x00000af0]
[etutils\src\http\CurlHttpUtils.cpp(1502)] [csf.httpclient]
[http::CurlHttpUtils::configureEasyRequest] - Setting connect
timeout value in milliseconds to : 10000
2015-02-27 09:14:40,081 DEBUG [0x00000af0]
[etutils\src\http\CurlHttpUtils.cpp(1511)] [csf.httpclient]
[http::CurlHttpUtils::configureEasyRequest] - Setting transfer
timeout value in milliseconds to : 30000
2015-02-27 09:14:40,081 DEBUG [0x00000af0]
[etutils\src\http\CurlHttpUtils.cpp(1514)] [csf.httpclient]
[http::CurlHttpUtils::configureEasyRequest] - HTTP Request Configured.
2015-02-27 09:14:40,081 DEBUG [0x00000af0]
[ls\src\http\BasicHttpClientImpl.cpp(482)] [csf.httpclient]
[http::performCurlRequest] - About to perform curl connection
request...
2015-02-27 09:14:40,096 DEBUG [0x00000af0]
[netutils\src\http\CurlHttpUtils.cpp(307)] [csf.httpclient]
[http::CurlHttpUtils::logPhaseData] - Pre connect phase. Resolved
IP: 23.23.23.23
2015-02-27 09:14:50,079 DEBUG [0x00000af0]
[etutils\src\http\CurlHttpUtils.cpp(1679)] [csf.httpclient]
[http::CurlHttpUtils::logOperationTiming] - Network IO timestamps:
[name lookup = 0.016 ; connect = 0 ; ssl connect = 0 ;
pre-transfer = 0 ; start-transfer = 0 ; total = 10 ; redirect = 0]
2015-02-27 09:14:50,079 INFO [0x00000af0]
[ls\src\http\CurlAnswerEvaluator.cpp(117)] [csf.httpclient]
[http::CurlAnswerEvaluator::curlCodeToResult] - curlCode=[28]
error message=[Connection timed out after 10000 milliseconds]
result=[CONNECTION_TIMEOUT_ERROR] fips enabled=[false]
2015-02-27 09:14:50,079 INFO [0x00000af0]
[ls\src\http\BasicHttpClientImpl.cpp(410)] [csf.httpclient]
[http::executeImpl] - *-----* HTTP response from:
https://collab-edge.company.com:8443/oauthcb [3] -> 0.
2015-02-27 09:14:50,079 ERROR [0x00000af0]
[ls\src\http\BasicHttpClientImpl.cpp(414)] [csf.httpclient]
[http::executeImpl] - There was an issue performing the call to
curl_easy_perform: CONNECTION_TIMEOUT_ERROR
2015-02-27 09:14:50,079 DEBUG [0x00000af0]
[etutils\src\http\HttpRequestData.cpp(90)] [csf.httpclient]
[http::HttpRequestData::returnEasyCURLConnection] - Returning
borrowed EasyCURLConnection from request : 3
2015-02-27 09:14:50,079 DEBUG [0x00000af0]
[utils\adapters\EdgeUtilsAdapter.cpp(255)] [csf.netutils.adapters]
[netutils::adapters::EdgeUtilsAdapter::isRequestTransformed] -
isRequestTransformed: result:0. originalPath: '/oauthcb'
pathFromUrlUsed: '/oauthcb'.
2015-02-27 09:14:50,079 DEBUG [0x00000af0]
[tutils\src\http\HttpRequestData.cpp(105)] [csf.httpclient]
[http::HttpRequestData::~HttpRequestData] - Destroying instance of
Request data, with request: 3
And then I get the message in Jabber which says "Cannot
Communicate with the Server"
<image.png>
It turns out that if I try to telnet to collab-edge.company.com
<http://collab-edge.company.com/> on port 8443, it fails:
<image.png>
And a Wireshark reveals that the TCP three way handshake never
happens, with two TCP SYN re-transmits, before finally timing out.
<image.png>
Interestingly, this free WiFi network does not prevent me from
accessing the standard HTTPS port of 443, and I can actually login
to the collab-edge.company.com <http://collab-edge.company.com/>
web interface and login. So, it would seem like they are treating
non-standard ports differently here. If I knew of a non standard
HTTP port (E.g., 8080, 8088, etc.) to attempt to connect to on the
public internet...wait a minute:
http://portquiz.net/
Yes! This site was setup for exactly what I need: validating my
theory, and I was right. You cannot hit this website on any port
other than the standard HTTP/HTTPS ports from here at Caribou Coffee.
Also, just to be thorough, I've ruled out my PC, my Jabber client,
our MRA solution, our enterprise network, basically everything, by
simply flipping over to my mobile hotspot on my iPhone and it
works immediately.
Here are the logs from the same process as above while using my
mobile hotspot:
2015-02-27 09:25:01,991 INFO [0x00000798]
[etutils\src\http\CurlHttpUtils.cpp(1163)] [csf.httpclient]
[http::CurlHttpUtils::configureEasyRequest] - *-----* Making HTTP
request to: https://collab-edge.company.com:8443/oauthcb [7]
2015-02-27 09:25:01,991 INFO [0x00000798]
[etutils\src\http\CurlHttpUtils.cpp(1738)] [csf.httpclient]
[http::CurlHeaders::CurlHeaders] - Number of Request Headers : 1
2015-02-27 09:25:01,991 DEBUG [0x00000798]
[etutils\src\http\CurlHttpUtils.cpp(1345)] [csf.httpclient]
[http::CurlHttpUtils::configureEasyRequest] - Checking for proxy
information for request [7] ...
2015-02-27 09:25:01,991 DEBUG [0x00000798]
[ts\csf-netutils\src\http\Request.cpp(83)] [csf.httpclient]
[http::Request::getProxy] - No Proxy will be used per
configuration of this request
2015-02-27 09:25:01,991 DEBUG [0x00000798]
[etutils\src\http\CurlHttpUtils.cpp(1429)] [csf.httpclient]
[http::CurlHttpUtils::configureEasyRequest] - No proxy information
available [7].
2015-02-27 09:25:01,991 DEBUG [0x00000798]
[etutils\src\http\CurlHttpUtils.cpp(1502)] [csf.httpclient]
[http::CurlHttpUtils::configureEasyRequest] - Setting connect
timeout value in milliseconds to : 10000
2015-02-27 09:25:01,991 DEBUG [0x00000798]
[etutils\src\http\CurlHttpUtils.cpp(1511)] [csf.httpclient]
[http::CurlHttpUtils::configureEasyRequest] - Setting transfer
timeout value in milliseconds to : 30000
2015-02-27 09:25:01,991 DEBUG [0x00000798]
[etutils\src\http\CurlHttpUtils.cpp(1514)] [csf.httpclient]
[http::CurlHttpUtils::configureEasyRequest] - HTTP Request Configured.
2015-02-27 09:25:01,991 DEBUG [0x00000798]
[ls\src\http\BasicHttpClientImpl.cpp(482)] [csf.httpclient]
[http::performCurlRequest] - About to perform curl connection
request...
2015-02-27 09:25:02,007 DEBUG [0x00000798]
[netutils\src\http\CurlHttpUtils.cpp(307)] [csf.httpclient]
[http::CurlHttpUtils::logPhaseData] - Pre connect phase. Resolved
IP: 23.23.23.23
2015-02-27 09:25:02,101 DEBUG [0x00000798]
[netutils\src\http\CurlHttpUtils.cpp(316)] [csf.httpclient]
[http::CurlHttpUtils::logPhaseData] - Connection established
2015-02-27 09:25:02,101 DEBUG [0x00000798]
[netutils\src\http\OpenSSLOptions.cpp(29)] [csf.httpclient]
[http::OpenSSLOptions::getOptions] - OpenSSL Options:
SSL_OP_NO_SSLv2 SSL_OP_NO_SSLv3
2015-02-27 09:25:02,101 DEBUG [0x00000798]
[netutils\src\http\CurlHttpUtils.cpp(564)] [csf.httpclient]
[http::CurlHttpUtils::curlSSLCallback] - fqdn :
collab-edge.company.com <http://collab-edge.company.com/>
2015-02-27 09:25:02,101 DEBUG [0x00000798]
[netutils\src\http\CurlHttpUtils.cpp(323)] [csf.httpclient]
[http::CurlHttpUtils::logPhaseData] - SSL handshake phase. SSL
version : SSLv3
There are two lessons here for me:
1. MRA has the potential to fail from free public WiFi networks
(Hotels, Coffee Shops, Airplanes, Submarines, Virgin Galactic,
etc.), and potentially any network, where there is some sort of
traffic filtering going on. In fact, this public WiFi and
filtering traffic is pretty common and people have been proxying
their traffic through their own servers to bypass this limitation.
Case in point.
<http://rogueleaderr.com/post/29855576743/never-again-be-thwarted-by-restrictive-guest>
So, I wonder, is there a Cisco solution, or a commonly used
solution to proxy the MRA traffic (which itself is a proxy of
sorts for FW traversal), to ensure a great user experience no
matter the network they join?
2. I learned how to troubleshoot and identify the problem which
all started from a very unhelpful error message in Jabber "Cannot
communicate with the server" It would be swell if Cisco could use
standard ports (E.g., 443). If that's just not possible for some
developer reason, then another suggestion would be to wait for the
HTTP timeout, then connect to the edge server on a standard port
to validate reach-ability. If this was possible, then they could
raise a warning which states "The network you are on is blocking
port 8443 traffic. Contact your network Administrator for further
assistance." At least then users would be prompted to move off
that network, or attempt an alternative connection method, such as
a mobile hotspot.
I look forward to your thoughts on the matter. Have a nice
weekend all.
/PS Fake names and IP addresses were used to protect the identity
of the real network. All errors and messages are consistent with
the real tests./
_______________________________________________
cisco-voip mailing list
[email protected] <mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected] <mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
