Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: Pix performance |
|---|---|
| Date: | Thu, 27 Jan 2005 17:14:29 -0600 |
Norwich University - Information Security <infosec@norwich.edu> wrote:I have just inherited a PIX 515e and am wondering if it is capable (from a performance perspective) of acting as our main firewall.
Given the term "inherited", you may wish to check the PIXOS version, also if the device is currently using conduits, upgrading to the latest code will require migrating the configuration to ACLs.
We are a small university with approximately 2500 users. Our incoming/outgoing bandwidth is 32Mb/s and can run any where from 4% to 90% utilization with a rough average of about 62% (20Mb/s). Does anyone know from personal experience if the PIX 515e can reliably handle this magnitude of usage doing both filtering and NAT?
By "filtering" are you referring to ACLs, or to web content filtering through an off-box "censorware" solution? (NetNanny, Websense, Smartfilter, etc) On Thu, 27 Jan 2005 14:54:48 -0500, Jason Albuquerque <JAlbuquerque@northkingstown.org> wrote:
Yes a 515e is very capable of handling filtering and Nat and Some!! Here it is used for Filtering, NAT, DMZ, ACL's, 4 VLANs, VPN and more for a municipality.
The PIX should be able to handle this traffic under normal usage, I have run into performance problems with PIX when even a small number of internal clients become infected with network scanning worms; in my particular case the client was sourcing from a bogus IP address (a RFC1918 address not actually used on the internal network), so TCP requests would be sourced out from "trusted" but no replies would ever come back, seems to be a state table issue. Pre-filtering both inbound and outbound traffic to drop spoofed sources mitigated the PIX issue until the underlying worm infestation was addressed. Just one more "gotcha" to watch for. Kevin Kadow
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Pix performance, Roger McLaren |
|---|---|
| Previous by Thread: | RE: Pix performance, Jason Albuquerque |
| Next by Thread: | Re: Pix performance, Roger McLaren |
| Indexes: | [Date] [Thread] [Top] [All Lists] |