Integrating Exchange 2000 with Cisco PIX Firewalls

November 2002 •  Reading time: 6 minutes

Integrating Exchange 2000 servers with Cisco PIX firewalls poses a unique set of challenges. While both technologies are widely adopted in enterprise networks, ensuring that mail delivery and remote access functions properly requires careful planning and precise configuration.

Understanding the Exchange Communication Model

Exchange 2000 uses several ports for its various services. SMTP traffic usually goes through TCP 25, while RPC over HTTP and MAPI involve dynamic port ranges and specific service ports. This makes static firewall rules harder to implement unless port restrictions are enforced on the Exchange server.

Challenges Introduced by Cisco PIX

The PIX firewall, by default, performs stateful inspection and may block unknown or dynamic ports unless explicitly configured. It also supports inspection for certain protocols like SMTP and FTP, but Exchange communication, especially RPC, doesn't fall into these easy categories.

Best Practices for Integration

• Pin down dynamic ports used by Exchange services via the Windows registry.
• Use static NAT mappings for the Exchange server to avoid issues with PAT and RPC.
• Open and inspect only the necessary ports (TCP 25, TCP 135, and specific RPC ranges).
• Use PIX access lists with tight source/destination criteria to reduce exposure.
• Enable SMTP fixup on PIX but test thoroughly to ensure it doesn’t interfere with message flow.

Optional: Publishing Exchange for Remote Access

If remote access is required, consider implementing a VPN solution or publishing Exchange via OWA (Outlook Web Access) using HTTPS. The latter can be placed in a DMZ with strict firewall rules separating it from internal Exchange servers.

Final Thoughts

Successful integration depends on balancing access with security. By understanding how Exchange communicates and how PIX firewalls enforce policies, administrators can deploy resilient and secure messaging platforms even in complex networks.

Eduardo Wnorowski is a technology consultant focused on network and infrastructure. He shares practical insights from the field for engineers and architects.

OSPF Route Filtering: Practical Use Cases

July 2002 - Estimated reading time: 7 minutes

Route filtering in OSPF isn't just theory—it’s a vital part of large-scale enterprise design. While OSPF was designed to be a link-state protocol with complete topological visibility, real-world implementations often require strategic control over route propagation.

Why Filter OSPF Routes?

In multi-area OSPF designs, especially in large environments with dozens of areas, it’s not always desirable—or scalable—to allow every route to flood throughout the OSPF domain. Route filtering helps reduce routing table size, simplify troubleshooting, and improve convergence in unstable networks.

Common Use Cases

• ABR Route Filtering: Prevent specific intra-area routes from being advertised between areas.
• LSA Type 3 Filters: Limit external redistribution to specific areas using prefix lists and distribute-lists.
• Stub and NSSA Areas: Used in conjunction with filters to avoid unnecessary Type 5 LSAs.

Configuration Tips

Use area X filter-list prefix carefully—it’s only effective on ABRs and applies to Type 3 LSAs. In Cisco IOS, use distribute-list out on redistribution points to control external routes from leaking into OSPF.

Gotchas

OSPF is not designed to have per-router customized views like BGP. Too much filtering can break SPF calculations or make troubleshooting hellish. Always validate filters with show ip ospf database and simulate changes in lab before deploying.

Eduardo Wnorowski is a technology consultant focused on network and infrastructure. He shares practical insights from the field for engineers and architects.

Network Baseline: Why It Matters

March 2002 • 3 min read

Most engineers think about performance only after issues appear. But understanding your network’s baseline is the first step toward proactive management.

I start by identifying quiet periods—early mornings or late nights. During these windows, I gather stats: CPU usage, interface load, memory consumption, packet drop rates, and latency between critical points.

On Cisco switches, I use SNMP and CLI outputs (like show interface, show process cpu) to collect this data. If I’ve deployed Windows or Linux boxes, I include performance counters or tools like top, vmstat, or Performance Monitor.

The goal is simple: know what “normal” looks like. Once I have a baseline, I can compare later stats against it—whether for troubleshooting, capacity planning, or validating changes.

Remember: no baseline means every spike feels like an emergency.

Eduardo Wnorowski is a technology consultant focused on network and infrastructure. He shares practical insights from the field for engineers and architects.