Troubleshooting

Viewing Logs

To troubleshoot the iRule added to the F5 BIG-IP, SSH into the BIG-IP machine, enter the bash shell, and check the LTM logs:

$
tail -f /var/log/ltm

Enable Debug Logging

For detailed troubleshooting, you can enable debug mode which provides additional logging information about the enforcer’s decision-making process.

Enable Debug Mode

$
modify /ltm data-group internal pxconfig records modify { debug { data 1 } }

Disable Debug Mode

$
modify /ltm data-group internal pxconfig records modify { debug { data 0 } }

Test Block Flow on Monitoring Mode

When the enforcer is in Monitor Mode (module_mode = 1), you can still test the blocking flow without affecting real traffic. This is useful for validating that blocking works correctly before switching to full blocking mode.

Configuration

Set the bypass monitor header in the pxconfig data group:

$
modify /ltm data-group internal pxconfig records modify { bypass_monitor_header { data x-px-block } }

Usage

Once configured, you can test blocking by including the header in your request:

1. Set the header x-px-block: 1 on your request
2. Trigger a detection (e.g., use a User-Agent header with the value PhantomJS/1.0)
3. The enforcer will bypass Monitor Mode and apply full Block Mode for this request

Conditions for bypass:

• The bypass_monitor_header must be configured
• The header must be present in the request with a value of 1
• The request must trigger a block response (high risk score)

If any condition is missing, the enforcer will stay in Monitor Mode.

To explicitly stay in Monitor Mode even when the header is present, set the header value to 0:

• x-px-block: 0 - Stay in Monitor Mode

Common Issues

No Activity Data in HUMAN Console

If you’re not seeing activity data in the HUMAN Console:

1. Verify that the Syslog configuration is complete (see Installation)
2. Check that your F5 IP address has been authorized with HUMAN backends
3. Verify the px_syslog_pool is healthy and can reach px-fst-syslog.perimeterx.net
4. Ensure the CLIENT_ACCEPTED rule is uncommented in the px iRule

Risk API Timeouts

If you’re seeing high s2s_timeout rates:

1. Check that px_backend_pool is healthy
2. Verify the virtual server px_backend_<APP_ID>_vip is configured correctly
3. Consider increasing risk_timeout if network latency is high:

$
modify /ltm data-group internal pxconfig records modify { risk_timeout { data 3000 } }

Module Not Processing Requests

If the enforcer doesn’t seem to be processing requests:

1. Verify enable_module is set to 1
2. Check if enable_module_header_name is configured and if so, ensure the header is present
3. Verify the px iRule is attached to your virtual server
4. Check the excluded_extensions pattern isn’t matching your requests

iRule Size Exceeded Error

If you see this error when uploading the px iRule:

01070712:3: Max string size exceeded during update of attribute:definition type:rule max:65520 received:67873

The px.tcl file exceeds F5’s 65,520 byte limit for iRules.

Solution: Minify the iRule before uploading:

$
sed '/^[[:space:]]*#/d' px.tcl | cat -s > px-minified.tcl

This command removes comment lines and collapses blank lines. The minified iRule is functionally identical to the original.

Use px-minified.tcl instead of px.tcl when creating the iRule.