- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: HTTPS Inspection logs location
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
HTTPS Inspection logs location
Hello colleagues,
There is a problem on R77.30 with HTTPS inspection, the gw is blocking everything.
The reason is: internal system occured, blocking request. See SK64162 for more information.
Unfortunately, nothing helped in this SK, so I collected a CPinfo to analyze it.
Where can I find any internal files, log files that are related to the issue?
I don't mean debugs, that's understandable. I'd like to figure out why the CP started to block it once.
Thank you for your time!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This error is usually connected to a blade, e.g. SmartLog search using
blade:"URL Filtering" AND "internal error"
or
blade:"Application Control" AND "internal error"
Also, Content Awareness or userspace RAD could be involved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But what about internal error records on the gateway, is there any file, which might be helpful to determine the problem?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For HTTPS Inspection there are gateway components in both process space and kernel space. The initial HTTPS negotiation between the firewall and Internet web server(s) starts in process space (wstlsd/pkxld) and that is usually where issues are encountered. Check out this log file: $FWDIR/log/wstlsd.elg; probably also worth looking in $FWDIR/log/fwd.elg and /var/log/messages* to see if anything interesting is getting written into these files. If you see any messages in wstlsd.elg that indicate a problem and need more debugging info go here: sk105559: How to debug the WSTLSD daemon.
On 64-bit Gaia there is also a companion process to wstlsd called pkxld that leverages the 64-bit mode of the processor along with other hardware-based acceleration capabilities for key calculations and such. I don't think there is a log file for this daemon, but if you think the problem is located here this daemon can be disabled to force all key calculations to occur back in wstlsd (just like they would be in 32-bit Gaia) by doing a touch $FWDIR/conf/pkxl_disable and rebooting.
For HTTPS kernel debugs the main module and option/flag for use with fw ctl debug is fw and cptls respectively. For instructions about how to run a kernel debug in R77.30 see here: Kernel Debug flags - R77.30
now available at maxpowerfirewalls.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
An internal error due to categorization service timeout would need a RAD debug:
# rad_admin rad debug on all
******************Replicate***************
# rad_admin rad debug off
Collect: $FWDIR/log/rad.elg*