Forum Discussion
jwashburn_48359
Nimbostratus
NimbostratusLync 2013 using iApp - Reverse Proxy Issues
Using iApp f5.microsoft_lync_server_2010_2013.v1.2.0 with a new Lync 2013 deployment.
Having some problems getting internal mobile clients working. We are currently testing with the Microsoft Lync Analyzer tool as well as Ipads and a Windows 8 tablet.
We have 2 F5. One is in our DMZ the other is internal. On the DMZ f5 we have set it up as the Reverse Proxy and given it an IP of 10.10.10.244. It has the cert with all the correct SANs. In the next section of the iApp it asks for the IP address of the internal side of the Reverse Proxy along with certs and we have it set up with 10.10.20.60 and the correct certs. This is where things get a little confusing for me. The instruction in the iApp ask: What is the port 443 virtual server IP address that forwards traffic to the Front End Servers?
I cant telnet to 10.10.20.60 over port 443, but I think that's expected because it should be using 4443 correct? It is doing a reverse proxy from 443 to 4443. So is the wording wrong in the iApp instruction or am I reading it wrong?
The error from the testing tool is: *An error occurred while sending the request. The underlying connection was closed: An unexpected error occurred on a receive. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. *
That leads me to believe that the Reverse Proxy External IP is accepting the connection, trying to send it on to its next hop, the internal IP and then failing. Possibly a cert issue so I ran tcpdump on the DMZ F5 and I see no attempt of it trying to traffic back out.
Thoughts?
Hi, there is a typo in the template. The iApp should create pool members at port 4443 for those IPs. We'll get that fixed ASAP, sorry.
Is the "_new_edge_external_ip_reverse_proxy_front_end_4443_pool" pool up? Are you seeing tcp requests to those pool members when the Lync Analyzer tries to connect?
thanks Mike
jwashburn_48359OK good that at least means I am not crazy. All the pools are up on both sides except for a few on the internal side that we don't use such as 448, 5068, 5080.- jwashburn_48359Its almost as the traffic is getting black holed on the f5. Running a tcpdump, I see the traffic coming in from a client, but it never forwards it on to the next destination
- Can you post your _secure_reverse_proxy iRule here? I'm curious if traffic is even getting by that.
OK, I just downloaded and ran the connectivity analyzer against my test environment with no problems.
Are you seeing connections being made to the pool members and the 4443 virtual servers on the internal BIG-IP? When you configured the iApp, what did you use for the Simple and Lync Mobile URLs?
- jwashburn_48359No. I am not getting any connection past the DMZ F5. The tool tests lyncdiscover.domain.com. That points to the Reverse Proxy IP of 10.10.10.244. The mobile URL is lyncdiscover.domain.com and the Simple URL is csweb.domain.com
Steven_Baker_15We are having almost the exact same issue as what's described in this post. Did anyone ever get back with a resolution to this for you? We can get traffic to the external VIP of the F5, but then when it tries to get to the internal Lync 2013 front end servers, the traffic appears to stop. Lync connectivity analyzer cites issues with accessing lyncdiscover.domain.com... Please help!
SB
- Steven, which version of the Lync iApp template are you using?
- Steven_Baker_15version 1.2.1. And.... we finally got it working.... in the irule that the iApp template creates, the entry for lyncdiscover.domain.com* was missing. I manually added the entry, and all of a sudden it started working. For instance, here is the irule the iapp created, and the addition I made that got it working properly: when HTTP_REQUEST { switch -glob [string tolower [HTTP::host]] { This is the entry we added lyncdiscover.domain.com* { pool External_Lync_2013_edge_external_ip_reverse_proxy_front_end_4443_pool } lyncdr.domain.com* { pool External_Lync_2013_edge_external_ip_reverse_proxy_front_end_4443_pool } { pool External_Lync_2013_edge_external_ip_reverse_proxy_front_end_4443_pool } meet.domain.com* { pool External_Lync_2013_edge_external_ip_reverse_proxy_front_end_4443_pool } dialin.domain.com* { pool External_Lync_2013_edge_external_ip_reverse_proxy_front_end_4443_pool } mobiledr.domain.com* { pool External_Lync_2013_edge_external_ip_reverse_proxy_front_end_4443_pool } } } Hopefully this helps someone else out.
- alessandro_suri
i have the same issue, in this case you can set a default pool for the VS in order to work around the issue and keep Lync working.
I recreate the irule issue in lab enviroment. Template insert "" but match the "host", try to remove the "" charathers.
The wildcard fix for the iRule was added in version 1.3.0 of the iApp. The mobility URL is added automatically when you answer yes to deploying mobility in the iApp. Is it correct to say that you needed to add another host name to that rule for mobility?
