Hello Seniors, Hope all is well at your side.

I have my Guardium Infra running on v11.5 GPU Bundle 570 with 4083 sniffer patch. I was working on Implimenting Guardium Session Level Firewall [SGATE] functionality. However, what abnormal behavior I have noticed Is that, 

GUARDIUM FIREWALL [S-GATE - Session Level] IS BLOCKING THE CONNECTION EVEN IF I DID NOT ENABLE [WINSTAP_FIREWALL_INSTALLED] AND WINSTAP_FIREWALL_DEFAULT_STATE=2 PARAMETERS. Meaning, I Just applied the condition & tried to attach the session with SGATE Attach action then on next Rule added SGATE Terminate Rule BUT did not enable any firewall related parameters at STAP level.

Further, As per IBM Support, this is working as expected & asked me to Open an IBM IDEA If my requirement needs the firewall to be involved for SLP to work,

Later, they admitted that, It is a IBM documentation glitch/Inconsistency. But, I don't think It's Documentation Issue, It Is a clearly a glitch/bug in the system.

AS PER IBM DOCUMENTATION: -

• The S-GATE SESSION policy rule actions require setting firewall_default_state=2 in the S-TAP configuration. For more information about the firewall_default_state setting, see S-TAP configuration firewall parameters.

Firewall and latency issues examples - IBM Documentation

With STAP firewall enabled (firewall_installed=1)

• If firewall_default_state=0(open mode), by default, NO sessions are watched/attached. Then the corresponding Policy side needs to define Access Rule with 'SGATE ATTACH' in order to watch/attach rogue sessions, so that later on SGATE TERMINATE can be used for that session. NOTE: It is only when a session is in watch/attach state, SGATE TERMINATE would take effect for that session.

• If firewall_default_state=1(closed mode), by default, ALL sessions are watched/attached. Then the corresponding Policy side needs to define Access Rule with 'SGATE DETACH' to unwatch/detach any sessions that don't need to be watched/blocked. Otherwise it may cause unwanted latency to sessions that don't need to be watched/blocked. With firewall_default_state=1, latency is expected because all sessions are considered rogue and watched by default.

• If firewall_default_state=2, by default, the initial priority_count(defined in guard_tap.ini) packets are watched/attached. After the initial priority_count packets for that session, S-TAP simply unwatches automatically if no WATCH(SGATE ATTACH) or DROP(SGATE TERMINATE) is received for that session. Then the corresponding Policy side still needs to define Access Rules with 'SGATE ATTACH' to continue to watch/attach to any rogue sessions.

All the associated documents related to session level firewall policy is not correctly created based on product behaviors. since, firewall policy started working irrespective, if we enable the firewall or not & weather, we set firewall_default_state=2 parameter OR not. It will work...!