Status>System logs>Firewall

heper

Easyrule: add to block list

Easyrule: pass this traffic

fa-minus-square-o
fa-plus-square-o

perhaps?

personally "-" & "+" reminds me of, adding & removing. while in this case, both add a rule (one to block, the other to pass).
so maybe we can make both of them a "+", but use the css color scheme? (green=pass , red=block)

or

use different icons altogether perhaps: fa-lock / fa-unlock ?

divsys

Given that icon set, might I suggest using the "hand" series such as:

block: hand-paper-o or hand-rock-o
reject: thumbs-o-down
pass: thumbs-o-up

The addition of colour (red for block and reject, green for pass) would go a long way to adding clarity IMO.

That might give us a consistent and hopefully intuitive way of representing the dual -ve conditions for processing packets.

Steve_B

We need to accommodate those who do not see colors clearly. Lock/unlock might work.

Donny

Hello, I like firewall log entries layout from the picture here under more than now. For the firewall log layout now at the "Act" column should be on the left side and not right side, It is look conflicting.
Icons X in the Act column look not attractive. My suggestion is: It is possible to use another icon or icon like firewall. When I point to an icon information and icon + the arrow pointer is disappear.

Donny

6h3h8n.png_thumb

divsys

We need to accommodate those who do not see colors clearly.

How about simply use Black on White for +ve and White on Black for -ve (or vice versa as consensus desires)?
I'm suggesting color or contrast (in this case) clues to be used in addition to icon clues.

BBcan177

Instead of defining 'icon-danger' and 'icon-success', why not just 'green' and 'red' so those css settings can be used in other places.

biggsy

OOPS - a can of worms :)

@Steve_B:

Replacing those glyphicons which fount-awesome icons . . .

How about:

Reject - arrow-left (orange)
Block/Drop - arrow-down (red)
Pass - arrow-right (green)

heper

@BBcan177:

Instead of defining 'icon-danger' and 'icon-success', why not just 'green' and 'red' so those css settings can be used in other places.

the bootstrap css already contains btn-success / btn-success /btn-warning by default. both of those are used throughout the webgui.
i thought it would be better to keep follow that naming-scheme ? what do you folks think?

Steve_B

As well as alert-success, alert-danger etc. We also now have an optional style argument to print_info_box() that I use quite a lot:

print_info_box(gettext("Changes saved."), success);

So keeping with the Bootstrap style names is a good thing IMHO.

dennypage

Bravo.

@Steve_B:

We need to accommodate those who do not see colors clearly.

router_wang

PLEASE go back to the colored "BLOCKED" and "PASS". Those are so much more ergonomic than a check or an "x". From an aesthetic standpoint they look a lot better too!

NOYB

@doktornotor:

The filter should be shrinked back to two rows as it was and grow itself a "hide" feature… Waste of screen estate.

Just for you (for 2.2.5)

Filter Form Hide Feature
Form hidden by default, shown when filtering/selected.
https://github.com/pfsense/pfsense/pull/2037

Steve_B

Thanks. I'll be adding similar functionality to 2.3 in the next few days.

doktornotor

@NOYB:

Just for you (for 2.2.5)

Filter Form Hide Feature
Form hidden by default, shown when filtering/selected.
https://github.com/pfsense/pfsense/pull/2037

NOYB

@Steve_B:

Thanks. I'll be adding similar functionality to 2.3 in the next few days.

Since you are in there working on that. If you're interested in consolidating some of that redundant code and adding filter form to the other system logs, feel free to grab anything from System Logs Consolidate Code and Add Advanced Filtering #1973 The most significant issue I know of is the regex pattern in /etc/inc/filter_log.inc needs a tweak for single digit day of month.

I'm currently running that on 2.2.5 with the following regex changes.

In function conv_log_filter($logfile, $nentries, $tail = 50, $filtertext = "", $fil…


	elseif ($logfile_type == 'system')		{ 
		$month_pattern = "[a-zA-Z]{3}";
		$day_pattern = "[0-9]{1,2}";
		$time_pattern = "[0-9]{2}:[0-9]{2}:[0-9]{2}";

		$date_pattern = "\(" . $month_pattern . "\ +" . $day_pattern . "\ +" . $time_pattern . "\)";

		$process_pattern = "\(.*?\)";
#		$pid_pattern = "\(.*?\)\(?::\ +\)?\(?:\[\([0-9:]*\)\]\)?:";
		$pid_pattern = "\(.*?\)\(?::\ +\)?\(?:\[[0-9:]*\]\)?:";
		$log_message_pattern = "\(.*\)";

		$pattern = "^" . $date_pattern . "\ +" . $process_pattern . "\ +" . $pid_pattern . "\ +" . $log_message_pattern . "$";
	}

In function parse_system_log_line($line)


	$month_pattern = "[a-zA-Z]{3}";
	$day_pattern = "[0-9]{1,2}";
	$time_pattern = "[0-9]{2}:[0-9]{2}:[0-9]{2}";

	$date_pattern = "(" . $month_pattern . "\ +" . $day_pattern . "\ +" . $time_pattern . ")";

	$process_pattern = "(.*?)";
	$pid_pattern = "(.*?)(?::\ +)?(?:\[([0-9:]*)\])?:";
	$log_message_pattern = "(.*)";

	$pattern = "/^" . $date_pattern . "\ +" . $process_pattern . "\ +" . $pid_pattern . "\ +" . $log_message_pattern . "$/";

	if (!preg_match($pattern, $line, $log_split))
		return "";

Steve_B

Thanks.

I consolidated all of the many logs pages into a single page + GET argument some months ago. I'll certainly check-out you regex suggestion.

NOYB

Unless adding the filter form to the system logs the regex that was there was fine as it only had to handle the firewall log.

I think it would be nice to have the filter form for the system logs too though.