Forum Discussion
NimbostratusMS Lync 2013 Reverse Proxy rules
Hi All
Firstly apologies that this post is so long! We have recently rolled out Lync 2013 and are using the BigIP LTM to load balance the web traffic from the reverse proxy server (TMG) to the front end pool.
Unfortuantely he BigIP configuration is controlled by our hosting partner and we have no access to the GIU interface, so I need to check whether the configuration they have created is as we intended!
Basically we are having an issue where the "test rule" option within TMG will fail for the publishing rule that deals with the Lync public URLS (dialin, meet etc). If we point the TMG server directly to a single front end using the hosts file, the rule tests OK, but always fails when pointing through the BigIP.
We gave our hosting partner the following information when setting up the rules, based on what out Lync contractor gave us:
There are two virtual servers required, one with a DMZ address and one with an internal address. The DMZ VIP will load balance Lync 2013 web traffic from the Lync 2013 Edge server. The internal VIP will load balance Lync 2013 web traffic from all internal workstations.
The three servers needed to be included in the pool for each of the above are:
HOSTNAME1 (172..X.X.X)
HOSTNAME2 (172..X.X.X)
HOSTNAME3 (172..X.X.X)
The internal facing VIP should allow connections on port 443, and the DMZ facing VIP should allow connection on port 4443.
The VIP for the DMZ traffic will need to be a new IP in the 172.X.X.X/24 subnet and the VIP for internal traffic will need to be a new IP in the 172.Y.Y.Y/24 subnet.
The internal facing VIP should use Source_addr persistence. For Lync Server 2013, Source_addr persistence means that multiple connections coming from a single IP address are always sent to one server to maintain session state. Use TCP idle timeout of 1800 seconds.
The DMZ facing VIP should use cookie based affinity, with the following specific requirements from Microsoft:
Hardware load balancer cookie MUST NOT be marked httpOnly
Hardware load balancer cookie MUST NOT have an expiration time
Hardware load balancer cookie MUST be named MS-WSMAN
Hardware load balancer cookie MUST be set in every HTTP response for which the incoming HTTP request did not have a cookie, regardless of whether a previous HTTP response on that same TCP connection had already obtained a cookie. If the load balancer optimizes cookie insert to only occur once per TCP connection, that optimization MUST NOT be used
From that, they have generated the following config file:
profile clientssl lync.xxxxxx-srv_profile {
defaults from clientssl
key "xxxxxxx_wildcard.key"
cert "xxxxxx.com.crt"
chain "IntermediateCA_xxxxxxx.crt"
ciphers "DEFAULT:!ADH:!EXPORT40:!EXP:!LOW"
}
profile persist cookie_persist_day {
defaults from cookie
mode cookie
cookie mode insert
cookie expiration 1d 00:00:00
}
profile persist source_addr_1800 {
defaults from source_addr
mode source addr
timeout 1800
}
profile serverssl lync.xxxxx-ssl_profile {
defaults from serverssl
key "LyncCertificate.key"
cert "LyncCertificate.crt"
}
pool lync_frontend_server_dmz {
lb method member least conn
monitor all tcp
members {
172.X.X.X:4443 {}
172.X.X.X:4443 {}
172.X.X.X:4443 {}
}
}
pool lync_frontend_server_int {
lb method member least conn
monitor all tcp
members {
172.X.X.X:443 {}
172.X.X.X:443 {}
172.X.X.X:443 {}
}
}
rule xxxxxxx_lync_forwarder_irule {
when HTTP_REQUEST {
if { [HTTP::cookie exists "MS-WSMAN"] } {
set need_cookie 0
} else {
set need_cookie 1
}
}
when HTTP_RESPONSE {
if { ($need_cookie == 1) && (! [HTTP::cookie exists "MS-WSMAN"]) } {
scan [IP::server_addr] "%u.%u.%u.%u" a b c d
set e [TCP::server_port]
set cookie "[format %u [expr {($d<<24)|($c<<16)|($b<<8)|$a}]].[expr{($e & 0xff)<<8 | ($e >>8)}].0000"
HTTP::cookie insert name "MS-WSMAN" value $cookie path "/"
unset cookie
}
unset need_cookie
}
}
virtual lync_dmz_https_vip {
snatpool xxxxxxx_http_1_snatpool
pool lync_frontend_server_dmz
destination 172.x.x.x:4443
ip protocol 6
rules xxxxxxx_lync_forwarder_irule
persist cookie_persist_day
profiles {
lync.xxxxxx-srv_profile {
clientside
}
lync.xxxxxxx-ssl_profile {
serverside
}
master_http_profile {}
tcp {}
}
}
virtual lync_int_https_vip {
snatpool xxxxxx_http_2_snatpool
pool lync_frontend_server_int
destination 172.x.x.x:443
ip protocol 6
persist source_addr_1800
}
Can someone who understands the iRule bit let me know whether what they have provided meets the requirements that we set out? We have no way of checking as no experience with the BigIP in house.
Many thanks
Daniel
11 Replies
- Hi Dan, that configuration guidance is rife with errors. First of all, clients connect to port 443 on the public-facing LTM, and that traffic must be forwarded to the internal LTM on port 4443. There needs to be an iRule assigned to the external virtual server that inspects the request URI and forwards requests for meet, dialin, and mobile URIs to the internal 4443 VIP, which will either point to the Front End or Director servers on port 4443.
The cookie generating iRule they have listed here applies only to BIG-IP v10, not v11. Which version are we talking about here? Also, this iRule needs to be applied to the internal virtual server, not the external one.
I recommend taking a look at our deployment guide for Lync for more specific information: http://www.f5.com/pdf/deployment-guides/microsoft-lync-iapp-dg.pdf
thanks
Mike 
Dan_Wiltshire_2Sorry, perhaps I was unclear.
There is only one BigIP LTM pair. The web traffic first hits a TMG reverse proxy server in the DMZ, which is set to forward on from 443 to 4443.
The BigIP is connected to the DMZ and to the internal network, so it listens on 4443 on the DMZ virtual and 443 on the internal virtual.
Does that make a bit more sense?
Thanks
Dan
- OK, sorry I read that too fast. Since TMG is going away and LTM can serve perfectly fine as the reverse proxy, you may want to consider removing TMG for Lync. The deployment guide includes steps for configuring this in a single BIG-IP pair deployment.
Persistence isn't actually required for Lync 2013. So that cookie iRule and the source IP persistence can be removed: http://technet.microsoft.com/en-us/library/jj656815.aspx
I'm curious to know what the TMG logs say when you try to connect to the front end VIP instead of directly to the server. That would be the next troubleshooting step to take. I assume that the internal VIP address has been correctly associated with a firewall rule in TMG that will pass the traffic? - Dan_Wiltshire_2
We get the following in the TMG log when connecting to the BigIP VIP:
Failed Connection Attempt
Log type: Web Proxy (Reverse)
Status: 0x80090322
Rule: Lync Proxy URLs
Source: Internal (X.X.X.X:31286)
Destination: Local Host (X.X.X.X:4443)
Request: POST http://extwebsvc01.XXXXX.com/groupe...ket_Bearer
Filter information: Req ID: 1532ad2e; Compression: client=No, server=No, compress rate=0% decompress rate=0% ; FBA cookie: exists=no, valid=no, updated=no, logged off=no, client type=unknown, user activity=yes
Protocol: https
User: anonymous
When connected directly to a single front end, it is the same message but status is 200 OK instead of the error code above.
That error code seems to indicate something to do with certificates. On the bigIP we have our public wildcard certificate set up as the serverside certificate and a copy of the front end certificate (which includes the SANS for meet, dialin etc) as the clientside certificate.
Dan
- You should remove the cert from the server SSL profile on LTM, it isn't necessary. Not sure if it would cause this problem, but I'd give it a try.
- Dan_Wiltshire_2Great thanks, I will look at getting the cert and cookie stuff removed. Will post a modified suggested config on here tomorrow to see if it makes sense!
- Dan_Wiltshire_2So, if I have understood you correctly, would the following config meet the requirements?
profile clientssl lync.xxxxxx-srv_profile {
defaults from clientssl
key "xxxxxxx_wildcard.key"
cert "xxxxxx.com.crt"
chain "IntermediateCA_xxxxxxx.crt"
ciphers "DEFAULT:!ADH:!EXPORT40:!EXP:!LOW"
}
profile serverssl lync.xxxxx-ssl_profile {
defaults from serverssl
}
pool lync_frontend_server_dmz {
lb method member least conn
monitor all tcp
members {
172.X.X.X:4443 {}
172.X.X.X:4443 {}
172.X.X.X:4443 {}
}
}
pool lync_frontend_server_int {
lb method member least conn
monitor all tcp
members {
172.X.X.X:443 {}
172.X.X.X:443 {}
172.X.X.X:443 {}
}
}
virtual lync_dmz_https_vip {
snatpool xxxxxxx_http_1_snatpool
pool lync_frontend_server_dmz
destination 172.x.x.x:4443
ip protocol 6
profiles {
lync.xxxxxx-srv_profile {
clientside
}
lync.xxxxxxx-ssl_profile {
serverside
}
tcp{}
}
}
virtual lync_int_https_vip {
snatpool xxxxxx_http_2_snatpool
pool lync_frontend_server_int
destination 172.x.x.x:443
ip protocol 6
} - Yes, assuming you still have the persistence and HTTP profiles and iRule from the previous configuration.
- Dan_Wiltshire_2Good news!
Although I thought it was mentioned previously in this thread that the cookie persistence (and therefore the iRule and cookie persistence profile) are not needed?
Dan - That was when I misunderstood your topology. You do need to to return a cookie named MS-WSMAN to the client in every response.
