Forum Discussion
behavior of SSL::disable serverside
- Feb 11, 2023
Better give the config of list ltm virtual xxx and serverside tcpdump to watch whether F5 send clienthello to this pool member
modify this iRules to test:
when HTTP_REQUEST { set usessl 0 switch -glob [string tolower [HTTP::uri]] { "/path1/*" { set usessl 1 pool POOL-path1 persist cookie insert cookie1 } "/path2/*" { set usessl 1 pool POOL-path2 persist cookie insert cookie2 } "/path3/*" { set usessl 0 # SSL::disable serverside pool POOL-path3 } default { set usessl 1 } } } when SERVER_CONNECTED { log local0. "usessl value is $usessl" if { $usessl == 0 } { SSL::disable } }
Hi xuwen,
and thanks for the answer. I can indeed share my VS config (below) but it probably will take a little while to get a tcpdump (no remote access to customer).
ltm virtual /Common/VS-wwwq-443 {
description "VIP https://wwwq.xxxxxxx"
destination /Common/10.x.x.12%2:443
ip-protocol tcp
mask 255.255.255.255
profiles {
/Common/HTTP-wwwq { }
/Common/SSL-C-wwwq {
context clientside
}
/Common/serverssl {
context serverside
}
/Common/tcp-lan-optimized { }
}
serverssl-use-sni disabled
source 0.0.0.0%2/0
source-address-translation {
type automap
}
rules {
IRULE-wwwq-443
}
translate-address enabled
translate-port enabled
vlans {
/Common/VLAN-1319
}
vlans-enabled
}
I can also try some iRule logging, but wouldn't the SSL::disable command, without the serverside option, try to disable SSL also from clientside?
[Edit]
Just took a closer look at https://clouddocs.f5.com/api/irules/SSL__disable.html, and I see your point. Will try to test this ASAP... which might mean next Monday.
/Mike
- xuwenFeb 11, 2023Cumulonimbus
your iRules and vs config look normal,iRules Home SSL::disable says:
Disables SSL processing on one side of the LTM. Sends an SSL alert to the peer requesting termination of SSL processing
is F5 send SSL alert packet on the serverside to the pool member cause this scene?
so,you need to tcpdump in serverside watch whether F5 send ClientHello or SSL alert to the http pool member
- Mike757Feb 12, 2023MVP
xuwen, you're the man!
Improved iRule worked like a charm. And yes, before the changes I saw the attempt of SSL handshake with the server.
/Mike
- xuwenFeb 12, 2023Cumulonimbus
Because SSL:: disable describes that it will send an ssl alert message to the peer, and I'm not sure because I did not experiment with VE.
In short, iRules Home should simply describe the scope of use of the function, and BIGIP VE should do the experiment for the specific details. In the previous few days [TCP:: option get 28], someone directly copied the example Code displayed by CLIENT_ACCEPTED event, cause [string length [TCP::option get 28] value is 0, Let Akamai capture packets. Akamai truely carry the tcp option 28 field, Finally, take VE to test and find that this situation should be CLIENT_DATA event use [TCP::option get 28] and not in CLIENT_ACCEPTED event
iRules Event flow order display SSL::disable should be in CLIENT_ACCEPTED or SERVER_CONNECTED event
Here is the link to the iRule Events flow order
https://clouddocs.f5.com/training/community/irules/html/class1/module1/iRuleEventsFlowHTTPS.html
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com