manual
Table Of Contents
- Introduction
- Scope
- Design Considerations—Connectivity at the Branch Office
- Branch-Office Connectivity over IPsec VPN
- Design Recommendations
- Routing Information Protocol
- Traffic Load Balancing for Type B and Type C Branch Deployments
- Using Border Gateway Protocol for Large Networks
- Using OSPF for Small Number of Branch Offices
- Using Auto Connect VPN to Create Branch-to-Branch IPsec Tunnels
- High Availability for the Branch Office
- High Availability Requirement Levels (Link, Device, Device, and Link Levels)
- High Availability Functionalities
- High Availability for Branch Office Type A
- VPN Security Zone Configuration for Type A
- High Availability for Branch Office Type B
- Using Secure Services Gateway for Type B
- High Availabilty for Branch Office Type C
- Connectivity at the Data Center
- Implementing a High Availability Enterprise Network at the Data Center
- Quality of Service Design Requirements
- WX Design Requirements
- Summary
- Appendix A Related Documents
- Appendix B Naming Conventions
- Appendix C Products
- About Juniper Networks
- Figure 1: Connecting branch offices, campus locations, and data centers over a single converged network
- Figure 2: Branch office reference architecture
- Figure 3: Multi-tiered/layered network architecture
- Figure 4: Two-tier network design for data centers
- Figure 5: Branch with dual internet connections (load balancing using ECMP)
- Figure 6: BGP routing design
- Figure 7: Star topology – connecting branches to central hub
- Figure 8: AC VPN provisioned tunnels between branches in the same region
- Figure 9: Multi-tier topology
- Figure 10: HA configuration for Type A
- Figure 11: VPN security zone configuration for Type A
- Figure 12: Type B optimized – HA configuration
- Figure 13: Type B – security zones
- Figure 14: Type C – HA configuration
- Figure 15: Intra-branch using OSPF
- Figure 16: Branch Type C – security zones
- Figure 17: Enterprise network for the data center
- Figure 18: M Series Multiservice Edge Routers
- Figure 19: Internet firewalls
- Figure 20: VPN firewalls
- Figure 21: VPN firewall IPS policy
- Figure 2: Branch office reference architecture

24 Copyright © 2010, Juniper Networks, Inc.
APPLICATION NOTE - Branch Office Connectivity Guide
The first set of firewalls, specifically the Internet firewalls, needs to provide a few specific functions. The Internet
firewalls must host the NOC. The NOC is deployed off of the firewalls like a traditional DMZ to ensure that the data it
collects is secured and unaltered by attackers. The Internet firewalls also must connect to the Internet and receive
routing information from the edge routers. This routing information is then passed to the shared services core
connected behind the Internet firewalls.
The second set of firewalls, the IPsec VPN firewalls, provide the connectivity hub for all remote sites and terminate
IPsec VPNs from the Internet as well as from the private WAN. These firewalls connect to the Internet and receive
routing information. This allows for connectivity to the Internet and provides access for the remote branches to
connect and terminate their VPNs. The connection to the private WAN is similar to the Internet, except that the
network is private. The IPsec firewalls also terminate VPN tunnels for all of the remote branches over the private
WAN. To provide services into the remote branches, the IPsec VPN firewalls must connect to the shared services core.
The firewalls are designed for availability and are similar to those found in a data center or Internet perimeter.
Besides the inclusion of redundant hardware, dynamic routing protocols and fully meshed links are employed to
minimize the amount of failure cases that could impede Internet access.
The separation of Internet accessibility and VPN termination is a choice that each organization must make if it
employs VPN services. In this solution, the separation provides a highly scalable VPN services infrastructure without
dependencies on the availability of the Internet firewall. If a network flood or Internet-based attack occurred on
the Internet services firewalls, it is possible to lose VPNs if the two were integrated. Therefore, the VPN devices
are scaled to provide several thousand tunnels and are limited to only this function. The VPN termination firewalls
terminate not only Internet-based VPNs but also VPNs that come across the private WAN.
Internet Firewalls
The hardware requirements for the Internet firewall are fairly basic and generally not required to provide a great
deal of throughput or concurrent sessions. They are only needed to integrate with dynamic routing, secure the NOC,
and secure access to the Internet. For this purpose, Juniper uses a cluster of SSG Series firewalls to implement the
Internet firewalls. If more throughput and more services were going to be hosted behind the Internet firewalls, a
cluster of Juniper Networks ISG Series Integrated Security Gateways would be used.
The NSRP configuration used for the Internet firewalls is a mix of active/active and active/passive. First, VSD 0
was unset to make all of the physical interfaces have unique IP addresses. The Interface IP addresses are not
synchronized among cluster members, allowing both firewalls to maintain their own OSPF neighbor relationships.
If a failover occurs, the firewall does not need to build its own relationships, which eliminates downtime during the
transition. However, this solution requires terminating interfaces for two separate purposes. The first is used for NAT
(both source and destination), and the second is used as a gateway for the hosts on the NOC. To do this, the cluster
must also act as a traditional active/passive NSRP cluster.
To have the firewall also provide these terminating interfaces, a VSD: VSD 1 was created. This allows a VSD to overlay
on top of the firewalls. It acts as a traditional active/passive cluster, with one firewall being the primary owner.
Juniper created two VSI interfaces to accomplish this.
The Internet firewalls are designed to be resilient through two specific failure cases: interface failure and device
failure. To overcome the possibility of interface failure, the firewalls use meshed links where possible. If one link
fails, the second link takes over for the first. It is possible to use redundant or aggregate interfaces, but these
interface types were not chosen for two reasons. First, as the network already allows dynamic routing protocols, it
automatically corrects itself during link failure. Second, ScreenOS currently has a limitation where redundant and
aggregate interfaces are unable to apply the screen feature TCP SYN cookie.
The weak point in this design is that the NOC only has a single interface per device connected to it. If a firewall loses
this interface, it MUST fail over to the secondary. This is a challenge because the firewall must fail over both the
routing protocol and the VSD. Because these are separate autonomous systems, the device must perform some
additional actions to fail over both.
The firewall must take two monitoring steps to ensure that the routing protocol and the VSD fail over together. The
VSD contains the loopback interface the firewall needs for NAT traffic. If that interface does not exist on the firewall
that is accepting the traffic, then NAT will fail, which causes the traffic to fail ultimately.
First, because the VSI that the NOC hosts uses the failover interface, and is bound to that VSD, the firewall must
monitor and verify that the NOC interface is up. The firewall must fail over the VSD if the NOC interface fails. If the
interface fails, then it must force down the interfaces connected to the Internet. This action prevents the firewall