Lync SSL Config

Mike,

 

 

Thanks for the info. I'm having a fit trying to get the reverse proxy working correctly.. hopefully you may be able to quickly see where my configuration mistake is.

 

 

I have one external reverse proxy VIP:

 

 

Clientssl and serverssl profiles configured correctly.

 

SNAT automap

 

No persistence

 

iRule configured to redirect users to the internal reverse proxy (on 4443)

 

One pool member, the internal reverse proxy VIP (on 4443). The deployment guide says to make the pool member the "IP address of the front end virtual server that you created," but this doesn't really make sense to me?

 

 

I then have one internal reverse proxy VIP:

 

 

Clientssl and serverssl profiles configured

 

SNAT automap

 

Cookie based persistence

 

Two pool members, each of the front-end servers on TCP/4443.

 

 

I can hit the "internal reverse proxy VIP" just fine, and get redirected to Lync web services. However, when I hit the external reverse proxy VIP, the request eventually times out. As a note, both the internal reverse proxy VIP and the external one are on the same network. and on the same BIG-IP. In doing a tcpdump between the internal and external reverse proxy VIPs, I see some strange ARPs:

 

 

15:45:40.543203 arp who-has 172.26.137.54 tell 172.26.137.5

 

15:45:41.543424 arp who-has 172.26.137.54 tell 172.26.137.5

 

15:45:42.543022 arp who-has 172.26.137.54 tell 172.26.137.5

 

15:45:43.543467 arp who-has 172.26.137.54 tell 172.26.137.5

 

15:45:44.543290 arp who-has 172.26.137.54 tell 172.26.137.5

 

 

172.26.137.54 is the internal reverse proxy VIP, and 172.26.137.5 is the floating self-IP address on that particular VLAN. I also see this:

 

 

15:45:46.543046 IP 172.26.137.55 > 172.28.140.64: ICMP host 172.26.137.55 unreachable, length 36

 

15:45:46.543056 IP 172.26.137.55 > 172.28.140.64: ICMP host 172.26.137.55 unreachable, length 36

 

15:45:46.543061 IP 172.26.137.55 > 172.28.140.64: ICMP host 172.26.137.55 unreachable, length 36

 

 

172.26.137.55 is the external reverse proxy VIP, and 172.28.140.64 is the client IP address that is trying to hit the VIP.

 

 

I'm stumped here. Do you have any idea what may be going on?

 

 

I really appreciate any help you can offer.

 

 

Thanks

 

It does seem like a routing issue. The iApp wasn't designed with this kind of setup in mind, although it's a scenario we can investigate and possibly add into the iApp. I see no reason why you would need both external and internal reverse proxy VIPs when deploying on one BIG-IP (or HA pair); you could copy the iRule that secures access to the external reverse proxy VIP, then reconfigure the iApp and NOT deploy the external reverse proxy VIP. Change the destination port on the VIP from 4443 to 443, and add that iRule to the internal reverse proxy VIP to secure access and you should be OK.

Ah, ok.. sounds like a much simpler solution. I'm getting stuck in a redirect loop here, though.

 

 

The internal VIP has two pool members, each of the front-ends (on 4443). The iRule is applied to this VIP redirects the simple URLs (meet.domain.com, etc) to this pool as well. Does that sound right?

You do need to edit the iRule to send requests for those URLs to the internal, rather than the external, reverse proxy pool. You would also need to remove the default pool assignment on the internal reverse proxy virtual server, since you want all traffic not allowed explicitly by the iRule to be dropped.

My apologies.. I had the wrong iRule assigned. Everything seems to be working fine now. I'll remove the default pool. I really appreciate all of your help.

 

 

Josh