Nimbostratus
Nimbostratus
The resources you suggested are great but do not work. I have tried Jason's iRule before and I just tried John's iRule and both with the same result. The log shows the TCP payload after the binary scan (see below) but the iRule never moves past the binary scan and the connection never succeeds; no persistence, therefore the two sessions initiated by the client end up on different servers:
Contents after binary scan: L”ƨ2—F÷a~£?6Uí–©®]_Eƒ¾ùJ¡������/��5���� ÀÀ ÀÀ��2��8��������4������������qa.mysite.com�� ����������������ÿ���� Contents after binary scan: L”ÆÜüoæ\Šé,NéûðahAµRl|àÍ“&������/��5���� ÀÀ ÀÀ��2��8��������4������������qa.mysite.com�� ����������������ÿ����
I think John and Jason's rules are more for a native RDP traffic rather than for TS Gateway traffic, which is HTTP encapsulated RDP. The iRule suggested in the F5 deployment guide is simple and should work, but it doesn't and again it is something I have tried. I contacted my local F5 support engineer and we modified the F5 deployment guide iRule to add some logging and see what happens. The iRule we used is:
when HTTP_REQUEST {
log local0. "In HTTP_REQUEST"
if { [HTTP::header exists "Authorization"] } {
log local0. "Auth header contains: [HTTP::header "Authorization"]
persist uie [HTTP::header "Authorization"] }
}
The result in the log is:
In HTTP_REQUEST Auth header contains: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAHIXAAAADw==
In HTTP_REQUEST Auth header contains: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAHIXAAAADw==
In HTTP_REQUEST Auth header contains: NTLM T1RMTVNTUAADAAAAGAAYAI4AAABgAWABpgAAABYAFgBYAAAADgAOAG4AAAASABIAfAAAAAAAAAAGAgAABYKIogYAchcAAAAPQcVyhyOrxM5Ogw7Sww+A/mEAcgByAF8AcQB1AGEAbABpAHQAeQB0AGEAcwBrAG8AdgBtAFcAMAAxADcAQQAyADgANgAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIQYlDTW6rrDzWrCOEq5KMsBAQAAAAAAAFWgzrTLVssBj02c1n/8pMsAAAAAAgAWAEEAUgBSAF8AUQBVAEEATABJAFQAWQABABQAMAAxAFcAVABTAFEAQQAxADIAMQAEADQAcQB1AGEAbABpAHQAeQAuAGMAZQBuAGQAYQBuAHQAbQBvAGIAaQBsAGkAdAB5AC4AcQBhAAMASgAwADEAVwBUAFMAUQBBADEAMgAxAC4AcQB1AGEAbABpAHQAeQAuAGMAZQBuAGQAYQBuAHQAbQBvAGIAaQBsAGkAdAB5AC4AcQBhAAUAJABjAGUAbgBkAGEAbgB0AG0AbwBiAGkAbABpAHQAeQAuAHEAYQAHAAgAVaDOtMtWywEGAAQAAgAAAAgAMAAwAAAAAAAAAAAAAAAAMAAAoEwYmtbo42zqTq1A3sqmz1vJ7c7c4bx3bJHWAf5XesMAAAAAAAAAAAAAAAA= In HTTP_REQUEST Auth header contains: NTLM TlRMTVNTUAADAAAAGAAYAI4AAABgAWABpgAAABYAFgBYAAAADgAOAG4AAAASABIAfAAAAAAAAAAGAgAABYKIogYAchcAAAAP4KAqIPKyP+a3pYFJ50DqDmEAcgByAF8AcQB1AGEAbABpAHQAeQB0AGEAcwBrAG8AdgBtAFcAMAAxADcAQQAyADgANgAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN2GS3qAt2c0BsoYQNPqeTYBAQAAAAAAAFWgzrTLVssBZqkb+Fb6A5QAAAAAAgAWAEEAUgBSAF8AUQBVAEEATABJAFQAWQABABQAMAAxAFcAVABTAFEAQQAxADIAMQAEADQAcQB1AGEAbABpAHQAeQAuAGMAZQBuAGQAYQBuAHQAbQBvAGIAaQBsAGkAdAB5AC4AcQBhAAMASgAwADEAVwBUAFMAUQBBADEAMgAxAC4AcQB1AGEAbABpAHQAeQAuAGMAZQBuAGQAYQBuAHQAbQBvAGIAaQBsAGkAdAB5AC4AcQBhAAUAJABjAGUAbgBkAGEAbgB0AG0AbwBiAGkAbABpAHQAeQAuAHEAYQAHAAgAVaDOtMtWywEGAAQAAgAAAAgAMAAwAAAAAAAAAAAAAAAAMAAAoEwYmtbo42zqTq1A3sqmz1vJ7c7c4bx3bJHWAf5XesMAAAAAAAAAAAAAAAA=
And the BIGIP persistence record created is:
NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAHIXAAAADw==
When the next user comes in, the result is:
In HTTP_REQUEST Auth header contains: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAHIXAAAADw==
In HTTP_REQUEST Auth header contains: NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAHIXAAAADw==
In HTTP_REQUEST Auth header contains: NTLM TlRMTVNTUAADAAAAGAAYAJAAAABgAWABqAAAABYAFgBYAAAAEAAQAG4AAAASABIAfgAAAAAAAAAIAgAABYKIogYAchcAAAAPQDE6mX1RhAWbUbtkXS8RF2EAcgByAF8AcQB1AGEAbABpAHQAeQB0AHMAYwBsAGkAZQBuAHQAVwAwADEANwBBADIAOAA2ADMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbjR17/6/wJofRAPGQyDjxwEBAAAAAAAAuVvI+ctWywHVFUos0PDTCgAAAAACABYAQQBSAFIAXwBRAFUAQQBMAEkAVABZAAEAFAAwADEAVwBUAFMAUQBBADEAMgAxAAQANABxAHUAYQBsAGkAdAB5AC4AYwBlAG4AZABhAG4AdABtAG8AYgBpAGwAaQB0AHkALgBxAGEAAwBKADAAMQBXAFQAUwBRAEEAMQAyADEALgBxAHUAYQBsAGkAdAB5AC4AYwBlAG4AZABhAG4AdABtAG8AYgBpAGwAaQB0AHkALgBxAGEABQAkAGMAZQBuAGQAYQBuAHQAbQBvAGIAaQBsAGkAdAB5AC4AcQBhAAcACAC5W8j5y1bLAQYABAACAAAACAAwADAAAAAAAAAAAAAAAAAwAACgTBia1ujjbOpOrUDeyqbPW8ntztzhvHdskdYB/ld6wwAAAAAAAAAAAAAAAA== In HTTP_REQUEST Auth header contains: NTLM TlRMTVNTUAADAAAAGAAYAJAAAABgAWABqAAAABYAFgBYAAAAEAAQAG4AAAASABIAfgAAAAAAAAAIAgAABYKIogYAchcAAAAPDQffWvWP9QCEpQWgjk+IZ2EAcgByAF8AcQB1AGEAbABpAHQAeQB0AHMAYwBsAGkAZQBuAHQAVwAwADEANwBBADIAOAA2ADMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1ujO7St7VqpQ1A3v95NqUwEBAAAAAAAAF77K+ctWywG+7hjFHTDUSAAAAAACABYAQQBSAFIAXwBRAFUAQQBMAEkAVABZAAEAFAAwADEAVwBUAFMAUQBBADEAMgAxAAQANABxAHUAYQBsAGkAdAB5AC4AYwBlAG4AZABhAG4AdABtAG8AYgBpAGwAaQB0AHkALgBxAGEAAwBKADAAMQBXAFQAUwBRAEEAMQAyADEALgBxAHUAYQBsAGkAdAB5AC4AYwBlAG4AZABhAG4AdABtAG8AYgBpAGwAaQB0AHkALgBxAGEABQAkAGMAZQBuAGQAYQBuAHQAbQBvAGIAaQBsAGkAdAB5AC4AcQBhAAcACAAXvsr5y1bLAQYABAACAAAACAAwADAAAAAAAAAAAAAAAAAwAACgTBia1ujjbOpOrUDeyqbPW8ntztzhvHdskdYB/ld6wwAAAAAAAAAAAAAAAA==
And the original persistence record is overwritten as the only part BIGIP sees and records is:
NTLM TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAGAHIXAAAADw==
This header appears to be the same for every user and connection and is the same for the first two of four connections opened by the client. It is not until the third connection that the header becomes unique but BIGIP never records that part. Again with the help of my local F5 support engineer, we tried to create an MD5 hash of the whole thing using the following iRule.
when HTTP_REQUEST {
log local0. "In HTTP_REQUEST"
if { [HTTP::header exists "Authorization"] } {
log local0. "Auth md5:[md5 [HTTP::header "Authorization"]]"
persist uie [md5 [HTTP::header "Authorization"]] }
}
The result was the same, the persistence record is only one and all users end up on the same server. So persistence with this iRule works but it is "too" persistent ;-). I guess BIGIP never goes past the first of the four records and it really needs to see and persist on the third and forth one. The F5 support engineer suggested that I open a support case with F5 since the TS Gateway persistence iRule is theirs and it is supposed to work. I will do that and hopefully this yields some better results. In the mean time, if anyone knows how to skip the first two HTTP headers and make BIGIP look at the third and fourth ones... please speak up.
Good thing I don't have much hair or I would be pulling it all out just about now ;-)