Chapter 1. Welcome to the SRX
Firewalls are an important part of almost every network in the world. The firewall protects nearly every network-based transaction that occurs, and even the end user understands its metaphoric name, meant to imply keeping out the bad stuff. Despite what some competitive marketing campaigns have said, the is not dead, and it is every bit as necessary today as it was yesterday. But firewalls have had to change. Whether it’s the growth of networks or the growth of network usage, they have had to move beyond the simple devices that only require protection from inbound connections. A firewall now has to transcend its own title, the one end users are so familiar with, into a whole new type of device and service. This new class of device is a services gateway. And it needs to provide much more than just a firewall—it needs to look deeper into the packet and use the contained data in new ways that are advantageous to the network for which it is deployed. Can you tell if an egg is good or not by just looking at its shell? Once you break it open, isn’t it best to use all of its contents? Deep packet inspection from a services gateway is the new firewall of the future.
Deep packet inspection isn’t a new concept, nor is it something that Juniper Networks invented. What Juniper did do, however, is start from the ground up to solve the technical problems of peering deeply. With the Juniper Networks SRX Series Services Gateways, Juniper built a new platform to answer today’s problems while scaling the platform’s features to solve the anticipated problems of tomorrow. It’s a huge challenge, especially with the rapid growth of enterprise networks. How do you not only solve the needs of your network today, but also anticipate the needs for tomorrow?
Juniper expended an enormous amount of effort to create a platform that can grow over time. The scalability is built into the features, performance, and multifunction capability of the SRX Series. This chapter introduces the solutions the SRX Series can provide for your organization today, while detailing its architecture to help you anticipate and solve your problems of tomorrow.
Evolving into the SRX
The predecessors to the SRX Series products are the legacy ScreenOS products. They really raised the bar when they were introduced to the market, first by NetScreen and then by Juniper Networks. Many features might be remembered as notable, but the most important was the migration of a split firewall software and operating system (OS) model. Firewalls at the time of their introduction consisted of a base OS and then firewall software loaded on top. This was flexible for the organization, because it could choose the underlying OS it was comfortable with, but when any sort of troubleshooting occurred, it led to all sorts of finger-pointing among vendors. ScreenOS provided an appliance-based approach by combining the underling OS and the features it provided.
The integrated approach of ScreenOS transformed the market. Today, most vendors have migrated to an appliance-based firewall model, but it has been more than 10 years since the founding of NetScreen Technologies and its ScreenOS approach. So, when Juniper began to plan for a totally new approach to firewall products, it did not have to look far to see its next-generation choice for an operating system: Junos became the base for the new product line called the SRX Series.
ScreenOS to Junos
Juniper Networks’ flagship OS is Junos. The has been a mainstay of Juniper and it runs on the majority of its products. Junos was created in the mid-1990s as an offshoot of the FreeBSD Unix-like operating system. The goal was to provide a robust core OS that could control the underlying chassis hardware. At that time, FreeBSD was a great choice on which to base Junos, because it provided all of the important components, including storage support, a memory controller, a kernel, and a task scheduler. The BSD license also allowed anyone to modify the source code without having to return the new code. This allowed Juniper to modify the code as it saw fit.
Note
Junos has evolved greatly from its initial days as a spin-off of BSD. It contains millions of lines of code and an extremely strong feature set.
The aged gracefully over time, but it hit some important limits that prevented it from being the choice for the next-generation SRX Series products. First, ScreenOS cannot separate the running of tasks from the kernel. All processes effectively run with the same privileges. Because of this, if any part of ScreenOS were to crash or fail, the entire OS would end up crashing or failing. Second, the modular architecture of Junos allows for the addition of new services, because this was the initial intention of Junos and the history of its release train. ScreenOS could not compare.
Over time, solutions to yesterday’s problems age and become less relevant to today’s needs. Because of this, the functionality that is needed to solve today’s problems is greatly focused on deep packet inspection. This is a problem that ScreenOS was never designed to solve. With its ASIC-focused architecture, it allowed for amazing performance for stateful firewalling but poor performance deeper in the packet. Although ScreenOS could be further evolved into this market, Junos already had the necessary underpinnings to allow for deeper inspection.
Inherited ScreenOS features
Although the next-generation SRX Series devices were destined to use the well-developed and long-running Junos operating system, that didn’t mean the familiar features of ScreenOS were going away. For example, ScreenOS introduced the concept of zones to the firewall world. A zone is a logical entity that interfaces are bound to, and zones are used in security policy creation, allowing the specification of an ingress and egress zone in the security policy. Creating ingress and egress zones means the specified traffic can only pass in a specific direction. It also increases the overall speed of policy lookup, and because multiple zones are always used in a firewall, it separates the overall firewall rulebase into many subsets of zone groupings. We cover zones further in Chapter 3.
The virtual router (VR) is an example of another important feature developed in ScreenOS and embraced by the new generation of SRX Series products. A VR allows for substitute command the creation of multiple routing tables inside the same device, providing the administrator with the ability to segregate traffic and virtualize the firewall.
Table 1-1 elaborates on the list of popular ScreenOS features that were added to Junos for the SRX Series. Although some of the features do not have a one-to-one naming parity, the functionality of these features is generally replicated on the Junos platform.
Feature | ScreenOS | Junos |
Zones | Yes | Yes |
Virtual routers (VRs) | VRs | Yes as routing instances |
Screens | Yes | Yes |
Deep packet inspection | Yes | Yes as full intrusion prevention |
Network Address Translation (NAT) | Yes as NAT objects | Yes as NAT policies |
Unified Threat Management (UTM) | Yes | Yes |
IPsec virtual private network (VPN) | Yes | Yes |
Dynamic routing | Yes | Yes |
High availability (HA) | NetScreen Redundancy Protocol (NSRP) | Chassis cluster |
Virtual firewalls | Virtual Systems (VSYS) | Logical Systems (LSYS) |
Device management
Junos has evolved since it was first deployed in service provider networks. Over the years, many lessons were learned regarding how to best use the device running the OS. These practices have been integrated into the SRX Series and are shared throughout this book, specifically in how to use the command-line interface (CLI).
For the most part, Junos users traditionally tend to utilize the CLI for managing the platform. As strange as it may sound, even very large organizations use the CLI to manage their devices. The CLI was designed to be easy to utilize and navigate through, and once you are familiar with it, even large configurations are completely manageable through a simple terminal window. Throughout this book, we will show you various ways to navigate and configure the SRX Series products using the CLI.
Note
In Junos, the CLI extends beyond just a simple set of commands. The CLI is actually implemented as an Extensible Markup Language (XML) interface to the operating system. This XML interface is called Junoscript and is even implemented as an open standard called NETCONF. Third-party applications can integrate with Junoscript or a user may even use it on the device. Juniper Networks provides extensive training and documentation covering this feature; an example is its Day One Automation Series.
Sometimes, getting started with such a rich platform is a daunting task, if only because thousands of commands can be used in the Junos operating system. To ease this task and help users get started quickly, the SRX Series of products provides a web interface called J-Web. The J-Web tool is automatically installed on the SRX Series (on some other Junos platforms it is an optional package), and it is enabled by default. The interface is intuitive and covers most of the important tasks for configuring a device.
For large networks with many devices, we all know mass efficiency is required. It may be feasible to use the CLI, but it’s hard to beat a policy-driven management system. Juniper provides two tools for efficient management. The first tool is called Network and Security Manager (NSM). This is the legacy tool that you can use to manage networks. It was originally designed to manage ScreenOS products, and, over time, it evolved to manage most of Juniper’s products. However, the architecture of the product is getting old, and it’s becoming difficult to implement new features. Although it is still a viable platform for management, just like the evolution of ScreenOS to Junos, a newly architected platform is available.
This new platform is called Junos Space, and it is designed from the ground up to be a modular platform that can integrate easily with a multitude of devices, and even other management systems. The goal for Junos Space is to allow for the simplified provisioning of a network.
To provide this simplified provisioning, three important things must be accomplished:
Integrate with a heterogeneous network environment.
Integrate with many different types of management platforms.
Provide this within an easy-to-use web interface.
By accomplishing these tasks, Junos Space will take network management to a new level of productivity and efficiency for an organization. Junos Space is an application platform, meaning that you can load applications on it to provide additional functions. The most important to SRX users is Security Design (SD). This application focuses on the policy management of the SRX. It makes managing one or thousands of firewalls a breeze. The intuitive UI makes even the most complex policies simple to manage. It not only provides the traditional management that firewall administrators crave, but it has new paradigms that drive management efficacy in a whole new direction.
The SRX Series Platform
The SRX Series hardware platform is a next-generation departure from the previous ScreenOS platforms, built from the ground up to provide scalable services. Now, the question that begs to be answered is this: What exactly is a service?
A service is an action or actions that are applied to the network traffic passing through the SRX Series of products. Two examples of services are stateful firewalling and intrusion prevention.
The ScreenOS products were designed primarily to provide three services: stateful firewalling, NAT, and virtual private networking (VPN). When ScreenOS was originally designed, these were the core value propositions for a firewall in a network. In today’s network, these services are still important, but they need to be provided on a larger scale because the number of Internet Protocol (IP) devices in a network has grown significantly, and each of them relies on the Internet for access to information they need to run. Because the SRX is going to be processing this traffic, it is critical that it provides as many services as possible on the traffic in one single pass.
Built for Services
So, the SRX provides services on the passing traffic, but it must also provide scalable services. This is an important concept to review. Scale is the ability to provide the appropriate level of processing based on the required workload, and it’s a concept that is often lost when judging firewalls because you have to think about the actual processing capability of a device and how it works. Although all devices have a maximum compute capability, or the maximum level at which they can process information, it’s very important to understand how a firewall processes this load. This allows the administrator to better judge how the device scales under such load.
Scaling under load is based on the services a device is attempting to provide and the scale it needs to achieve. The traditional device required to do all this is either a branch device or the new, high-end data center firewall. A branch firewall needs to provide a plethora of services at a performance level typical of the available wide area network (WAN) speeds. These services include the traditional stateful firewall, VPN, and NAT, as well as more security-focused services such as UTM and intrusion prevention.
A data center firewall, on the other hand, needs to provide highly scalable performance. When a firewall is placed in the core of a data center, it cannot impede the performance of the entire network. Each transaction in the data center contains a considerable amount of value to the organization, and any packet loss or delay can cause financial implications. A data center firewall requires extreme stateful firewall speeds, a high session capacity, and very fast new sessions per second.
In response to these varied requirements, Juniper Networks created two product lines: the branch SRX Series and the data center SRX Series. Each is targeted at its specific market segments and the network needs of the device in those segments.
Deployment Solutions
Networking products are created to solve problems and increase efficiencies. Before diving into the products that comprise the SRX Series, let’s look at some of the problems these products solve in the two central locations in which they are deployed:
The branch SRX Series are designed for small to large office locations consisting of anywhere from a few individuals to hundreds of employees, representing either a small, single device requirement or a reasonably sized infrastructure. In these locations, the firewall is typically deployed at the edge of the network, separating the users from the Internet.
The data center SRX Series products are Juniper’s flagship high-end firewalls. These products are targeted at the data center and the service provider. They are designed to provide services to scale. Data center and service provider deployments are as differentiated as branch locations.
Let’s look at examples of various deployments and what type of services the SRX Series products provide. We will look at the small branch first, then larger branches, data centers, service providers, and mobile carriers, and finally all the way up (literally) to cloud networks.
Small Branch
A small branch location is defined as a network with no more than a dozen hosts. Typically, a small branch has a few servers or, most often, connects to a larger office. The requirements for a firewall device are to provide not only connectivity to an Internet source, or larger office connection, but also connectivity to all of the devices in the office. The branch firewall also needs to provide switching and, in some cases, wireless connectivity, to the network.
Figure 1-1 depicts a small branch location. Here a Juniper Networks SRX100 or SRX210 Services Gateway can be utilized. If WAN interfaces are not required, then the SRX100 is ideal. The SRX210 series is the same horsepower as the SRX100, but includes the ability to include WAN interfaces. The SRX220 can do dual WAN interfaces for ISP redundancy. Several hosts can connect to an upstream device that provides Internet connectivity. In this deployment, the device consolidates a firewall, Digital Subscriber Line (DSL) modem, and switch.
The small-location deployment keeps the footprint to one small device and keeps branch management to one device—if the device were to fail, it’s simple to replace and get the branch up and running using a backup of the current configuration. Finally, you should note that all of the network hosts are directly connected to the branch.
Medium Branch
In medium to large branch offices, the network has to provide more to the location because there are 20 or more users—our network example contains about 50 client devices—so here the solution is the Juniper Networks SRX200 Series Services Gateway branch device. Figure 1-2 shows the deployment of the SRX240 placed at the Internet edge. It utilizes a WAN port to connect directly to the Internet service provider (ISP).
Note that the servers are connected directly to the SRX240 to provide maximum performance and security. Because this branch provides email and web-hosting services to the Internet, security must be provided. Not only can the SRX240 provide stateful firewalling, but it can also offer intrusion protection services (IPS) for the Web and email services, including antivirus services for email.
Juniper has also introduced the SRX550, which is about twice as powerful as the SRX240. It also provides more interface density and gives more headroom for future expansion, so it is also a good consideration for the medium branch deployments.
Because of the size of the branch, the network can never go down. Using chassis cluster or ensures that if one device were to fail, the other will keep the network up and running. The servers have also been given dual network interface cards (NICs) to have an interface on each SRX. Because the SRX can offer HA switching, it allows the servers to stay up in the event of a single device failure.
Large Branch
The last branch deployment to review is the large branch. For our example, the large branch has 250 clients. This network requires significantly more equipment than was used in the preceding branch examples. Note that for this network, the Juniper Networks EX Series Ethernet Switches were reutilized to provide client access to the network. Figure 1-3 depicts our large branch topology.
Our example branch network needs to provide Ethernet access for 250 clients, so to realistically depict this, six groupings of two EX4200 switches are deployed. Each switch provides 48 tri-speed Ethernet ports. To simplify management, all of the switches are connected using Juniper’s virtual chassis technology.
Note
For more details on how the EX Series switches and the virtual chassis technology operates, as well as how the EX switches can be deployed and serve various enterprise networks, see JUNOS Enterprise Switching by Harry Reynolds and Doug Marschke (O’Reilly).
The SRX Series platform of choice for the large branch is the Juniper Networks SRX 550 or SRX650 Services Gateway. The SRX550 is ideal if you do not need additional headroom for your deployment. The SRX650 is the largest of the branch SRX Series products; its performance capabilities actually exceed those of the branch, allowing for future adoption of features in the branch. Just as was done in the previous deployment, the local servers will sit off of an arm of the SRX650, but note that in this deployment, HA was utilized, so the servers must sit off of their own switch (here the Juniper Networks EX3200 switch).
Also because the SRX is a next-generation firewall, it’s possible to have user-based dynamic firewalling. Each individual user can get authenticated for services using AppSecure. This is further discussed in the AppSecure chapter later in the book. The HA deployment of the SRX650 products means two devices are used, allowing the second SRX650 to take over in the event of a failure on the primary device. The SRX650 HA model provides an extreme amount of flexibility for deploying a firewall, and we detail its capabilities in Chapter 7.
Data Center
What truly is a data center has blurred in recent times. The traditional concept of a data center is a physical location that contains servers that provide services to clients. The data center does not contain client hosts (a few machines here and there to administer the servers don’t count) or clear bounds of ingress and egress to the network. Ingress points may be Internet or WAN connections, but each type of ingress point requires different levels of security.
The new data center of today seems to be any network that contains services, and these networks could even span multiple physical locations. In the past, a data center and its tiers were limited to a single physical location because there were some underlying technologies that were hard to stretch. But today, it’s much easier to provide the same Layer 2 network across two or more physical locations, thus expanding the possibilities of creating a data center. With the popularization of multiprotocol label switching (MPLS) and virtual private LAN service (VPLS) technologies, data centers can be built in new and creative ways.
The traditional data center design consists of a two- or three-tier switching model. Figure 1-4 shows both a two-tier and a three-tier switching design. Both are fundamentally the same, except that between the two is the addition of the aggregation switching tier. The aggregation tier compensates for the lack of port density at the core (only in the largest switched networks should a distribution tier be required).
Note that the edge tier is unchanged in both models. This is where the servers connect into the network, and the number of edge switches (and their configuration) is driven by the density of the servers. Most progressively designed data centers are using virtualization technologies that allow multiple servers to run on the same bit of hardware, reducing the overall footprint, energy consumption, and rack space.
Neither this book nor this chapter is designed to be a comprehensive primer on data centers. Design considerations for a data center are enormous and can easily fill up several volumes. The point here is to give a little familiarity to the next few deployment scenarios and to show how the various SRX Series platforms scale to the needs of those deployments.
Data Center Edge
As discussed in the previous section, a data center needs to have an ingress point to allow clients to access the data center’s services. The most common service is ingress Internet traffic, and as you can imagine, the ingress point is a very important area to secure. This area needs to allow access to the servers, yet in a limited and secure fashion, and because the data center services are typically high profile, they could be the target of denial-of-service (DoS), distributed denial-of-service (DDoS), and botnet attacks. It is a fact of network life that must be taken into consideration when building a data center network.
An SRX Series product deployed at the edge of the network must handle all of these tasks, as well as handle the transactional load of the servers. Most connections into applications for a data center are quick to be created and torn down, and during the connection, only a small amount of data is sent. An example of this is accessing a web application. Many small components are actually delivered to the web browser on the client, and most of them are delivered asynchronously, so the components might not be returned in the order they were accessed. This leads to many small data exchanges or transactions, which differs greatly from the model of large continual streams of data transfer.
Figure 1-5 illustrates where the SRX Series would be deployed in our example topology. The products of choice are the Juniper Networks SRX1400 and SRX3000 line, because they can meet the needs identified in the preceding paragraph. Figure 1-5 might look familiar to you, as it is part of what we discussed regarding the data center tier in Figure 1-4. The data center is modeled after that two-tier design, with the edge being placed at the top of the diagram. The SRX1400 and SRX3000 line of products do not have WAN interfaces, so upstream routers are used. The WAN routers consolidate the various network connections and then connect to the SRX1400 and SRX3000 products. For connecting into the data center itself, the SRX1400 and SRX3000 line uses its 10-gigabit Ethernet to connect to the data center core and WAN routers.
A data center relies on availability—all systems must be deployed to ensure that there is no single point of failure. This includes the SRX Series. The SRX3000 line provides a robust set of HA features. In Figure 1-5, both SRX3000 line products are deployed in what is traditionally called an active/active deployment. This means both firewalls can pass traffic simultaneously. When a product in the SRX3000 line operates in a cluster, the two boxes operate as though they are one unit. This simplifies HA deployment because management operations are reduced. Also, traffic can enter and exit any port on either chassis. This model is flexible compared to the traditional model of forcing traffic to only go through an active member.
Data Center Services Tier
The data center core is the network’s epicenter for all server communications, and most connections in a data center flow through it. A firewall at the data center core needs to maintain many concurrent sessions. Although servers may maintain long-lived connections, they are more likely to have connectivity bursts that last a short period of time. This, coupled with the density of running systems, increases the required number of concurrent connections, but at the rate of new connections per second. If a firewall fails to create sessions quickly enough, or falls behind in allowing the creation of new sessions, transactions are lost.
For this example, the Juniper Networks SRX5800 Services Gateway is a platform that can meet these needs. The SRX5800 is the largest member of the SRX5000 line, and is well suited for the data center environment. It can meet the scaling needs of today as well as those of tomorrow. Placing a firewall inside the data center core is always challenging, and typically the overall needs of the data center dictate the placement of the firewall. However, there is a perfect location for the deployment of our SRX5800, as shown in Figure 1-6, which builds on the example shown as part of the two-tier data center in Figure 1-4.
This location in the data center network is called the services tier, and it is where services are provided to the data center servers on the network traffic. This includes services provided by the SRX5800, such as stateful firewalling, IPS, Application Denial of Service (AppDoS) prevention, and server load balancing. This allows the creation of a pool of resources that can be shared among the various servers. It is also possible to deploy multiple firewalls and distribute the load across all of them, but that increases complexity and management costs. The trend over the past five years has been to move toward consolidation for all the financial and managerial reasons you can imagine.
In the data center core, AppSecure and IPS are two key services to include in the data center services tier design. The AppSecure feature allows the SRX5800 to look for attack patterns, unlike other security products. AppSecure can perform actions like application firewalling, application Quality of Service (QoS), and advanced application usage reporting.
A separate SRX Series specialty is IPS. The IPS feature differs from AppSecure as it looks for specific attacks through the streams of data. When an attack is identified, it’s possible to block, log, or ignore the threat. Because all of the connections to the critical servers will pass through the SRX5800, adding the additional protection of the IPS technology provides a great deal of value, not to mention additional security for the services tier.
Service Provider
Although most administrators are more likely to use the services of a service provider than they are to run one, looking at the use case of a service provider can be quite interesting. Providing connectivity to millions of hosts in a highly available and scalable method is an extremely tough proposition. Accomplishing this task requires a herculean effort of thousands of people. Extending a service provider network to include stateful security is just as difficult. Traditionally, a service provider processes traffic in a stateless manner, meaning that each packet is treated independently of any other. Although scaling stateless packet processing isn’t inexpensive, or simple by any means, it does require less computing power than stateful processing.
In a stateful processing device, each packet is matched as part of a new or existing flow. Each packet must be processed to ensure that it is part of an existing session, or a new session must be created. All of the fields of each packet must be validated to ensure that they correctly match the values of the existing flow. For example, in TCP, this would include TCP sequencing numbers and TCP session state. Scaling a device to do this is extremely challenging.
A firewall can be placed in many locations in a service provider’s network. Here we’ll discuss two specific examples: in the first, the firewall provides a managed service, and in the second, the service provider protects its own services.
Starting with the managed service provider (MSP) environment, Figure 1-7 shows a common MSP deployment. On the left, several customers are shown, and depending on the service provider environment, this could be several dozen to several thousand (for the purposes of explanation, only a handful are needed). The connections from these customers are aggregated to a Layer 2 and Layer 3 routing switch, in this case a Juniper Networks MX960 3D Universal Edge Router. Then the MX Series router connects to an SRX5800. The SRX5800 is logically broken down into smaller firewalls for each customer so that each customer gains the services of a firewall while the provider consolidates all of these “devices” into a single hardware unit. The service provider can minimize its operational costs and maximize the density of customers on a single device.
Our second scenario for service providers involves protecting the services that they provide. Although a service provider provides access to other networks, such as the Internet, it also has its own hosted services. These include, but are not limited to, Domain Name System (DNS), email, and web hosting. Because these services are public, it’s important for the service provider to ensure their availability, as any lack of availability can become a front-page story or at least cause a flurry of angry customers. For these services, firewalls are typically deployed, as shown in our example topology in Figure 1-8.
Several attack vectors are available to service providers’ public services, including DoS, DDoS, and service exploits. They are all the critical types of attacks that the provider needs to be aware of and defend. The data center SRX products can protect against both DDoS and the traditional DoS attack. In the case of a traditional DoS attack, the screen feature can be utilized.
A screen is a mechanism that is used to stop more simplistic attacks such as SYN and UDP floods (note that although these types of attacks are “simple” in nature, they can quickly overrun a server or even a firewall). Screens allow the administrator of an SRX Series product to set up specific thresholds for TCP and UDP sessions. Once these thresholds have been exceeded, protection mechanisms are enacted to minimize the threat of these attacks. We discuss the screen feature in detail in Chapter 11.
Mobile Carriers
The phones of today are more than the computers of yesterday; they are fully fledged modern computers in a hand-held format, and almost all of a person’s daily tasks can be performed through them. Although a small screen doesn’t lend itself to managing 1,000-line spreadsheets, the devices can easily handle the job of sharing information through email or web browsing. More and more people who would typically not use the Internet are now accessing the Internet through these mobile devices, which means that access to the public network is advancing in staggering demographic numbers.
This explosion of usage has brought a new challenge to mobile operators: how to provide a resilient data network to every person in the world. Such a mobile network, when broken down into smaller, easy-to-manage areas, provides a perfect example of how an SRX Series firewall can be utilized to secure such a network.
For mobile carrier networks, an SRX5800 is the right choice for a few specific reasons: its high session capacity and its high connections-per-second rate. In the network locations where this device is placed, connection rates can quickly vary from a few thousand to several hundred thousand. A quick flood of new emails or everyone scrambling to see a breaking news event can strain any well-designed network. And as mentioned in the preceding service provider example, it’s difficult to provide firewall services in a carrier network.
Figure 1-9 shows a simplified example of a mobile operator network. It’s simplified to focus more on the firewalls and less on the many layers of the wireless carrier’s network. For the purposes of this discussion, the way in which IP traffic is tunneled to the firewalls isn’t relevant.
In Figure 1-9, the handsets are depicted on the far left, and their radio connections, or cell connections, are terminated into the provider’s network. Then, at the edge of the provider’s network, when the actual data requests are terminated, the IP-based packet is ready for transport to the Internet or to the provider’s services.
An SRX5800 at the location depicted in Figure 1-9 is designed to protect the carrier’s network, ensuring that its infrastructure is secure. By protecting the network, it ensures that its availability and the service that customers spend money on each month continues. If the protection of the handsets is the responsibility of the handset provider in conjunction with the carrier, the same goes for the cellular or 3G Internet services that can be utilized by consumers using cellular or 3G modems. These devices allow users to access the Internet directly from anywhere in a carrier’s wireless coverage network—these computers need to employ personal firewalls for the best possible protection.
For any service provider, mobile carriers included, the provided services need to be available to the consumers. As shown in Figure 1-9, the SRX5800 devices are deployed in a highly available design. If one SRX5800 experiences a hardware failure, the second SRX5800 can completely take over for the primary. Of course, this failover is transparent to the end user for uninterrupted service and network uptime that reaches to the five, six, or even seven 9s, or 99.99999 percent of the time. As competitive as the mobile market is these days, the mobile carrier’s networks need to be a competitive advantage.
Cloud Networks
It seems like cloud computing is on everyone’s mind today. The idea of providing any service to anyone at any time to any scale with complete resilience is a dream that is becoming a reality for many organizations. Both cloud computing vendors and large enterprises are providing their own private clouds.
Although each cloud network has its own specific design needs, the SRX Series can and should play an important role.
That’s because a cloud network must scale in many directions to really be a cloud. It must scale in the number of running operating systems it can provide. It must scale in the number of physical servers that can run these operating systems. And it must scale in the available number of networking ports that the network provides to the servers. The SRX Series must be able to scale to secure all of this traffic, and in some cases, it must be able to be bypassed for other services. Figure 1-10 depicts this scale in a sample cloud network that is meant to merely show the various components and how they might scale.
The logical items are easier to scale than the physical items, meaning it’s easy to make 10 copies of an operating system run congruently, because they are easily instantiated, but the challenge is in ensuring that enough processing power can be provided by the servers, as they are a physical entity and it takes time to get more of them installed. The same goes for the network. A network in a cloud environment will be divided into many virtual LANs (VLANs) and many routing domains. It is simple to provide more VLANs in the network, but it is hard to ensure that the network has the capacity to handle the needs of the servers. The same goes for the SRX Series firewalls.
For the SRX Series in particular, the needs of the cloud computing environment must be well planned. As we discussed in regard to service providers, the demands of a stateful device are enormous when processing large amounts of traffic. Because the SRX Series device is one of the few stateful devices in the cloud network, it needs to be deployed to scale. As Figure 1-10 shows, the SRX5800 is chosen for this environment because it can be deployed in many different configurations based on the needs of the deployment. The capabilities of the SRX5800 are discussed in Chapter 2.
Because of the dynamic nature of cloud computing, infrastructure provisioning of services must be done seamlessly. This goes for every component in the network, including the servers, the network, and the firewalls. Juniper Networks provides several options for managing all of its devices, as shown in Figure 1-11, which illustrates the management paradigm for the devices.
Just as the provisioning model scales for the needs of any organization, so does the cloud computing model. On the far left in Figure 1-11, direct hands-on or user device management is shown. This is the device management done by an administrator through the CLI or web management system (J-Web). The next example is the command of the device by way of its native application programming interface (API; either Junos automation or NETCONF, both of which we discuss in Chapter 2), where either a client or a script would need to act as the controller that would use the API to provision the device.
The remaining management examples are similar to the first two examples of the provisioning model, except they utilize a central management console provided by Juniper Networks. Model three shows a user interacting with the default client provided by the Juniper Networks NSM or Junos Space. In this case, the NSM uses the native API to talk to the devices.
Lastly, management option six is the most layered and scalable approach. It shows a custom-written application controlling the NSM directly with its own API, and then controlling the devices with its own API.
Although this approach seems highly layered, it provides many advantages in an environment where scaling is required. First, it allows for the creation of a custom application to provide network-wide provisioning in a case where a single management product is not available to manage all of the devices on the network. Second, the native Juniper application is developed specifically around the Juniper devices, thus taking advantage of the inherent health checks and services without having to integrate them.
The Junos Enterprise Services Reference Network
To simplify the SRX Series learning process, this book consistently uses a single topology that contains a number of SRX Series devices and covers all of the scenarios, many of the tutorials, and all of the case studies in the book. A single reference network allows the reader to follow along and only have to reference one network map.
Note
This book’s reference network is primarily focused on branch topologies because the majority of readers have access to those units. For readers who are interested in or are using the data center SRX products, these are discussed as well, but the larger devices are not the focus for most of the scenarios. Where differences exist, they will be noted.
Figure 1-12 shows this book’s reference network. The network consists of three branch deployments, two data center firewall deployments, and remote VPN users. Five of the topologies represent HA clusters with only a single location that specifies a non-HA deployment. The Internet is the network that provides connectivity among all of the SRX Series deployments. Although the reference network is not the perfect “real-world” network, it does provide the perfect topology to cover all of the features in the SRX Series.
Note
Although three of the locations are called branches, they could also represent standalone offices without a relationship to any other location.
The first location to review is the South Branch location. The South Branch location is a typical small branch, using a single SRX100 device. This device is a small, low-cost appliance that can provide a wide range of features for a location with 2 to 10 users and perhaps a wireless access point, as shown in the close-up view in Figure 1-13. The remote users at this location can access both the Internet and other locations over an IPsec VPN connection. Security is provided by using a combination of stateful firewalling, IPS, and UTM.
The West Branch, shown in Figure 1-14, is a larger remote branch location. The West Branch location uses two SRX240 firewalls. These firewalls are larger in capacity than the SRX210 devices in terms of ports, throughput, and concurrent sessions. They are designed for a network with more than 10 users or where greater throughputs are needed. Because this branch has more local users, HA is required to prevent loss of productivity due to loss of access to the Internet or the corporate network.
The East Branch location uses the largest branch firewall, the SRX650. This deployment represents both a large branch and a typical office environment where support for hundreds of users and several gigabits per second of throughput is needed. The detailed view of the East Branch is shown in Figure 1-15. This deployment, much like that of the West Branch, utilizes HA. Just as with the other branch SRX Series devices, the SRX650 devices can also use IPS, UTM, stateful firewalling, NAT, and many other security features. The SRX650 provides the highest possible throughput for these features compared to any other branch product line.
Deployment of the campus core firewalls of our reference network will be our first exploration into the high-end or data center SRX Series devices. These are the largest firewalls of the Juniper Networks firewall product line (at the time of this book’s publication). The deployment uses SRX5800 products, and more than 98 percent of the data center SRX Series firewalls sold are deployed in a highly available deployment, as represented here. These firewalls secure the largest network in the reference design, and Figure 1-16 illustrates a detailed view of the campus core.
Our campus core example network shows three networks; in a “real-world” deployment this could be hundreds or thousands of networks, but to show the fundamentals of the design and to fit on the printed page, only three are used: Department-A, Department-B, and the Internal Servers networks. These are separated by the SRX5800 HA cluster. Each network has a simple switch to allow multiple hosts to talk to each other. Off the campus core firewalls is a demilitarized zone (DMZ) SRX Series firewall cluster, as shown in Figure 1-17.
The DMZ SRX Series devices’ firewall deployment uses an SRX3600 firewall cluster. The SRX3600 firewalls are perfect for providing interface density with high capacity and performance. In the DMZ network, several important servers are deployed. These servers provide critical services to the network and need to be secured to ensure service continuity.
This DMZ deployment is unique compared to the other network deployments because it is the only one that highlights transparent mode deployment, which allows the firewall to act as a bridge. Instead of routing packets like a Layer 3 firewall would, it routes packets to a destination host using its media access control (MAC) address. This allows the firewall to act as a transparent device, hence the term.
Finally, you might note that the remote VPN users are an example use case of two different types of IPsec access to the SRX Series firewalls. The first is the Dynamic VPN client, which is a dynamically downloaded client that allows client VPN access into the branch networks. The second client type highlighted is a third-party client, which is not provided by Juniper but is recommended when a customer wants to utilize a standalone software client. We will cover both use cases in Chapter 10. Last, customers often deploy a MAG Pulse appliance. This allows for Secure Sockets Layer (SSL) VPN termination.
The reference network contains the most common deployments for the SRX Series products, allowing you to see the full breadth of topologies within which the SRX Series is deployed. The depicted topologies show all the features of the SRX Series in ways in which actual customers use the products. We intend for real administrators to sit down and understand how the SRX Series is used and learn how to configure it. We have seen the majority of SRX Series deployments in the world and boiled them down to our reference network.
Summary
This chapter covered the most common deployment options for an SRX. This by no means covers all of the possible types of configurations. The new types of designs that customers use to solve complex network issues always impress us at Juniper Networks. By harnessing the power of Junos and a bit of creativity, the SRX can solve most network deployments. This speaks volumes about the capabilities of the SRX. Often we are tapping into new possible deployment models to solve complex problems.
The development of the SRX tends to focus on the use cases covered in this book. It ensures that the SRX can offer optimal solutions for the most desired use cases. These specific scenarios are covered in various test beds ensuring the best possible stability and features to solve these common problems. Without a specific direction, the SRX would become a mismatch of features that wouldn’t solve anyone’s problems without expending a great amount of configuration effort.
Study Questions
- Questions
What is the importance of deep packet inspection?
What was the name of the OS that the SRX evolved from?
What security concept did the SRX inherit from its predecessor that simplified policy creation?
What application is used in Junos Space to manage SRX policies?
What is the core design change that SRX brought over the NetScreen devices?
What are the two classes or types of SRX devices?
- Answers
Deep packet inspection allows looking inside of the application layer of a packet. This technology is used in IPS, AppSecure, UTM, and other features to determine what the traffic contains.
ScreenOS was the OS that SRX used as a starting point for the products’ evolution.
This concept is called zones. It allows for a simpler abstract to use when creating policies. It also reduces the lookup tables for policies, providing faster lookups for matches.
Security Design is the application that simplifies policy management for the SRX devices.
The SRX is focused on providing services, whereas the NetScreen devices were focused on stateful inspection.
The two SRX device classes are branch and data center. The data center devices are also often called high-end firewalls.
Get Juniper SRX Series now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
