You receive the error "Late Condition Guards Early Action" when you attempt to install policy that contains the client.effective_address condition. This error means that the policy contains a condition that does not exist before the required action needs to be taken.

Note: This issue can occur using other conditions and actions, but this article focuses on client.effective_address.

Consider the following policy:

<proxy>
   client.address=<IP_address> client.effective_address("$(request.header.X-Forwarded-For)")

The ProxySG appliance dynamically takes the X-Forwarded-For (XFF) header value and set it as the client.effective_address.  You could then use the client.effective_address to control the traffic. This is useful in environments such as load balancing to multiple appliances where the load balancer sets the original client IP address as the XFF header, and all packets to the appliance show the load balancer for the client IP address. 

Because the policy to move the XFF header into the client.effective_address requires evaluation, client.effect_address cannot be used as a condition for any action that occurs before ECP_CLIENT_EFFECTIVE_ADDRESS_READY. 

The following is the complete list of actions before ECP_CLIENT_EFFECTIVE_ADDRESS_READY:

==TRANSACTION
client.certificate.require
client.certificate.validate
client.certificate.validate.check_revocation
server.certificate.validate.check_revocation
client.effective_address
ftp.welcome_banner
http.client.recv.timeout
socks.authenticate.force
ftp.server_connection
shell.prompt
shell.realm_banner
shell.welcome_banner
socks.authenticate

==REQUEST_HOST
trust_destination_ip

==REQUEST_URL
dynamic_rating_headers
dynamic_rating_mode
dynamic_rating_url
authenticate.redirect_stored_requests

==REQUEST_HEADERS
http_apparent_data_type

==REQUEST_ALL
authenticate
authenticate_authorization_refresh
authenticate_charset
authenticate_credential_refresh
Authenticate_credentials_address
authenticate_credentials_username
authenticate_credentials_password
authenticate_credentials_sso_cookie
authenticate_form
authenticate.force
authenticate_new_pin
authenticate_surrogate_refresh
authenticate_tolerate_error
authenticate_mode
authenticate.transaction
authenticate.use_url_cookie
authenticate.force_307_redirect
authorize_tolerate_error
http_request_detection_injection_sql
http_request_detection_other
http_request_max_body_size
protocol_force
server_authenticate_constrained_delegation
server_authenticate_constrained_delegation_spn
socks_client_compression
streaming.fast_cache
streaming.rtmp.tunnel_encrypted
authenticate.transaction
cache.ability.cw.suppress
ftp.match_client_data_ip
ftp.match_server_data_ip

==AUTHENTICATION_RESULT
authenticate_guest
authorize_add_group

==CLIENT_IDENTITY
dynamic_bypass
external_service
icap_reqmod_sequence
icap_secure_connection_request
property_detect
server_authenticate
service_deny_unauthorized
socks_handoff
bypass_cache
never_serve_after_expiry
never_refresh_before_expiry
remove_IMS_from_GET
remove_PNC_from_GET
remove_reload_from_IE_GET
check_authorization
im.strip_attachments
dns.impute
im.block_encryption
im.reflect

To resolve this issue, use a different condition to perform the required action. 

Instead of using client.effective_address to perform the actions in this example, such as detect.protocol(no), authenticate, and so on, use the XFF header value. Write the following policy:

<proxy>

  client.address=<IP_address> client.effective_address("$(request.header.X-Forwarded-For)")

<proxy>

  request.header.X-Forwarded-For.address="x.x.x.x"  detect_protocol(no)