Re: PIX & access-list

In article <1149255503.104414.245220@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<soup_or_power@xxxxxxxxx> wrote:
Walter Roberson wrote:
In article <1149187872.808706.243500@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<soup_or_power@xxxxxxxxx> wrote:
I had this rule in the PIX to accept https requests from a specific
host

access-list incoming permit tcp 255.138.142.224 255.255.255.224 host 209.255.196.216 eq 443

Oops sorry, the router IP is 255.138.142.224.

If the router IP is 255.138.142.224 then why does your netmask
also end in 224 -- that would make the router IP the base network
IP of the subnet, and the base network IP of any subnet is reserved.
(If you look at the math, it turns out that if you have a netmask of
255.255.255.X then any IP that ends with X must be the reserved base IP
of the subnet.)

It is true that in PIX ACLs, the masks are really bitmasks rather
than netmasks, so the line is not necessarily invalid (just suspicious) --
but even so it contradicts your original statement that you want to
accept https requests from a specific -host-. And if you want to
accept https from a specific host, then you wouldn't be putting your
router IP there ?!


How do I turn on logging?

logging on
logging timestamp
logging buffered notifications
logging queue 512

This will send a copy of all messages of priority "notification" or
higher to the PIX wrap-around message buffer, which can be displayed
by using the command show log

The memory buffer usually can only hold a few seconds worth of
information, so you would normally want to enable syslog on a server and
then,

logging trap notifications
logging host inside SERVERIP

This will send a copy of all messages of priority "notification" or
higher to the syslog process on host SERVERIP.

Logging level notification is often enough to solve "Duh, why didn't
I think of that!" type of ACL problems, but if you have a difficult
ACL problem then you would want to switch to logging trap debugging
You probably only want to use debugging level to a syslog server
(and not to the onboard memory buffer) because the traffic volume
of messages is fairly high at debugging level.

To recap briefly: "logging buffered" controls the level of messages
available via "show log", and "logging trap" controls the level
of messages sent to the syslog server.
.