Forum Discussion

jwashburn_48359's avatar
jwashburn_48359
Icon for Nimbostratus rankNimbostratus
Nov 13, 2013

Lync 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?

 

deployment
devops
iApps
lync 2013
reverse proxy

26 Replies

Sort By
  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account
    Nov 13, 2013

    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_48359's avatar
      jwashburn_48359
      Icon for Nimbostratus rankNimbostratus
      Nov 13, 2013
      OK 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_48359's avatar
      jwashburn_48359
      Icon for Nimbostratus rankNimbostratus
      Nov 13, 2013
      Its 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
    • mikeshimkus_111's avatar
      mikeshimkus_111
      Historic F5 Account
      Nov 13, 2013
      Can you post your _secure_reverse_proxy iRule here? I'm curious if traffic is even getting by that.
  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account
    Nov 13, 2013

    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_48359's avatar
      jwashburn_48359
      Icon for Nimbostratus rankNimbostratus
      Nov 13, 2013
      No. 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_15's avatar
    Steven_Baker_15
    Icon for Nimbostratus rankNimbostratus
    Oct 02, 2014

    We 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

     

    • mikeshimkus_111's avatar
      mikeshimkus_111
      Historic F5 Account
      Oct 02, 2014
      Steven, which version of the Lync iApp template are you using?
    • Steven_Baker_15's avatar
      Steven_Baker_15
      Icon for Nimbostratus rankNimbostratus
      Oct 02, 2014
      version 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's avatar
    alessandro_suri
    Icon for Nimbostratus rankNimbostratus
    Nov 21, 2014

    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.

     

  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account
    Nov 21, 2014

    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?