NimbostratusIs anyone able to tell me if you can store data in the session table using an iRule on one VS then recover it on a second VS, if the second VS is called via the virtual command in an iRule on the first VS. I can recover data from the session table added by a separate VS but not the data added by the first VS, the one that calls the second VS.
NimbostratusThis is th
Log
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/CLIENT_PROFILE <CLIENT_ACCEPTED>: client accepted VS1 on irule CLIENT_PROFILE
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/CLIENT_PROFILE <CLIENT_ACCEPTED>: This is irule CLIENT PROFILE. FTPS_CLIENT1 10.0.1.85
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <CLIENT_ACCEPTED>: client accepted VS1
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <CLIENT_ACCEPTED>: New TCP connection from 10.0.1.85:56112 to 10.0.1.50:21
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <CLIENT_DATA>: client data VS1
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <CLIENT_DATA>: AUTH TLS is the payload VS1
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <CLIENT_DATA>: New TCP connection from 10.0.1.85:56112 to 10.0.1.50:21
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <CLIENT_DATA>: is the payload (should be empty) VS1
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: CLIENT_DATA found client data
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: CLIENT_DATA send to virtual vs-test-02
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <CLIENT_DATA>: TCP Release Completed VS1
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP_1 <CLIENTSSL_CLIENTHELLO>: This is clientssl_clienthello - VS1
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP_1 <CLIENTSSL_CLIENTCERT>: This is clientssl_clientcert - VS1
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP_1 <CLIENTSSL_CLIENTCERT>: CLIENTSSL session ID is d531cee3d86573361dd958caa18c7b9f807e1e788d4a42cc6a6bc0c731dc8b6e
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP_1 <CLIENTSSL_CLIENTCERT>: Count of certificates is 1
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP_1 <CLIENTSSL_CLIENTCERT>: this is VAR value 1122334455
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: send to virtual vs-test-02
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: result is 1122334455
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP_1 <CLIENTSSL_HANDSHAKE>: This is clientssl_handshake - VS1
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <SERVER_CONNECTED>: This is server connected event VS1
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <SERVER_CONNECTED>: New TCP connection from 10.0.1.85:56112 to 10.0.1.85:56112
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: table is bluelist and returns STRING
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <CLIENT_ACCEPTED>: client accepted VS2
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <CLIENT_ACCEPTED>: New TCP connection from 10.0.1.85:56112 to 10.0.3.50:21
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <CLIENT_ACCEPTED>:
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <CLIENT_DATA>: USER user VS2 client data event
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP2 <CLIENT_DATA>: This is client data
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <CLIENT_DATA>: USER user
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <CLIENT_DATA>: This is line 29
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <SERVER_CONNECTED>: VS2 server connected event - on inner F5 this is connection to FTP server
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP2 <SERVER_CONNECTED>: New TCP connection from 10.0.1.85:56112 to 10.0.3.201:56112
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP2 <SERVERSSL_CLIENTHELLO_SEND>: This is SERVERSSL_CLIENTHELLO_SEND - VS2
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP2 <SERVERSSL_SERVERHELLO>: This is SERVERSSL_SERVERHELLO - VS2
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP2 <SERVERSSL_SERVERCERT>: This is SERVERSSL_SERVERCERT - VS2
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: SERVERSSL_SERVERCERT result for 10.0.1.85 is .
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: table is bluelist and returns
Oct 16 16:22:31 ip-10-0-0-200 info tmm1[9810]: Rule /Common/VIP2 <SERVERSSL_HANDSHAKE>: This is SERVERSSL_HANDSHAKE - VS2
Oct 16 16:22:31 ip-10-0-0-200 debug tmm1[9810]: Rule /Common/VIP_1 <SERVER_DATA>: this is server data event VS1e log .....
NimbostratusHi, thanks for the reply. The build follows the FTPS F5 build from:
https://devcentral.f5.com/s/articles/ftps-offload-via-irules
As well as FTPS, i want to take a value from the first VS (a dynamic value which changes with each connection) and make it available to the second VS. It works with a global variable. But since the value is dynamic, saving it in the session table is recommended by F5, rather than using the global variable (which would not scale with concurrent connections). However, maybe because of the ssl::disable/ssl::enable, the table seems not to save the value in the same table where it performs the lookup. That, or the table is reset by the time it does the lookup in the second VS. I thought, at one point, that the way the F5 handles the CMP (the VS is demoted from CMP when global variables are used), might have something to do with it - the global variable being available to the second VS might have meant that the memory was available to both. But, at this stage, i have no clue, it is becoming frustrating. I know that using the persistence profiles screws up the table config because values are retained and the "wrong" value is returned from a lookup in the same VS sometimes, so i'm not using persistence. Anyway, thanks for looking into it. I'm just grateful someone else is interested. I don't want to do IP blacklisting. Anyway, i'd be interested to know what you think. Because of where the table lookup occurs in the log, i don't think it is a race condition. Would you agree?
MVPi agree that logically you wouldn't expect a race condition.
while i would like to built something similar i don't know if that is gonna happen soon.
my strong advise remains to get F5 support involved, they can built something similar and check, they also should know if something like ssl::disable/enable or persistence might have an effect.
NimbostratusThanks a lot for having a look. I really appreciate it. I shall pursue through F5 and see if they respond. I shall let you know if i get anywhere with them
NimbostratusHi Boneyard,
I didn't get anywhere with F5. But it's working now. There were server events in the iRule on the first VIP. Even when they were hashed out it didn't work. When the iRule was re-created from scratch without the hashed out server commands in the first iRule, it worked. There have been some problems compiling the iRules and this complicated the problem even further.
Thanks for your help though.
Since you like a challenge ;-) i have another problem with selecting an SSL server profile in SERVER_CONNECTED via a data group and a class lookup, which logs but does not actually set the profile. I'm just about to raise a question about it on this forum.
Anyway, thanks for your help with this one
MVPthanks for sharing the solution, it might help others. replied on your other question.