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
Copyright © 2010, Juniper Networks, Inc. 29
APPLICATION NOTE - Branch Office Connectivity Guide
access between branches. Many organizations often terminate the private WAN into the shared services core or core
network. This method potentially allows attacks or allows unsecured traffic to migrate to the private WAN from the
branch offices. Even though the private WAN provides a different type of connectivity than an Internet-based VPN, the
traffic should still be treated the same as the Internet traffic.
Juniper Networks integrates the VPN firewalls with two routing protocols: OSPF and RIP. OSPF is the primary
interior routing protocol used throughout the solution. RIP is used on the tunnels established with the various branch
locations. OSPF is used to pass routes between all of the devices. However, OSPF cannot be used for all of the VPN
tunnels because large VPN topologies do not accommodate the use of this protocol. First, all of the remote devices,
which are small, cannot handle all of the routing information. Second, one change in the topology forces all of the
sites to recalculate SPF. It is possible for this to happen several times in an hour, causing a flurry of calculations.
OSPF also does not filter routing information, except at area borders.
Figure 20: VPN firewalls
ScreenOS supports two other routing protocols: RIP and BGP. This solution uses RIP. While BGP is better suited for
larger deployments, the protocol can be cumbersome and complex to manage. Because customers already use RIP
for broadcasting routes, it was an easy decision to continue using this protocol for all of the remote branches as well.
RIP is enabled on the tunnel interfaces only. All of the learned routes from the remote branches move into the trust
virtual router. These routes are then distributed into OSPF as Type 2 external OSPF routes. This methodology allows
the data center to determine the location for all of the remote sites. Because two firewalls are active at any time,
all of the individual routes must be sent to the entire data center. See Implementing HA at the Enterprise Data Center
to Connect to a Large Number of Branch Offices for protocol configuration settings. The RIP preference has been
changed so that the learned RIP route for the remote location will be preferred over the learned OSPF route.
All of the VPNs that terminate at the firewall use the ScreenOS standard implementation for security. This means
that the tunnels use 3DES encryption and SHA1 for hashing. Each of the VPN firewalls has 10 tunnel interfaces. The
tunnel interfaces employ the Next Hop Tunnel Binding (NHTB) protocol to determine the remote networks that are
associated with their respective VPNs and tunnel interfaces. Using the RIP feature demand circuits, the NHTB table
is automatically updated to reflect the location of the remote network.
The firewall security policy is nearly identical to the policy configured at the branch office. The policies are extremely
restrictive, allowing access for only the minimum required services. All of the policies on the VPN firewalls have
intrusion detection and protection inspection enabled. The IPS policy is set up to stop the most critical recommended
attacks. The policy also logs any minor attacks. Figure 21 shows the IPS policy used on the VPN firewalls.
Figure 21: VPN firewall IPS policy
SSG
Series (A)
SSG
Series (B)
ethernet0/0
172.18.8.2/30
OSPF Cost-5
ethernet0/1
172.18.8.14/30
OSPF Cost-1000
ethernet0/0
172.18.8.10/30
OSPF Cost-500
ethernet2/0
192.168.128/24
ethernet0/0
172.18.8.34/30
OSPF Cost- 500
ethernet2/1
192.168.4.3/24
ethernet0/3
172.18.8.83/30
OSPF Cost-1000
ethernet2/0
192.168.3.127/24
ethernet2/1
192.168.4.2/24
ethernet0/2
172.18.8.26/30
OSPF Cost-5
ethernet0/3
172.18.8.30/30
OSPF Cost-10
ethernet0/1
172.18.8.8/30
OSPF Cost-10
loopback.1
172.18.8.43
loopback.1
172.18.8.42
ethernet2/2-HA
ethernet2/3-HA