MS 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