Initial Firewall Deployment and Configuration

Let us start with what a firewall actually is. A firewall is a device (or a piece of software) that sits between two networks — typically between your company’s internal network (the inside) and the internet (the outside). Its job is to inspect every packet of data that tries to cross from one side to the other and decide whether to allow it or block it, based on rules you define. The Palo Alto Networks firewall is a next-generation firewall (NGFW), meaning it can look at much more than just IP addresses and port numbers; it can identify the actual application trying to use the network, the user who is sending the traffic, and even the content inside the packet.

The first thing you do when you get a new firewall is plug it in, turn it on, and connect a laptop to its console port (a special management port) or to one of its network interfaces. You give the firewall a basic IP address for its own management interface so you can reach it from your laptop. This is like installing a temporary doorbell on an empty building so you can get inside to start the real work.

Once you can access the firewall’s web interface (a graphical, browser-based control panel called Panorama or the local web interface), you begin with interfaces. An interface is a physical port (or a virtual one on a virtual firewall) that connects to a network cable. On a physical Palo Alto Networks firewall, you have numbered ports like ethernet1/1, ethernet1/2, and so on. Each interface can be configured for a specific purpose. For example, you might set ethernet1/1 as the interface that faces the internet (the wide area network, or WAN), and ethernet1/2 as the interface that connects to your internal network (the local area network, or LAN). You assign each interface an IP address — a unique numeric label that devices use to find each other on the network. For the internet-facing interface, you would typically use a public IP address assigned by your internet service provider. For the internal interface, you would use a private IP address from ranges like 192.168.x.x or 10.x.x.x, which are not directly routable on the internet.

After interfaces are configured, you create zones. A zone is a logical grouping of one or more interfaces that share a common security level. For example, you might create an Untrust zone for the internet-facing interface, a Trust zone for the internal network interface, and a DMZ (demilitarised zone) for servers that must be accessible from the internet, such as a web server. Why zones? Because Palo Alto Networks firewalls enforce security policies between zones, not between individual interfaces. If you want to allow employees to browse the web, you write a policy that permits traffic from the Trust zone to the Untrust zone. If you want to block outsiders from reaching your internal file server, you simply do not write a policy that allows traffic from Untrust to Trust. By default, all inter-zone traffic is blocked, which is a security best practice called implicit deny. Zones also simplify management: if you add a second interface to the Trust zone later, it automatically follows the same rules.

The third major part of initial configuration is management access. This is about who can log in to the firewall itself and how. The firewall has a dedicated management interface (often labelled MGT) that you use for administrative tasks. You configure which IP addresses are allowed to connect to that interface, what authentication method is used (such as a local username and password, or a remote system like Microsoft Entra ID), and which services are enabled (HTTPS for the web interface, SSH for command-line access, and maybe ping for basic troubleshooting). A common beginner mistake is to leave the management interface exposed to the internet — that is like leaving the master key under the doormat. Exam objective 2.1 expects you to restrict management access to specific trusted IP addresses only, and to use strong authentication.

Why does all of this exist? Before firewalls, network security relied on host-based controls — every computer had to defend itself. That was impractical because it meant securing hundreds or thousands of machines individually. The firewall centralises security at the point where your network meets the outside world. Initial deployment and configuration are the critical first steps because they define the firewall’s identity within your network (its IP addresses), what it sees as safe or unsafe (zones), and how you talk to it (management access). Without these basics, the firewall cannot enforce any policies at all.

Consider a medium-sized company called GreenLeaf Supplies, which has 200 employees at its headquarters. GreenLeaf recently purchased a Palo Alto Networks PA-440 firewall to replace an old, unsupported router-based firewall that had no security features. The IT manager, Priya, is responsible for the initial deployment.

Priya starts by unboxing the PA-440, connecting the console cable from her laptop to the console port, and opening a terminal emulator application (like PuTTY). She powers on the firewall and sees boot messages scroll by. She then assigns a temporary IP address (192.168.1.1) to the MGT interface and connects her laptop to the MGT port with a network cable. Now she can open a web browser and access the firewall’s web interface at that IP address. The firewall asks her to create an initial admin account — she sets a strong password and stores it in a password manager.

Next, she looks at the physical ports on the back of the firewall. The ISP fibre connection (the internet line) will plug into ethernet1/1. The internal switch that connects all employee computers will plug into ethernet1/2. She configures ethernet1/1 with a static public IP address provided by her ISP: 203.0.113.10 with a subnet mask of 255.255.255.248. She configures ethernet1/2 with a private IP address: 10.10.10.1 with a mask of 255.255.255.0. She gives both interfaces descriptive names: the first she calls “Outside-Internet” and the second “Inside-Corp”.

Now Priya creates the zones. She creates a zone called “Untrust” and assigns the Outside-Internet interface to it. She creates a zone called “Trust” and assigns the Inside-Corp interface to it. She also creates a third zone called “DMZ” for a future web server, even though that interface is not yet connected, so the zone is ready to use. In the zone properties, she leaves the default settings — no need to tweak them yet.

Finally, she turns to management access. Priya knows that the MGT interface should never be reachable from the internet, so she ensures the management profile (a set of allowed services and source IPs) only permits connections from the internal 10.10.10.0/24 network. She also enables HTTPS and SSH, but disables ping to reduce visibility to attackers. She defines an authentication profile that points to GreenLeaf’s Microsoft Entra ID instance, so administrators can use their existing corporate credentials instead of a separate local account. She performs a quick test: she logs out, then logs back in from her workstation using her Entra ID credentials. It works.

The firewall is now deployed. Priya has not yet written any security policies, but the foundation is solid. The firewall has an identity, its interfaces are named and zoned, and management access is locked down. The next morning, she will begin writing rules to allow outbound web traffic and to block everything else.