Forum Discussion
vitalsign0_2058
Nimbostratus
NimbostratusCannot get reverse proxy for Lync 2013 to work.
We have our public IP being NAT'd through our firewall to the reverse proxy address indicated in the iApp, doesn't work. I can ping the address internally. External access still doesn't work.
Any ideas?
Firomsa_Degefa_I can Browse the below links both from internal and external and it prompts for credential https://lyncweb.domain.org/CertProv/CertProvisioningservice.svc https://lyncpool.domain.org/CertProv/CertProvisioningservice.svc
but the problem is when i try to sign in using mobile device it prompts with error message "We can not sign you in. check your account and try later"
Any help is appriciated
That's good to know.
The next step would be to run tcpdump/ssldump on the LTM to identify what's happening when client traffic hits it: https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10209.html
It will be easier to read if you use tcpdump's filtering to narrow down your capture to just the client traffic vlan and client/VS IP addresses. You should be able to view the dump files in Wireshark as well.
vitalsign0_2058Tried it, don't see any new entries as we try to connect.
In your config, lyncweb.domain.org isn't in the secure_reverse_proxy iRule that forwards traffic to the RP server pool. Requests for that FQDN will be dropped since there is no default pool for that VS.
- Looks like that wasn't in the iHealth config from June 5. You can add a log statement to that rule see how far the request is getting (you'll need to disable strictness on the iApp first) and tail /var/log/ltm from the command line while trying to connect to see the log entries: when HTTP_REQUEST { switch -glob [string tolower [HTTP::host]] { lyncweb.domain.org* { log local0. "Request for [HTTP::host] forwarded to reverse proxy pool." pool Lync2013_reverse_proxy_front_end_4443_pool } { pool Lync2013_reverse_proxy_front_end_4443_pool } meet.domain.org* { pool Lync2013_reverse_proxy_front_end_4443_pool } dialin.domain.org* { pool Lync2013_reverse_proxy_front_end_4443_pool } lyncdiscover.domain.org* { pool Lync2013_reverse_proxy_front_end_4443_pool } } }
- vitalsign0_2058lyncweb.domain.org is in the iRule. when HTTP_REQUEST { switch -glob [string tolower [HTTP::host]] { lyncweb.domain.org* { pool Lync2013_reverse_proxy_front_end_4443_pool } { pool Lync2013_reverse_proxy_front_end_4443_pool } meet.domain.org* { pool Lync2013_reverse_proxy_front_end_4443_pool } dialin.domain.org* { pool Lync2013_reverse_proxy_front_end_4443_pool } lyncdiscover.domain.org* { pool Lync2013_reverse_proxy_front_end_4443_pool } }
- Chase_Abbott
Employee
That would definitely drop a connection. Guessing there's no vIP? If so, wonder what's responding to ICMP...
- Chase_Abbott
Can you navigate to:
https://lyncweb.domain.org/CertProv/CertProvisioningservice.svc https://lyncpool.domain.org/CertProv/CertProvisioningservice.svc
Both should prompt for credentials. If this fails, and you're not using the BigIP as an outbound gateway for the web servers, make sure SNAT is enabled and using available IPs. The connection closed is not something that should be happening unless the BigIP cannot hit the web server properly.
Technically the reverse proxy is just a SNAT port forward and can even be run as a fast L4 with no proxy functionality. Also, remember to make sure the internal node for the reverse proxy is set to port 4443 and not 443. This is how Lync knows the difference between external and internal connections.
Else, you may need to wireshark on the web server and BigIP to see where the connection is actually going.
- vitalsign0_2058
Internal is "lyncpool.domain.org" (no override). External is "lyncweb.domain.org".
All SAN certs we are using are from Digicert.
Remote Certificate Subject: CN=lyncweb.domain.org, Issuer: CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc, C=US. Elapsed Time: 259 ms. Validating the certificate name. The certificate name was validated successfully.
Additional DetailsHost name lyncdiscover.domain.org was found in the Certificate Subject Alternative Name entry. Elapsed Time: 1 ms. Testing the certificate date to confirm the certificate is valid. Date validation passed. The certificate hasn't expired.
Additional DetailsThe certificate is valid. NotBefore = 3/9/2015 12:00:00 AM, NotAfter = 3/16/2016 12:00:00 PM Elapsed Time: 0 ms. Testing HTTP authentication methods for URL https://lyncdiscover.domain.org/Autodiscover/AutodiscoverService.svc/root/user. HTTP authentication test failed.
Additional DetailsException details: Message: The underlying connection was closed: An unexpected error occurred on a receive. Type: System.Net.WebException Stack trace: at System.Net.HttpWebRequest.GetResponse() at Microsoft.Exchange.Tools.ExRca.Extensions.RcaHttpRequest.GetResponse() Exception details: Message: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. Type: System.IO.IOException Stack trace: at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count) at System.Net.Security._SslStream.StartFrameHeader(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security._SslStream.StartReading(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security._SslStream.ProcessRead(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.TlsStream.Read(Byte[] buffer, Int32 offset, Int32 size) at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size) at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead) Exception details: Message: An existing connection was forcibly closed by the remote host Type: System.Net.Sockets.SocketException Stack trace: at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags) at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) Elapsed Time: 509 ms.
- Chase_Abbott
Remember topology will have two URL's one internal and one for external. By default, the internal URL is the FQDN of the internal Lync pool (but you're allowed to override). Are you using a single namespace for external and internal functionality or separate names? Something like:
Internal: lyncpool.domain.internal External: lyncpool.domain.com
Lync will put all of these names into a cert request by default but validate that any cert answering for external and internal have all of the names a client is attempting.
And are you using externally signed certs for the external names?
- vitalsign0_2058
Ok the external web service URL is not working internally (lyncweb.domain.org). Other simple URLs are working internally.
Externally nothing works.
Web server name points to our reverse proxy in DNS.
- Chase_Abbott
In my experience, 90% of the time, this is a certificate issue (especially for OSX). The Lync client runs two authentication methods, one for the SIP registration, and a second for the Lync web services. This web service path uses an HTTPS-based auth via web ticketing services. Try navigating to the following via browser:
https://"lyncwebservice".domain.com/CertProv/CertProvisioningservice.svc
You should be prompted for user credentials. Enter your regular domain auth (whatever the client is using). You'll get a return via svcutil.exe with Front End Pool data and other neat stuff.
If that works, you know the web service URL is working. You should also be able to put https://meet.domain.com/CertProv/CertProvisioningservice.svc and get the same result. In my case, I just used CNAME's to redirect autodiscover and other webservices to the lyncsvc.domain.com external name published in Topology.
If you cannot get to that name, either the certificate does not have all of the names required for the web ticket service to create a token, OR the certificate cannot be properly validated. All of these things will break HTTP auth. The testconnectivity tool should allow you to expand the results and give you some more detail.
- vitalsign0_2058
We get this when testing from Microsoft's tool,
Testing HTTP authentication methods for URL https://lyncdiscover.domain.org/Autodiscover/AutodiscoverService.svc/root/user. HTTP authentication test failed.
Additional DetailsException details: Message: The underlying connection was closed: An unexpected error occurred on a receive.
