custom logging

[willj_]

Is it me or is the Juniper documentation for custom logging woefully inadequate?

I get a basic request: We need to know who logged in, how long they were logged in for and what they did whilst they were logged in.

Can anyone tell me whether the SSLVPN is able to provide me with this (pretty basic) information, or whether I have to look at 3rd party software to achieve this?

cheers

[seaweed_]

i have the same question as well but besides that is there a way to get loggingwith more information than just the basics?

[Jan_]

i use kiwi syslog deamon for syslogging

and sawmill for reporting.

jan

[dogmai_]

No information available in the logging will help you if you have issues with predefined Host Checks. The predefined stuff is all a big black box so when you have users that should pass but aren't, you only see in the logs that they didn't pass, not what specifically about the check is failing. As a result, each time I have users that run into issues, I have to open a case with Juniper and collect tons of logs and then a month or two later, ESAP usually catches up to the issue and addresses whatever was causing the issue. Problem with this is I never find out what caused the problem in the first place (knowing, for instance, that a particular check was looking for specific registry syntax would allow me to verify whether my problem user(s) have an extra comma or semicolon character at the end of their string and would allow me to solve the problem much faster than the system in place today). To add insult to injury, I've attended a couple of SSL VPN webinars for competing vendors recently and I've seen that some products do at least have a verbose logging 'mode' that will allow you to troubleshoot such things more efficiently... so it's possible to give us this functionality, just prolly not very high on the to-do list.

The Juniper log files, otherwise, have actually seemed pretty good although the reporting against those logs could use work. My account management team tells me that there will be no additional log reporting functionality built into the IVE as it's been made available in another product, STRM, and I've also evaluated a pretty cool solution called SSL Clearview reporter from NWG Technologies (http://www.nwgtechnologies.com/products/product2.html) that is built just for Juniper SSL VPN reporting and comes with some really good drill-down canned reporting.

Hope this helps.

[ssl_boy_]

Hi Dogmai,

The Juniper Client logging is pretty good, if you know where to look.. If you enable client side logging in the IVE admin console, when users login they will automatically generate an "EPcheck.log" file which is buried in a hidden directory under \documents and settings\username\EPcheck\epcheck.log. This explains in verbose detail why the check failed. Admittidly this won't be mean much to the average end-user, but you should at least be able to figure it out..

With the "canned" esap tests when there is a problem is does take a while to sort I'll admit..In the meantime as a workaround I tend to create an "oldschool" test and manulally check for the bit myself that aren't working. Juniper have been tinkering with this functionailty a lot in the late 6.x releases, whilst still not perfect it still is much more comprehensive than any other vendor that I've seen..

[dogmai_]

'With the "canned" esap tests when there is a problem is does take a while to sort I'll admit..In the meantime as a workaround I tend to create an "oldschool" test and manulally check for the bit myself that aren't working.'

Kendal,

Hopefully what you're talking about is available in the 6.x releases because the information I've found in the EPCHECK.log and dsHostChecker.log files has been pretty much useless for me (You see large sections of gobbledygook that I would imagine contains the information I am after but I am not intended to see it). I have had some luck running the OESISDIAGNOSE utility and the OPSWAT AV integration SDK test harness and seeing a bit of what is checked for specifically but in both of those cases, I can't know if I am finding everything the pre defined stuff checks for or just pieces.

I guess what I'm saying is I have no way, currently, of comparing a problem user's settings to a known list of the stuff a pre-defined check looks for; I can't create 'oldschool' checks to look for nonworking bits that I have no way of knowing about. This causes me to waste time depending on Juniper support for something I should be able to determine on my own, causes the users to suffer unacceptable periods of denied access, causes me to question the quality of any workaround I do decide to implement temporarily and also causes much longer delays in ultimately getting a problem fixed.

FWIW, I agree that this product is miles ahead, almost categorically, of any of the other products I've seen out there. I have just seen some that 'seem' from demonstrations and webinars to have friendlier logging. Anywho, I didn't intend to leave the impression that I was dissatisfied with the product overall, only that I don't like how limited I am in diagnosing and resolving problems with this feature.

Message Edited by dogmai on 12-03-2008 12:58 PM