Juniper Networks SRX Series Services Gateways, J Series Services Routers, J2320, J4350, SSG5 VPN Network Configuration Example

Juniper Networks SRX Series Services Gateways, J Series Services Routers, J2320, J4350, SSG5 VPN Network Configuration Example

Below you will find brief information for VPN SRX Series Services Gateways, VPN J Series Services Routers, VPN SSG5, VPN J Series J2320, VPN J Series J4350. This document describes next-hop tunnel binding and provides a step-by-step example for configuring a hub-and-spoke VPN using route-based VPNs and multipoint interfaces.

advertisement

Assistant Bot

Need help? Our chatbot has already read the manual and is ready to assist you. Feel free to ask any questions about the device, but providing details will make the conversation more productive.

VPN SRX Series Services Gateways, J Series Services Routers, SSG5, J Series J2320, J4350 - Network Configuration Example | Manualzz
Network Configuration Example
Configuring, Verifying, and Troubleshooting
Hub-and-Spoke VPNs Using Next-Hop Tunnel
Binding
Published: 2014-01-10
Copyright © 2014, Juniper Networks, Inc.
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United
States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other
trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify,
transfer, or otherwise revise this publication without notice.
Network Configuration Example Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
NCE0021
Copyright © 2014, Juniper Networks, Inc.
All rights reserved.
The information in this document is current as of the date on the title page.
YEAR 2000 NOTICE
Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the
year 2038. However, the NTP application is known to have some difficulty in the year 2036.
END USER LICENSE AGREEMENT
The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks
software. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted at
http://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditions of
that EULA.
ii
Copyright © 2014, Juniper Networks, Inc.
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding Overview . . . . . . . . . . . . . . 1
Fundamentals of Hub-and-Spoke VPNs in Junos OS . . . . . . . . . . . . . . . . . . . . 1
Next-Hop Tunnel Binding Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Understanding Route-to-Tunnel Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Example: Configuring Hub-and-Spoke VPNs using Next-Hop Tunnel Binding . . . . 4
Verifying Hub-and-Spoke VPN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Verifying Configuration of the Hub (Device in Corporate Office) . . . . . . . . . . 35
Verifying Configuration of the Spoke (Device in Westford Office) . . . . . . . . . 39
Copyright © 2014, Juniper Networks, Inc.
iii
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
iv
Copyright © 2014, Juniper Networks, Inc.
Introduction
This document describes next-hop tunnel binding and provides a step-by-step example
for configuring a hub-and-spoke VPN using route-based VPNs and multipoint interfaces.
It is intended for network design and security engineers, as well as anyone who requires
secure connectivity over public networks.
Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding Overview
This topic includes the following sections:
•
Fundamentals of Hub-and-Spoke VPNs in Junos OS on page 1
•
Next-Hop Tunnel Binding Overview on page 1
•
Understanding Route-to-Tunnel Mapping on page 2
Fundamentals of Hub-and-Spoke VPNs in Junos OS
The Juniper Networks Junos operating system (Junos OS) provides the following features:
•
Powerful operating system with rich IP services tool kit
•
IP dependability and security to ensure an efficient and predictable IP infrastructure
•
Enhanced security and virtual private network (VPN) capabilities from Juniper Networks
Firewall/IP Security (IPsec) VPN Platforms, including the Secure Services Gateway
(SSG) product family
A multipoint interface is commonly used for hub-and-spoke environments. The “Example:
Configuring Hub-and-Spoke VPNs using Next-Hop Tunnel Binding” on page 4 uses
route-based VPNs from a central hub device to multiple spoke devices. Junos OS does
not support a multipoint topology with policy-based VPNs.
Next-Hop Tunnel Binding Overview
You can implement a hub-and-spoke VPN topology by using the route-based VPN
concept in many ways. One way of implementing a hub-and-spoke VPN topology is to
configure a separate secure tunnel logical interface (st0) for every spoke site. However,
if a device has many associated peer devices, then the increased number of required
interfaces can be a concern from the standpoint of scaling and management.
For example, the following limitation applies to:
•
SSG platform – A maximum number of tunnel interfaces can be configured for the
platform.
•
Junos OS device – A maximum number of logical interface units can be configured for
the platform.
Junos OS supports the multipoint secure tunnel interfaces with the next-hop tunnel
binding (NHTB) feature for easier management and scalability. NHTB enables a device
to bind multiple IPsec security associations (SAs) to a single secure tunnel interface.
Copyright © 2014, Juniper Networks, Inc.
1
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
In the example:
•
The secure tunnel interface operates as a point-to-point link by default.
•
The Junos OS hub device is configured with the st0 interface as a multipoint interface
type in the st0 unit hierarchy. You need to configure the multipoint interface only on
the hub site; the spokes might continue to use the default point-to-point mode.
•
The Junos OS device binds multiple IPsec VPN tunnels to a single st0 interface unit.
•
The Junos OS device links a specific destination to a specific IPsec tunnel bound to the
same st0 interface, by using the following two tables:
•
•
Inet.0 route table
•
NHTB table
The Junos OS device maps the next-hop IP address specified in the route table entry
to a particular VPN tunnel specified in the NHTB table. With this feature, a single st0
interface can support many VPN tunnels.
The maximum number of IPsec tunnels is not limited by the number of st0 interfaces
that you can create, but is limited by either of the following factors (whichever is lower):
•
Route table capacity
•
Maximum number of dedicated IPsec tunnels allowed
To see the maximum route and tunnel capacities for your platform, refer to the relevant
product data sheet.
Understanding Route-to-Tunnel Mapping
To manage the traffic among multiple IPsec VPN tunnels bound to the same st0 interface,
the security device maps the next-hop gateway IP address specified in the route table
to a particular IPsec tunnel name. This scenario is explained in this section with reference
to Figure 1 on page 3.
The following settings are assumed for the local security device and remote VPN peer
devices:
•
•
2
Local security device
•
A local security device with multiple IPsec VPNs bound to a single secure tunnel
interface (st0) is in subnet 10.1.1.0/24.
•
A trusted LAN interface is in subnet 10.10.10.0/24.
•
The st0.0 logical interface is configured in multipoint mode.
Remote VPN peer settings
•
The remote VPN peers with fixed st0.0 logical interface IP addresses are all within
the same 10.1.1.0/24 subnet as the local device st0 interface.
•
The remote trusted subnets are 10.20.10.0/24, 10.30.10.0/24, and 10.40.10.0/24.
•
The st0.0 logical interface is configured in point-to-point mode.
Copyright © 2014, Juniper Networks, Inc.
Figure 1 on page 3 shows the local device routing traffic sent from 10.10.10.10 to
10.30.10.10 through the st0.0 interface and then routing the traffic through VPN2.
Figure 1: NHTB Routes and Table Entries
st0.0
10.1.1.2
J2320
VPN1
st0.0
10.1.1.1
10.20.10.0/24
Trust zone LAN
st0.0
10.1.1.3
10.10.10.0/24
10.30.10.0/24
J2320
J2320
Trust zone LAN
VPN2
10.10.10.10
10.30.10.10
st0.0
10.1.1.4
VPN3
J2320
10.40.10.0/24
Trust zone LAN
g040514
Trust zone LAN
Table 1 on page 3 shows the mapping of entries in the route table to the entries in the
NHTB table.
Table 1: Mapping of Route Table Entries and NHTB Table Entries
Route Table
Next-Hop Tunnel Binding Table
IP Prefix
Next Hop
Interface
Next Hop
Interface
IPsec
VPN
Flag
10.20.10.0/24
10.1.1.2
st0.0
–>
10.1.1.2
st0.0
VPN1
static
10.30.10.0/24
10.1.1.3
st0.0
–>
10.1.1.3
st0.0
VPN2
static
10.40.10.0/24
10.1.1.4
st0.0
–>
10.1.1.4
st0.0
VPN3
static
The following is an explanation of the scenario in Figure 1 on page 3 and in
Table 1 on page 3:
•
You can use a dynamic routing protocol (for example, OSPF) to automatically populate
the route table, or you can add static routes manually. The next-hop IP address is the
IP address of the remote peer’s st0 interface.
•
You can use one of the following options for an NHTB table:
•
Enter the next-hop addresses manually and bind them to the appropriate IPsec VPN
tunnel.
To link the route table and NHTB table, you must enter the same IP address as the
next hop, along with the appropriate IPsec VPN name in the NHTB table.
•
Allow the Junos OS device to automatically acquire the next-hop address from the
remote peer and exchange st0 interface addresses during Phase 2 negotiations using
the NOTIFY_NS_NHTB_INFORM message (value 40001). Note that this functionality
is applicable only if both peers are Juniper Networks devices.
Copyright © 2014, Juniper Networks, Inc.
3
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
•
As listed in Table 1 on page 3, the IP addresses for the next hop in the route table
(which is also the same next-hop IP in the NHTB table) is the st0 interface IP address
of the remote peer site. This next hop links the route, and consequently the st0 interface
specified in the route, to a particular IPsec VPN tunnel.
NOTE: The multipoint st0 interface goes down when all interface virtual
circuits are down and comes up when at least one interface virtual circuits
is up.
Related
Documentation
•
Example: Configuring Hub-and-Spoke VPNs using Next-Hop Tunnel Binding on page 4
•
Verifying Hub-and-Spoke VPN Configuration on page 35
Example: Configuring Hub-and-Spoke VPNs using Next-Hop Tunnel Binding
This example shows how to configure, verify, and troubleshoot hub-and-spoke VPNs
using next-hop tunnel binding.
NOTE:
•
Configuration and troubleshooting details of route-based virtual private
networks (VPNs) and other Junos OS- specific documents are available
at the Juniper Networks Knowledge Base at http://kb.juniper.net.
•
For more information about the concepts of NHTB, route-based VPNs, and
interface types, refer to the complete documentation for Junos OS available
at http://www.juniper.net/techpubs/.
•
For more information about VPN configuration and troubleshooting, see
KB10182 (http://kb.juniper.net/KB10182) available at the Juniper Networks
Knowledge Base.
This topic includes the following sections:
•
Requirements on page 4
•
Overview and Topology on page 5
•
Basic Configuration Steps for Hub and Spoke Devices on page 6
•
Example: Configuring the Multipoint VPN Configuration with Next-Hop Tunnel
Binding on page 8
•
Verification on page 17
•
Troubleshooting Hub-and-Spoke VPNs on page 24
Requirements
This example uses the following hardware and software components:
•
4
Junos OS Release 9.5 or later
Copyright © 2014, Juniper Networks, Inc.
•
Juniper Networks SRX Series Services Gateways or J Series Services Routers
NOTE: This configuration example has been tested using the software release
listed and is assumed to work on all later releases.
Overview and Topology
Figure 2 on page 5 shows the network topology used in this configuration example.
Figure 2: Network Topology
J4350 Corporate Office
Sunnyvale SSG5
SSG5
POWER
STATUS
J4350
AUX
CONSOLE
0/0
0/1
0/2
0/3
0/4
0/5
0/6
AUX
st0.0
10.11.11.10/24
zone: vpn
ge-0/0/0.0
10.10.10.1/24
zone: trust
tunnel.1
10.11.11.11/24
zone: vpn
e0/6
192.168.168.1/24
zone: trust
e0/0
2.2.2.2/30
zone: untrust
ge-0/0/3.0
1.1.1.2/30
zone: untrust
ge-0/0/0.0
3.3.3.2/30
zone: untrust
192.168.168.10/24
Westford J2320
J2320
st0.0
10.11.11.12/24
zone: vpn
ge-0/0/3.0
192.168.178.1/24
zone: trust
g040513
192.168.178.10/24
Clear traffic
VPN traffic
Required Settings
This example assumes the following settings:
•
The internal LAN interface of the hub device (Corporate office) is ge-0/0/0.0 in zone
trust and has a private IP subnet.
•
The Internet interface of the hub device (Corporate office) is ge-0/0/3.0 in zone untrust
and has a public IP subnet.
•
The internal LAN interface of the spoke device (Westford office) is ge-0/0/3.0 in zone
trust and has a private IP subnet.
•
The Internet interface of the spoke device (Westford office) is ge-0/0/0.0 in zone
untrust and has a public IP subnet.
Copyright © 2014, Juniper Networks, Inc.
5
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
NOTE: This example shows the configuration and verification of a
multipoint interface in a hub-and spoke topology with two spokes. This
example uses the following spokes as shown in Figure 2 on page 5:
•
Spoke - Device in Westford office, which is a Junos OS device running
Junos OS Release 9.5 or later.
•
Spoke - Device in Sunnyvale office, which is a Juniper Networks SSG5
Secure Services Gateway running ScreenOS 5.4.0 or later.
You can easily include additional spokes by duplicating the configuration
from any existing spokes, changing IP addresses as needed, and adding
any additional static routes for the new local LANs.
•
The secure tunnel interface is st0.0 for the devices in the Corporate office and in the
Westford office. The tunnels are configured in the vpn zone. This setting allows you to
configure unique policies specifically for tunnel (encrypted) traffic, while maintaining
unique policies for clear (non-encrypted) traffic.
•
All st0 interfaces of all peer devices have IP addresses configured within the same
logical subnet. Configuring all peer tunnel interface IP addresses within the same logical
subnet is recommended, but not mandatory. However, if you have configured OSPF
with a point-to-multipoint link, then you must configure all peer tunnel interface IP
addresses within the same logical subnet.
•
Traffic is allowed in both directions from all remote offices (spokes) to the corporate
LAN (hub). Traffic is also allowed from spoke to spoke. However, you can pass the
traffic from one spoke to the other spoke only by first routing the traffic through the
hub.
•
A static NHTB entry is not required between the devices.
•
The SSG5 has already been configured with the correct information for this example.
Basic Configuration Steps for Hub and Spoke Devices
This topic includes the following sections:
•
Basic Steps to Configure the Hub (Device in Corporate Office) on page 6
•
Basic Steps to Configure the Spoke (Device in Westford Office) on page 8
Basic Steps to Configure the Hub (Device in Corporate Office)
Step-by-Step
Procedure
6
The basic steps to configure the hub (device in the Corporate office) are:
1.
Configure the IP addresses for the ge-0/0/0.0, ge-0/0/3.0, and st0.0 interfaces.
2.
Configure the default route to the Internet next hop, and configure static routes for
each remote office LAN.
Copyright © 2014, Juniper Networks, Inc.
NOTE: Optionally, you can use a dynamic routing protocol such as OSPF
to configure the routes automatically, but that is beyond the scope of
this example.
3.
Configure the security zones, and bind the interfaces to the appropriate zones.
Ensure that you have enabled the necessary host-inbound services on the interfaces
or the zone. In this example, you must enable the Internet Key Exchange (IKE) service
on either the ge-0/0/3 interface or the zone untrust.
4.
Configure address book entries for each zone.
5.
Configure Phase 1 (IKE) gateway settings for both remote offices.
This example uses a standard proposal set. However, you can create a different
proposal set, if required.
6.
Configure Phase 2 IP Security- virtual private network (IPsec VPN) settings for both
remote offices.
Optionally, you can also configure the VPN monitor settings, if required. This example
uses a standard proposal set and Perfect Forward Secrecy (PFS) group 2. However,
you can create a different proposal set, if required.
7.
Bind the st0.0 logical interface to the IPsec VPN.
8.
Configure the st0.0 logical interface for a multipoint interface.
9.
Configure the NHTB entries for any non-Junos OS spoke sites.
NOTE: If you are establishing a VPN between two Junos OS devices,
then it is not necessary to configure an NHTB because the hub device
can obtain the NHTB entry automatically during Phase 2 negotiations.
However, if you have configured the VPN to establish the tunnel when
data traffic flows, then the hub site cannot initiate the VPN. Without an
NHTB entry, the route for that remote peer will not be in the active state.
In this scenario, either the tunnel must always be initiated from the
spoke, or the hub device must have the establish-tunnel field configured
to be activated immediately after the configuration changes are
committed.
10.
Configure security policies to permit remote office traffic into the host LAN
(Corporate office) and vice versa.
11.
Configure an outgoing trust to untrust permit-all policy with source Network Address
Translation (NAT) for non-encrypted Internet traffic.
12.
Configure an intrazone policy in zone vpn to allow spokes to communicate with
each other.
Copyright © 2014, Juniper Networks, Inc.
7
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
Intrazone traffic is where the ingress (incoming) and egress (outgoing) traffic pass
through the same zone. By default intrazone traffic is denied.
13.
Configure TCP maximum segment size (MSS) for IPsec traffic to eliminate the
possibility of fragmented TCP traffic.
This step reduces the resource usage on the device.
Basic Steps to Configure the Spoke (Device in Westford Office)
Step-by-Step
Procedure
The basic steps to configure the spoke (device in the Westford office) are:
1.
Configure the IP addresses for the ge-0/0/0.0, ge-0/0/3.0 and st0.0 logical
interfaces.
2.
Configure the default route to the Internet next hop, and also configure a static
route for the Corporate Office LAN.
3.
Configure the security zones and bind the interfaces to the appropriate zones.
Ensure that the necessary host-inbound services are enabled on the interfaces or
the zone. In this example, you must enable IKE service on the ge-0/0/0 interface
or the zone untrust.
4.
Configure address book entries for each zone.
5.
Configure Phase 1 (IKE) gateway settings.
This example uses a standard proposal set.
6.
Configure Phase 2 (IPsec) VPN settings.
7.
Bind the st0.0 interface to the IPsec VPN.
This example uses a standard proposal set and PFS group 2.
8.
Configure security policies to permit remote office (Westford office) traffic into the
host LAN (Corporate office) and vice versa.
9.
Configure an outgoing trust to untrust permit-all policy with source NAT for
non-encrypted Internet traffic
10.
Configure the TCP-MSS for IPsec traffic to eliminate the possibility of fragmented
TCP traffic and to reduce the resource usage on the device.
Example: Configuring the Multipoint VPN Configuration with Next-Hop Tunnel Binding
This topic includes the following sections:
•
Example: Configuring the Hub (Corporate Office) on page 8
•
Example: Configuring the Spoke (Westford Office) on page 13
Example: Configuring the Hub (Corporate Office)
Step-by-Step
Procedure
8
1.
Configure the IP addresses for the private LAN, the public Internet, and the secure
tunnel (st0) interfaces.
Copyright © 2014, Juniper Networks, Inc.
NOTE: Junos OS uses the concept of units for the logical component
of an interface. This example uses unit 0 and family inet (IPv4). We
recommend configuring st0 interface IP addresses for all peer devices
within the same logical subnet.
[edit]
user@hub# set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.1/24
user@hub# set interfaces ge-0/0/3 unit 0 family inet address 1.1.1.2/30
user@hub# set interfaces st0 unit 0 family inet address 10.11.11.10/24
2.
Configure a default route and other static routes for tunnel traffic.
For a static route, you can normally specify the gateway IP address as the next-hop.
For route-based VPNs with a multipoint interface, specify the remote peer st0
interface IP address as the next hop.
[edit]
user@hub# set routing-options static route 0.0.0.0/0 next-hop 1.1.1.1
user@hub# set routing-options static route 192.168.168.0/24 next-hop 10.11.11.11
user@hub# set routing-options static route 192.168.178.0/24 next-hop 10.11.11.12
3.
Configure the security zones, and assign interfaces to the zones.
Creating a unique zone for tunnel traffic enables you to create a specific set of
policies for VPN traffic while maintaining a separate set of policies for non-VPN
traffic. Also, you can create deny policies to prevent certain hosts from accessing
the VPN.
NOTE:
No additional security policies are required if:
•
You terminate the st0 interface in the same zone as the trusted LAN.
•
A policy is available that allows intrazone traffic in the same zone as
the trusted LAN.
[edit]
user@hub# set security zones security-zone trust interfaces ge-0/0/0.0
user@hub# set security zones security-zone untrust interfaces ge-0/0/3.0
user@hub# set security zones security-zone vpn interfaces st0.0
4.
Configure host-inbound services for each zone.
Host-inbound services are for traffic destined for the Junos OS device. These settings
include but are not limited to FTP, HTTP, HTTPS, IKE, ping, rlogin, RSH, SNMP, SSH,
Telnet, TFTP, and traceroute.
In this example, assume that all host-inbound services should be allowed from zone
trust. For security reasons, allow IKE only on the Internet-facing zone untrust, which
is required for IKE negotiations to occur. However, you can enable other individual
services, such as services for management, or services for troubleshooting, if required.
Copyright © 2014, Juniper Networks, Inc.
9
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
[edit]
user@hub# set security zones security-zone trust host-inbound-traffic
system-services all
user@hub# set security zones security-zone untrust host-inbound-traffic
system-services ike
5.
Configure the address book entries for each zone.
In this example, use address-book object names such as local-net, sunnyvale-net,
and westford-net. Additional address book entries can added for any additional
spokes, if required.
[edit]
user@hub# set security zones security-zone trust address-book address local-net
10.10.10.0/24
user@hub# set security zones security-zone vpn address-book address sunnyvale-net
192.168.168.0/24
user@hub# set security zones security-zone vpn address-book address westford-net
192.168.178.0/24
6.
Configure the IKE policy for main mode, predefined standard proposal set, and
preshared key.
In this example, use the standard proposal set, which includes the
esp-group2-3des-sha1 and esp-group2- aes128-sha1 proposals. However, you can
create a unique proposal and then specify it in the IKE policy in accordance with
your corporate security policy.
The same IKE policy can be used for all spoke VPNs, if needed.
[edit]
user@hub# set security ike policy ike-policy1 mode main
user@hub# set security ike policy ike-policy1 proposal-set standard
user@hub# set security ike policy ike-policy1 pre-shared-key ascii-text "secretkey"
7.
Configure the spoke IKE gateways (Phase 1) with a peer IP address, an IKE policy,
and an outgoing interface.
A remote IKE peer can be identified by:
•
IP address
•
Fully qualified domain name / user-fully qualified domain name (FQDN/U-FQDN)
•
ASN1-DN (public key infrastructure [PKI] certificates)
In this example, identify the peer by IP address. Therefore, the gateway address
should be the remote peer’s public IP address. You must also specify the correct
external interface or peer ID to properly identify the IKE gateway during Phase 1
setup.
[edit]
user@hub# set security ike gateway westford-gate ike-policy ike-policy1
user@hub# set security ike gateway westford-gate address 3.3.3.2
user@hub# set security ike gateway westford-gate external-interface ge-0/0/3.0
user@hub# set security ike gateway sunnyvale-gate ike-policy ike-policy1
user@hub# set security ike gateway sunnyvale-gate address 2.2.2.2
user@hub# set security ike gateway sunnyvale-gate external-interface ge-0/0/3.0
10
Copyright © 2014, Juniper Networks, Inc.
8.
Configure the IPsec policy.
In this example, use the standard proposal set, which includes the
esp-group2-3des-sha1 and esp-group2- aes128-sha1 proposals. However, you can
create a unique proposal and then specify it in the IPsec policy, if needed.
[edit]
user@hub# set security ipsec policy vpn-policy1 proposal-set standard
user@hub# set security ipsec policy vpn-policy1 perfect-forward-secrecy keys group2
9.
Configure the IPsec VPN with an IKE gateway and IPsec policy, and bind them to
the same st0 interface.
Binding an st0 interface indicates that the VPN is a route-based VPN.
You must specify an st0 interface to successfully complete Phase 2 negotiations
for route-based VPNs.
[edit]
user@hub# set security ipsec vpn westford-vpn ike gateway westford-gate
user@hub# set security ipsec vpn westford-vpn ike ipsec-policy vpn-policy1
user@hub# set security ipsec vpn westford-vpn bind-interface st0.0
user@hub# set security ipsec vpn sunnyvale-vpn ike gateway sunnyvale-gate
user@hub# set security ipsec vpn sunnyvale-vpn ike ipsec-policy vpn-policy1
user@hub# set security ipsec vpn sunnyvale-vpn bind-interface st0.0
10.
Configure the st0 interface as multipoint interface, then add a static NHTB entry
for the spoke in the Sunnyvale office, which is an SSG device running ScreenOS.
Because the spoke in the Sunnyvale office is not a Junos OS device, a static NHTB
entry is required. You can optionally configure a static NHTB entry for another spoke
in the Westford office, if required.
[edit]
user@hub# set interfaces st0 unit 0 multipoint
user@hub# set interfaces st0 unit 0 family inet next-hop-tunnel 10.11.11.11 ipsec-vpn
sunnyvale-vpn
11.
Configure bidirectional security policies for tunnel traffic for all spokes.
In this example, a security policy permits traffic in one direction, but it also allows
all reply traffic without the need for a reverse direction policy. However, since traffic
can be initiated from either direction, bidirectional policies are required.
NOTE:
• If required, more granular policies can be created to permit/deny
certain traffic.
Copyright © 2014, Juniper Networks, Inc.
•
Because the policies are regular non-tunnel policies, they do not
specify the IPsec profile.
•
Source NAT rules can be enabled if desired, but that is beyond the
scope of this example.
•
If more spoke sites are added, you can add the additional
source/destination match entries for the new spoke local LANs to
permit the traffic.
11
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
[edit security policies from-zone trust to-zone VPN]
user@hub# set policy local-to-spokes match source-address local-net
user@hub# set policy local-to-spokes match destination-address sunnyvale-net
user@hub# set policy local-to-spokes match destination-address westford-net
user@hub# set policy local-to-spokes match application any
user@hub# set policy local-to-spokes then permit
[edit security policies from-zone vpn to-zone trust]
user@hub# set policy spokes-to-local match source-address sunnyvale-net
user@hub# set policy spokes-to-local match source-address westford-net
user@hub# set policy spokes-to-local match destination-address local-net
user@hub# set policy spokes-to-local match application any
user@hub# set policy spokes-to-local then permit
12.
Configure a source NAT rule and a security policy for Internet traffic.
A security policy is required to permit all traffic from zone trust to zone untrust.
The device uses the specified source-nat interface, and translates the source IP
address and port for outgoing traffic, using the IP address of the egress interface
as the source IP address and using a random higher port for the source port. If
required, you can create more granular policies to permit or deny certain traffic.
[edit security nat source rule-set nat-out]
user@hub# set from zone trust
user@hub# set to zone untrust
user@hub# set rule interface-nat match source-address 192.168.10.0/24
user@hub# set rule interface-nat match destination-address 0.0.0.0/0
user@hub# set rule interface-nat then source-nat interface
[edit security policies from-zone trust to-zone untrust]
user@hub# set policy any-permit match source-address any
user@hub# set policy any-permit match destination-address any
user@hub# set policy any-permit match application any
user@hub# set policy any-permit then permit
13.
Configure an intrazone policy in the vpn zone for spoke-to-spoke traffic.
This policy permits all traffic from zone vpn to zone vpn, which is intra-zone traffic.
You must configure an intra-zone policy to allow traffic through one spoke to another
without dropping any traffic. If required, you can create more granular policies to
permit or deny certain IP prefixes or protocols.
[edit security policies from-zone vpn to-zone vpn]
user@hub# set policy spoke-to-spoke match source-address any
user@hub# set policy spoke-to-spoke match destination-address any
user@hub# set policy spoke-to-spoke match application any
user@hub# set policy spoke-to-spoke then permit
14.
Configure the TCP-maximum segment size (tcp-mss) to eliminate the fragmentation
of TCP traffic across the tunnel.
The TCP MSS is negotiated as part of the TCP three-way handshake. It limits the
maximum size of a TCP segment to accommodate the maximum transmission unit
(MTU) limits on a network. This is very important for VPN traffic, because the IPsec
encapsulation overhead, along with the IP and Frame overhead, can cause the
resulting ESP packet to exceed the MTU of the physical interface, resulting in
12
Copyright © 2014, Juniper Networks, Inc.
fragmentation. Fragmentation increases the bandwidth and device resource usage,
and should always be avoided. The recommended value for TCM MSS is 1350 for
most Ethernet-based networks with an MTU of 1500 or higher. This value might
need to be altered if any device in the path has a lower MTU value or if there is any
added overhead such as PPP, or Frame Relay. As a general rule, you might need to
experiment with different TCP MSS values to obtain optimal performance.
[edit]
user@hub# set security flow tcp-mss ipsec-vpn mss 1350
Example: Configuring the Spoke (Westford Office)
Step-by-Step
Procedure
1.
Configure the IP addresses for the private LAN, public Internet, and the secure tunnel
interfaces (st0).
NOTE: The steps for configuring the spoke device (Westford office) are
similar to the steps for configuring the hub device (Corporate office).
NOTE: We recommend configuring IP addresses for all peer-devices
within the same logical subnet (for st0 interfaces). Thus, the spoke
device (Westford office) st0 interface is configured within the same
subnet as the hub device (Corporate office) st0 interface.
[edit]
user@spoke# set interfaces ge-0/0/0 unit 0 family inet address 3.3.3.2/30
user@spoke# set interfaces ge-0/0/3 unit 0 family inet address 192.168.178.1/24
user@spoke# set interfaces st0 unit 0 family inet address 10.11.11.12/24
2.
Configure a default route and other static routes for the tunnel traffic.
Because the device in the Westford office is in a spoke site, the st0 interface type
is point-to-point. Therefore, while configuring the next-hop option, you can specify
the IP address of the st0 interface on the hub site, or you can specify st0.0 as the
next hop.
[edit]
user@spoke# set routing-options static route 0.0.0.0/0 next-hop 1.1.1.1
user@spoke# set routing-options static route 10.10.10.0/24 next-hop 10.11.11.10
user@spoke# set routing-options static route 192.168.168.0/24 next-hop 10.11.11.10
3.
Configure the security zones, and assign interfaces to the security zones.
[edit]
user@spoke# set security zones security-zone trust interfaces ge-0/0/3.0
user@spoke# set security zones security-zone untrust interfaces ge-0/0/0.0
user@spoke# set security zones security-zone vpn interfaces st0.0
4.
Configure the host-inbound services for each zone.
Copyright © 2014, Juniper Networks, Inc.
13
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
The variables configured in this step are the same for both the spoke device
(Westford office) and the hub device (Corporate office).
[edit]
user@spoke# set security zones security-zone trust host-inbound-traffic
system-services all
user@spoke# set security zones security-zone untrust host-inbound-traffic
system-services ike
5.
Configure the address book entries for each zone.
In this example, use address-book object names such as local-net, sunnyvale-net,
and westford-net.
You can add the additional spoke devices by:
•
Creating an additional address book entry for each local LAN on the spoke
•
Creating a single address book entry that encompasses all the local LANs on the
spoke
[edit]
user@spoke# set security zones security-zone trust address-book address local-net
192.168.178.0/24
user@spoke# set security zones security-zone vpn address-book address corp-net
10.10.10.0/24
user@spoke# set security zones security-zone vpn address-book address
sunnyvale-net 192.168.168.0/24
6.
Configure the IKE policy for main mode, predefined standard proposal set, and
preshared key.
NOTE: The variables (proposal set and preshared key) configured in
this step are the same for both the spoke device (Westford office) and
the hub device (Corporate office).
[edit]
user@spoke# set security ike policy ike-policy1 mode main
user@spoke# set security ike policy ike-policy1 proposal-set standard
user@spoke# set security ike policy ike-policy1 pre-shared-key ascii-text "secretkey"
7.
Configure the spoke IKE gateways (Phase 1) with a peer IP address, an IKE policy,
and an outgoing interface.
NOTE:
The variables configured in this step are the same for both the spoke
device (Westford office) and the hub device (Corporate office), except
as follows:
14
•
The external interface for the spoke device is ge-0/0/0.0.
•
The peer address in the spoke device is the IP address of the hub
device.
Copyright © 2014, Juniper Networks, Inc.
[edit]
user@spoke# set security ike gateway corp-gate address 1.1.1.2
user@spoke# set security ike gateway corp-gate ike-policy ike-policy1
user@spoke# set security ike gateway corp-gate external-interface ge-0/0/0.0
8.
Configure the IPsec policy for the standard proposal set.
NOTE: The variables configured in this step are the same for both the
spoke device (Westford office) and the hub device (Corporate office).
[edit]
user@spoke# set security ipsec policy vpn-policy1 proposal-set standard
user@spoke# set security ipsec policy vpn-policy1 perfect-forward-secrecy keys
group2
9.
Configure the IPsec VPN with an IKE gateway and IPsec policy, and bind them to
the same st0 interface.
NOTE: The variables configured in this step are the same for both the
spoke device (Westford office) and the hub device (Corporate office).
[edit]
user@spoke# set security ipsec vpn corp-vpn ike gateway corp-gate
user@spoke# set security ipsec vpn corp-vpn ike ipsec-policy vpn-policy1
user@spoke# set security ipsec vpn corp-vpn bind-interface st0.0
10.
Configure bidirectional security policies for tunnel traffic.
NOTE: The variables configured in this step are the same for both the
spoke device (Westford office) and the hub device (Corporate office),
except that the remote subnets used in the hub device local LAN and
in the other spoke device local LAN are different.
[edit security policies from-zone trust to-zone vpn]
user@spoke# set policy to-corp match source-address local-net
user@spoke# set policy to-corp match destination-address corp-net
user@spoke# set policy to-corp match destination-address sunnyvale-net
user@spoke# set policy to-corp match application any
user@spoke# set policy to-corp then permit
[edit security policies from-zone vpn to-zone trust]
user@spoke# set policy from-corp match source-address corp-net
user@spoke# set policy from-corp match source-address sunnyvale-net
user@spoke# set policy from-corp match destination-address local-net
user@spoke# set policy from-corp match application any
user@spoke# set policy from-corp then permit
11.
Configure a source NAT rule and a security policy for Internet traffic.
Copyright © 2014, Juniper Networks, Inc.
15
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
NOTE: The variables configured in this step are the same for both the
spoke device (Westford office) and the hub device (Corporate office).
[edit security nat source rule-set nat-out]
user@spoke# set from zone trust
user@spoke# set to zone untrust
user@spoke# set rule interface-nat match source-address 192.168.178.0/24
user@spoke# set rule interface-nat match destination-address 0.0.0.0/0
user@spoke# set rule interface-nat then source-nat interface
[edit security policies from-zone trust to-zone untrust]
user@spoke# set policy any-permit match source-address any
user@spoke# set policy any-permit match destination-address any
user@spoke# set policy any-permit match application any
user@spoke# set policy any-permit then permit
12.
Configure the tcp-mss to eliminate fragmentation of TCP traffic across the tunnel.
NOTE: The values used in this step are the same for both the spoke
device (Westford office) and the hub device (Corporate office).
[edit]
user@spoke# set security flow tcp-mss ipsec-vpn mss 1350
13.
This is the SSG5 portion of the configuration and is provided for your reference.
The focus of this example is the configuration and troubleshooting of the Junos OS
device. For the purpose of completing the network shown in Figure 2 on page 5, a
sample of the relevant configurations is provided for an SSG5 device.
However, the concepts for configuring policy-based VPNs for Juniper Networks
Firewall/VPN products are available in the Concepts and Examples (C&E) guides.
For more information, see the Concepts & Examples ScreenOS Reference Guide at
http://www.juniper.net/techpubs/software/screenos/ .
set zone name "VPN"
set interface ethernet0/6 zone "Trust"
set interface ethernet0/0 zone "Untrust"
set interface "tunnel.1" zone "VPN"
set interface ethernet0/6 ip 192.168.168.1/24
set interface ethernet0/6 route
set interface ethernet0/0 ip 2.2.2.2/30
set interface ethernet0/0 route
set interface tunnel.1 ip 10.11.11.11/24
set flow tcp-mss 1350
set address "Trust" "sunnyvale-net" 192.168.168.0 255.255.255.0
set address "VPN" "corp-net" 10.10.10.0 255.255.255.0
set address "VPN" "westford-net" 192.168.178.0 255.255.255.0
set ike gateway "corp-ike" address 1.1.1.2 Main outgoing-interface ethernet0/0
preshare "secretkey" sec-level standard
16
Copyright © 2014, Juniper Networks, Inc.
set vpn "corp-vpn" gateway "corp-ike" replay tunnel idletime 0 sec-level standard
set vpn "corp-vpn" bind interface tunnel.1
set policy id 1 from "Trust" to "Untrust" "ANY" "ANY" "ANY" nat src permit
set policy id 2 from "Trust" to "VPN" "sunnyvale-net" "corp-net" "ANY" permit
set policy id 2
set dst-address "westford-net"
set policy id 3 from "VPN" to "Trust" "corp-net" "sunnyvale-net" "ANY" permit
set policy id 3
set src-address "westford-net"
set route 10.10.10.0/24 interface tunnel.1
set route 192.168.178.0/24 interface tunnel.1
set route 0.0.0.0/0 interface ethernet0/0 gateway 2.2.2.1
Verification
Verify that the hub-and-spoke VPN using next-hop tunnel binding is working by perform
the following steps:
•
Confirming VPN Status on page 17
•
Obtaining Peer Device’s Individual Index Numbers on page 18
•
Viewing IPsec (Phase 2) Security Associations on page 19
•
Display IPsec Security Association Details on page 20
•
Confirming Next-Hop Tunnel Bindings on page 21
•
Confirming Static Routes for Remote Peer Local LANs on page 22
•
Checking Statistics and Errors for an IPsec SA on page 23
•
Testing Traffic Flow Across the VPN on page 23
•
Confirming the Connectivity on page 24
Confirming VPN Status
Purpose
Action
Confirm VPN status by checking the status of any IKE Phase 1 security associations.
Use the following command on the hub device (in the Corporate office):
user@hub> show security ike security-associations
Index Remote Address State Initiator cookie Responder cookie Mode
6 3.3.3.2 UP 94906ae2263bbd8e 1c35e4c3fc54d6d3 Main
7 2.2.2.2 UP 7e7a1c0367dfe73c f284221c656a5fbc Main
Meaning
The output indicates that:
•
•
The remote peers (spokes) have the following IP addresses:
•
3.3.3.2 (spoke device at the Westford office)
•
2.2.2.2 (spoke device at the Sunnyvale office)
The state showing UP for both remote peers indicates the successful association of
Phase 1 establishment.
Copyright © 2014, Juniper Networks, Inc.
17
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
•
The remote peer IP address, IKE policy, and external interfaces are all correct.
•
Incorrect output would indicate that:
•
The remote peer status as Down.
•
There are no IKE security associations.
•
Incorrect IKE policy parameters such as wrong Mode type (Aggressive or Main),
preshared keys, or Phase 1 proposals (all must match on both peers).
For more information, see “Troubleshooting Hub-and-Spoke VPNs” on page 24.
•
Incorrect external interface.
The external interface is invalid for receiving the IKE packets.
•
The next steps to perform are:
•
Check the configurations for PKI-related issues.
•
Check the kmd log for any other errors.
•
Run traceoptions to find the mismatch.
For more information, see “Troubleshooting Hub-and-Spoke VPNs” on page 24.
Obtaining Peer Device’s Individual Index Numbers
Purpose
Get details on the individual index numbers of the remote peer devices (spokes).
The Index number value is unique for each IKE SA for every remote peer.
18
Copyright © 2014, Juniper Networks, Inc.
Action
user@hub> show security ike security-associations index 6 detail
IKE peer 3.3.3.2, Index 6,
Role: Responder, State: UP
Initiator cookie: 94906ae2263bbd8e, Responder cookie: 1c35e4c3fc54d6d3
Exchange type: Main, Authentication method: Pre-shared-keys
Local: 1.1.1.2:500, Remote: 3.3.3.2:500
Lifetime: Expires in 3571 seconds
Algorithms:
Authentication : sha1
Encryption : 3des-cbc
Pseudo random function: hmac-sha1
Traffic statistics:
Input bytes : 1128
Output bytes : 988
Input packets: 6
Output packets: 5
Flags: Caller notification sent
IPsec security associations: 1 created, 0 deleted
Phase 2 negotiations in progress: 1
Negotiation type: Quick mode, Role: Responder, Message ID: 1350777248
Local: 1.1.1.2:500, Remote: 3.3.3.2:500
Local identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Flags: Caller notification sent, Waiting for done
Meaning
The output displays the details of the spoke (in the Westford office) SA, such as the
index, role (initiator or responder), status, exchange type, authentication method,
encryption algorithms, traffic statistics, Phase 2 negotiation status, and so on.
You can use the output data to:
•
Determine the role of the remote peer (spoke) device. Troubleshooting is easier when
the peer device has the responder role.
•
Obtain details regarding the authentication and encryption algorithms used.
•
Obtain the traffic statistics to verify the traffic flow in both directions.
•
Obtain the number of IPsec SAs created or in progress.
Viewing IPsec (Phase 2) Security Associations
Purpose
When IKE Phase 1 is confirmed, view the IPsec (Phase 2) security associations.
Copyright © 2014, Juniper Networks, Inc.
19
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
Action
user@hub> show security ipsec security-associations
total configured sa: 2
ID Gateway Port Algorithm SPI Life:sec/kb
<16384 2.2.2.2 500 ESP:3des/sha1 b2fc36f8
>16384 2.2.2.2 500 ESP:3des/sha1 5d73929e
total configured sa: 2
ID Gateway Port Algorithm SPI Life:sec/kb
<16385 3.3.3.2 500 ESP:3des/sha1 70f789c6
>16385 3.3.3.2 500 ESP:3des/sha1 80f4126d
Meaning
Mon vsys
3564/ unlim - 0
3564/ unlim - 0
Mon vsys
28756/unlim - 0
28756/unlim - 0
The output indicates the following:
•
There is a configured IPsec SA pair available. The port number 500 indicates that a
standard IKE port is used. Otherwise, it is Network Address Translation-Traversal
(NAT-T) port 4500, or a random high port number.
•
The security parameter index (SPI) is used for both directions. The lifetime or usage
limits of the SA are expressed either in seconds or in kilobytes. In the output,
28756/unlim for 3.3.3.2 (spoke in the Westford office) indicates that the Phase 2 lifetime
is set to expire in 28756 seconds and that there is no specified lifetime size.
NOTE: The Phase 2 lifetime might differ from the Phase 1 lifetime, because
Phase 2 is not dependent on Phase 1 after the VPN is up.
•
The Mon column refers to VPN monitoring status. A hyphen (-) in the Mon column
indicates that VPN monitoring is not enabled for this SA. If VPN monitoring is enabled,
then this field shows U (up) or D (down).
NOTE: For information about VPN monitoring, refer to the complete
documentation for Junos OS available at http://www.juniper.net/techpubs/
.
•
The virtual system (vsys) is zero, which is the default value.
•
The unique index value for each IPsec SA. (ID number)
Display IPsec Security Association Details
Purpose
Display the individual IPsec SA details identified by the index number for a remote peer
device (Westford office).
The index value is unique for each IPsec SA. You can view more details for a particular
SA by specifying the index value.
20
Copyright © 2014, Juniper Networks, Inc.
Action
user@hub> show security ipsec security-associations index 16385 detail
Virtual-system: Root
Local Gateway: 1.1.1.2, Remote Gateway: 3.3.3.2
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
DF-bit: clear
Direction: inbound, SPI: 1895270854, AUX-SPI: 0
Hard lifetime: Expires in 28729 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 28136 seconds
Mode: tunnel, Type: dynamic, State: installed, VPN Monitoring: Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
Anti-replay service: enabled, Replay window size: 32
Direction: outbound, SPI: 2163479149, AUX-SPI: 0
Hard lifetime: Expires in 28729 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 28136 seconds
Mode: tunnel, Type: dynamic, State: installed, VPN Monitoring: Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
Anti-replay service: enabled, Replay window size: 32
Meaning
The output displays the local identity and the remote identity.
Note that a proxy ID mismatch might cause Phase 2 completion to fail. If no IPsec SA is
listed, then confirm that the Phase 2 proposals, including the proxy ID settings, are correct
for both peers. In this example, for route-based VPNs, the default proxy ID is
local=0.0.0.0/0, remote=0.0.0.0/0, service=any.
NOTE:
•
You might have to specify unique proxy IDs for each IPsec SA if you use
multiple route-based VPNs from the same peer server’s IP address.
•
You might have to manually enter the proxy ID to match if you are using
applications from some third-party vendors.
•
You must specify st0 interface binding. Otherwise, Phase 2 might fail to
complete.
NOTE: If IPsec fails to complete, then check the kmd log or set traceoptions.
For more information, see “Troubleshooting Hub-and-Spoke VPNs” on
page 24.
Confirming Next-Hop Tunnel Bindings
Purpose
After Phase 2 is complete for all peers, confirm that the NHTB table is established
correctly.
Copyright © 2014, Juniper Networks, Inc.
21
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
To display the NHTB table, run the following command:
Action
Meaning
user@hub> show security ipsec next-hop-tunnels
Next-hop gateway interface IPsec VPN name Flag
10.11.11.11 st0.0 sunnyvale-vpn Static
10.11.11.12 st0.0 westford-vpn Auto
As in the network topology diagram in Figure 2 on page 5, the next-hop gateways are
the IP addresses for the st0 interfaces of all remote spoke peers. The next hop should
be associated with the correct IPsec VPN name. Without an NHTB entry, it is not possible
for the hub device to differentiate which IPsec VPN is associated with which next hop.
The flag can have one of the following options:
•
Static – The NHTB is manually configured in the st0.0 interface configurations, which
is required if the peer device is not running Junos OS.
•
Auto – The NHTB is not configured, but the entry was automatically populated into
the table during Phase 2 negotiations between two Junos OS devices.
In this example, the NHTB table is not available on any of the devices in the spoke sites.
This is because, from the spoke point of view, the st0 interface is still a point-to-point
link with only one IPsec VPN binding. Thus, if you use the show security ipsec
next-hop-tunnels command on any of the devices in the spoke site (Westford office),
you will not obtain any output.
Confirming Static Routes for Remote Peer Local LANs
Purpose
Confirm the route to the remote peer by using the show route <dest-ip-prefix> operational
command.
For the NHTB table to be used, the static route needs to refer to the peer-devices (spoke)
st0 interface IP address.
Action
user@hub> show route 192.168.168.10
inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.168.0/24 *[Static/5] 00:08:33
> to 10.11.11.11 via st0.0
user@hub> show route 192.168.178.10
inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.178.0/24 *[Static/5] 00:04:04
> to 10.11.11.12 via st0.0
Meaning
22
In the output, the next hop is the remote peer st0 interface IP address, and both routes
point to st0.0 as the outgoing interface.
Copyright © 2014, Juniper Networks, Inc.
Checking Statistics and Errors for an IPsec SA
Purpose
Check statistics and errors for an IPsec SA.
For troubleshooting purposes, check the Encapsulating Security Payload/Authentication
Header (ESP/AH) counters for any errors with a particular IPsec SA.
Action
user@hub> show security ipsec statistics index 16385
ESP Statistics:
Encrypted bytes: 920
Decrypted bytes: 6208
Encrypted packets: 5
Decrypted packets: 87
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
Meaning
An error value of zero in the output indicates a normal condition.
Run this command multiple times to observe any packet loss issues across a VPN. Output
from this command also includes the statistics for encrypted and decrypted packet
counters, error counters, and so on. You must enable security flow traceoptions to
investigate which ESP packets are experiencing errors and why. For more information,
see “Troubleshooting Hub-and-Spoke VPNs” on page 24.
Testing Traffic Flow Across the VPN
Purpose
Test traffic flow across the VPN after IKE Phase 1, Phase 2, routes, and NHTB entries
have completed successfully.
You can test traffic flow by using the ping command. You can ping from the local host
to a remote host. You can also initiate pings from the Junos OS device itself.
This example shows how to initiate a ping request from the Junos OS device to the remote
host at the Sunnyvale office. You can use the same procedure to ping a host device at
the Westford office to confirm connectivity. Note that when pings are initiated from the
Junos OS device, the source interface must be specified to ensure that the correct route
lookup takes place and that the appropriate zones are referenced in the policy lookup.
In this example, the ge-0/0/0.0 interface resides in the same security zone as the local
host and must be specified in the ping request so that the policy lookup can be from zone
trust to zone untrust.
Copyright © 2014, Juniper Networks, Inc.
23
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
Action
user@hub> ping 192.168.168.10 interface ge-0/0/0 count 5
PING 192.168.168.10 (192.168.168.10): 56 data bytes
64 bytes from 192.168.168.10: icmp_seq=0 ttl=127 time=8.287
64 bytes from 192.168.168.10: icmp_seq=1 ttl=127 time=4.119
64 bytes from 192.168.168.10: icmp_seq=2 ttl=127 time=5.399
64 bytes from 192.168.168.10: icmp_seq=3 ttl=127 time=4.361
64 bytes from 192.168.168.10: icmp_seq=4 ttl=127 time=5.137
--- 192.168.168.10 ping statistics --5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.119/5.461/8.287/1.490 ms
ms
ms
ms
ms
ms
Confirming the Connectivity
Purpose
Action
Meaning
Confirm the connectivity between a remote host and a local host.
ssg5-> ping 10.10.10.10 from ethernet0/6
Type escape sequence to abort
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 1 seconds from
ethernet0/6
!!!!!
Success Rate is 100 percent (5/5), round-trip time min/avg/max=4/4/5 ms
ssg5-> ping 192.168.178.10 from ethernet0/6
Type escape sequence to abort
Sending 5, 100-byte ICMP Echos to 192.168.178.10, timeout is 1 seconds from
ethernet0/6
!!!!!
Success Rate is 100 percent (5/5), round-trip time min/avg/max=8/8/10 ms
You can confirm end-to-end connectivity from a remote host at a spoke site to a local
host at the Corporate office LAN by using the ping command. In this example, the
command is initiated from the SSG5 device.
Failed end-to-end connectivity might indicate an issue with routing, policy, end host, or
encryption/decryption of the ESP packets. To verify the exact causes of the failure:
•
Check the IPsec statistics for details on errors as described in “Checking Statistics and
Errors for an IPsec SA” on page 23.
•
Confirm end host connectivity by using the ping command from a host on the same
subnet as the end host. If the end host is reachable by other hosts, then you can assume
that the issue is not with the end host.
•
Enable security flow traceoptions for troubleshooting the routing-related and
policy-related issues.
Troubleshooting Hub-and-Spoke VPNs
The basic troubleshooting steps involve:
24
•
Identifying and isolating the problem
•
Debugging the problem
Copyright © 2014, Juniper Networks, Inc.
The common approach to begin troubleshooting is to start with the lowest layer of the
Open Systems Interconnection (OSI) model and work your way up the OSI stack to
determine in which layer the failure occurs. The steps for troubleshooting are as follows:
1.
Confirm the physical connectivity of the Internet link at the physical and data link
levels.
2. Confirm that the Junos OS device has connectivity to the Internet next hop and
connectivity to the remote IKE peer.
3. Confirm IKE Phase 1 completion.
4. Confirm IKE Phase 2 completion if IKE Phase 1 completion is successful.
5. Confirm the traffic flow across the VPN (if the VPN is up and active).
Junos OS includes the traceoptions feature. Using this feature, you can enable a
traceoption flag to write the data from the trace to a log file. The log file can be
predetermined or manually configured, and the file is stored in flash memory. These trace
logs can be retained even after a system reboot. Check the available flash storage before
implementing traceoptions.
You can enable the traceoptions feature in configuration mode and commit the
configuration to use the traceoptions feature. Similarly, to disable traceoptions, you must
deactivate traceoptions in configuration mode and commit the configuration.
If the VPN is not in the UP state then there is very little reason to test any transit traffic
across the VPN. Likewise if Phase 1 is not successful, then there is no need to look at
Phase 2 issues.
Checking the Free Disk Space on Your Device
Problem
You need to verify that the device file system has enough memory available to perform
other tasks.
Solution
Use show system storage command output to verify the free disk space.
user@hub> show system storage
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0s1a 213M 136M 75M 65% /devfs 1.0K 1.0K 0B 100% /dev
devfs 1.0K 1.0K 0B 100% /dev/
/dev/md0 144M 144M 0B 100% /junos
/cf 213M 136M 75M 65% /junos/cf
devfs 1.0K 1.0K 0B 100% /junos/dev/
procfs 4.0K 4.0K 0B 100% /proc
/dev/bo0s1e 24M 13K 24M 0% /config
/dev/md1 168M 7.3M 147M 5% /mfs
/dev/md2 58M 38K 53M 0% /jail/tmp
/dev/md3 7.7M 108K 7.0M 1% /jail/var
devfs 1.0K 1.0K 0B 100% /jail/dev
/dev/md4 1.9M 6.0K 1.7M 0% /jail/html/oem
The /dev/ad0s1a folder represents the onboard flash memory and is currently at 65%
capacity.
Copyright © 2014, Juniper Networks, Inc.
25
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
NOTE: You can view the available system storage in the J-Web interface
under the System Storage option.
NOTE: You can enable traceoptions to log the trace data to the filenames
specified or to the default log file to receive the output of the tracing operation.
For the Juniper Networks SRX3000 line, SRX5000 line, and SRX1400 devices,
the logs are located in the /var/tmp directory, and the SPU ID values are
included in the log filename. For example /var/tmp/kmd14.
Check the Log Files to Verify Different Scenarios and to Upload Log Files to an
FTP Server
Problem
You need to verify that logging to the syslog is working and that there are no errors shown
in the security IKE debug messages and security flow debug messages.
Solution
To verify the messages in the syslog, use the show log kmd, show log security-trace, and
show log messages commands.
user@hub> show log kmd
user@hub> show log security-trace
user@hub> show log messages
NOTE: You can view a list of all logs in the /var/log directory by using the
show log command.
Log files can also be uploaded to an FTP server by using the file copy command.
user@hub> file copy /var/log/kmd ftp://10.10.10.10/kmd.log
ftp://10.10.10.10/kmd.log 100% of 35 kB 12 MBps
Enable IKE Traceoptions to View Messages on IKE
Problem
You need to verify that there are no Phase 1 and Phase 2 negotiation issues and error
messages.
To verify success or failure messages for IKE or IPsec, display the key management
process (kmd) log by using the show log kmd command. Because the kmd log displays
some general messages, it might be useful to obtain additional details by enabling IKE
and PKI traceoptions.
NOTE: Generally, it is a best practice to troubleshoot the peer that has the
responder role. You must obtain the trace output from the initiator and the
responder to understand the cause of a failure.
26
Copyright © 2014, Juniper Networks, Inc.
Solution
Enable IKE traceoptions by configuring the device to write trace options and by setting
the flag for trace messages at the edit security ike traceoptions hierarchy level.
[edit security ike traceoptions]
user@hub# set file ?
Possible completions:
<filename> Name of file in which to write trace information
files Maximum number of trace files (2..1000)
match Regular expression for lines to be logged
no-world-readable Don't allow any user to read the log file
size Maximum trace file size (10240..1073741824)
world-readable Allow any user to read the log file
user@hub# set flag ?
Possible completions:
all Trace everything
certificates Trace certificate events
database Trace security associations database events
general Trace general events
ike Trace IKE module processing
parse Trace configuration processing
policy-manager Trace policy manager processing
routing-socket Trace routing socket messages
timer Trace internal timer events
NOTE: By default, if no filename is specified, then all IKE traceoptions output
is written to the kmd log. However, you can specify a different filename if you
want. If a different filename is specified, then all IKE and IPsec related logs
are no longer written to the kmd log.
To write trace data to the log, you must specify at least one flag option. For example:
•
file size — Maximum size of each trace file, in bytes. For example 1m or 1000000 can
generate a maximum file size of 1 MB.
•
file files — Maximum number of trace files to be generated and stored in flash memory.
NOTE: To start the trace, you must commit your configuration.
Setting Up IKE Traceoptions to Troubleshoot IKE-Related Issues
Problem
You need to configure IKE traceoptions.
Solution
Configure the required IKE traceoptions such as file size, policy-manager, flag, and
routing-socket in the edit security ike traceoptions hierarchy.
[edit security ike traceoptions]
user@hub# set file size 1m
Copyright © 2014, Juniper Networks, Inc.
27
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
user@hub# set flag policy-manager
user@hub# set flag ike
user@hub# set flag routing-socket
user@hub# commit
Analyzing the Phase 1 and Phase 2 Success Messages
Problem
Verify that Phase 1 and Phase 2 are successful.
Solution
Use the show log kmd command output to confirm that IKE Phase 1 and Phase 2 conditions
are successful, as shown:
Oct 8 10:41:40 Phase-1 [responder] done for local=ipv4(udp:500,[0..3]=1.1.1.2)
remote=ipv4(udp:500,[0..3]=2.2.2.2)
Oct 8 10:41:51 Phase-2 [responder] done for p1_local=ipv4(udp:500,[0..3]=1.1.1.2)
p1_remote=ipv4(udp:500,[0..3]=2.2.2.2)
p2_local=ipv4_subnet(any:0,[0..7]=10.10.10.0/24)
p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24)
The sample output indicates:
•
1.1.1.2 — Local address.
•
2.2.2.2 — Remote address.
•
udp: 500 — The UDP port. A value of 500 indicates that no NAT-T was negotiated.
•
Phase-1 [responder] done — Phase 1 status, along with the role (initiator or responder).
•
Phase-2 [responder] done — Phase 1 status with proxy ID information.
You can also confirm the IPsec SA status by using the verification commands mentioned
in “Display IPsec Security Association Details” on page 20.
Analyzing the Phase 1 Failure Message (Proposal Mismatch)
Problem
Phase 1 (responder) fails with an error because of proposal mismatch.
Solution
To resolve this issue, ensure that the parameters for the Phase 1 proposals for the
responder and the initiator match.
The following sample shows output from the show log kmd command. In this sample,
the IKE Phase 1 condition is a failure:
Oct 8 10:31:10 Phase-1 [responder] failed with error(No proposal chosen) for
local=unknown(any:0,[0..0]=) remote=ipv4(any:0,[0..3]=2.2.2.2)
Oct 8 10:31:10 1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { 011359c9 ddef501d - 2216ed2a
bfc50f5f [1] / 0x00000000 } IP; Error = No proposal chosen (14)
The sample output indicates:
28
•
1.1.1.2 — Local address.
•
2.2.2.2 — Remote address.
Copyright © 2014, Juniper Networks, Inc.
•
udp: 500 — No NAT-T was negotiated.
•
Phase-1 [responder] failed with error (No proposal chosen) — Phase 1 failure caused by
a proposal mismatch.
Analyzing the Phase 1 Failure Message (Policy Lookup Failure)
Problem
Phase 1 (responder) fails with an error caused by a policy lookup failure.
This condition indicates that Phase 1 is failing because of a proposal mismatch and
because the responder is not recognizing the incoming request as originating from a valid
gateway peer. The peer was not recognized because of an incorrect peer address, a
mismatched peer ID type, or an incorrect peer ID, depending on whether this is a dynamic
VPN or a static VPN.
Solution
To resolve this issue, configure the following before Phase 1:
•
Correct peer IP address on the local peer
•
Local peer with an IKE ID type of IP address
The following sample shows the output from the show log kmd command, where the
Phase 1 failure is caused by a policy lookup failure:
Oct 8 10:39:40 Unable to find phase-1 policy as remote peer:2.2.2.2 is not recognized.
Oct 8 10:39:40 KMD_PM_P1_POLICY_LOOKUP_FAILURE: Policy lookup for Phase-1
[responder] failed for
p1_local=ipv4(any:0,[0..3]=1.1.1.2) p1_remote=ipv4(any:0,[0..3]=2.2.2.2)
Oct 8 10:39:40 1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { 18983055 dbe1d0af a4d6d829 f9ed3bba [1] / 0x00000000 } IP; Error = No proposal chosen (14)
The sample output indicates:
•
1.1.1.2 — Local address.
•
2.2.2.2 — Remote address.
•
Unable to find phase-1 policy as remote peer:2.2.2.2 is not recognized — A Phase 1 failure
caused by a proposal mismatch and by the responder not recognizing the incoming
request as originating from a valid gateway peer (peer:2.2.2.2 is not recognized).
Analyzing the Phase 1 Failure Message (Invalid Payload Type)
Problem
Phase 1 (responder) fails because of an invalid payload type.
The invalid payload type indicates a problem with IKE packet decryption caused by a
mismatch of the preshared keys.
Solution
To resolve this issue, configure the preshared keys to match on the peers.
Copyright © 2014, Juniper Networks, Inc.
29
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
The following sample shows the output from the show log kmd command, when the
Phase 1 condition is a failure caused by invalid payload type:
Oct 8 10:36:20 1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { e9211eb9 b59d543c - 766a826d
bd1d5ca1 [1] / 0x00000000 } IP; Invalid next payload type = 17
Oct 8 10:36:20 phase-1 [responder] failed with error(Invalid payload type) for
local=unknown(any:0,[0..0]=) remote=ipv4(any:0,[0..3]=2.2.2.2)
The sample output indicates:
•
1.1.1.2 — Local address.
•
2.2.2.2 — Remote address.
•
Phase-1 [responder] failed with error (Invalid payload type) — Indicates Phase 1 failure
caused by invalid payload type.
Analyzing the Phase 2 Failure Message (Proposal Mismatch)
Problem
Phase 2 fails with an error caused by a proposal mismatch between two peers.
Solution
To resolve this issue, configure the Phase 2 proposals to match on the peers.
The following sample shows output of the show log kmd command, when the Phase 2
condition is a failure:
Oct 8 10:53:34 Phase-1 [responder] done for local=ipv4(udp:500,[0..3]=1.1.1.2)
remote=ipv4(udp:500,[0..3]=2.2.2.2)
Oct 8 10:53:34 1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { cd9dff36 4888d398 6b0d3933 f0bc8e26 [0]
/ 0x1747248b } QM; Error = No proposal chosen (14)
The sample output indicates:
•
1.1.1.2 — Local address.
•
2.2.2.2 — Remote address.
•
Phase-1 [responder] done — Phase 1 success.
•
Error = No proposal chosen — No proposal was chosen during Phase 2 negotiations.
Analyzing the Phase 2 Failure Message (Proxy ID Mismatch)
Problem
Phase 2 fails with an error caused by a proxy ID mismatch between two peers, resulting
from a mismatch of configurations on the local peer.
Solution
To resolve this issue, configure the proxy ID on one of the peers so that it matches the
other peer.
The following sample shows output from the show log kmd command, when the Phase
2 condition is a failure:
Oct 8 10:56:00 Phase-1 [responder] done for local=ipv4(udp:500,[0..3]=1.1.1.2)
remote=ipv4(udp:500,[0..3]=2.2.2.2)
30
Copyright © 2014, Juniper Networks, Inc.
Oct 8 10:56:00 Failed to match the peer proxy ids
p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24)
p2_local=ipv4_subnet(any:0,[0..7]=10.10.20.0/24)
for the remote peer:ipv4(udp:500,[0..3]=2.2.2.2)
Oct 8 10:56:00 KMD_PM_P2_POLICY_LOOKUP_FAILURE: Policy lookup for Phase-2 [responder]
failed for
p1_local=ipv4(udp:500,[0..3]=1.1.1.2) p1_remote=ipv4(udp:500,[0..3]=2.2.2.2)
p2_local=ipv4_subnet(any:0,[0..7]=10.10.20.0/24)
p2_remote=ipv4_subnet(any:0,[0..7]=192.168.168.0/24)
Oct 8 10:56:00 1.1.1.2:500 (Responder) <-> 2.2.2.2:500 { 41f638eb cc22bbfe 43fd0e85 b4f619d5 [0]
/ 0xc77fafcf } QM; Error = No proposal chosen (14)
The sample output indicates:
•
1.1.1.2 — Local address.
•
2.2.2.2 — Remote address.
•
Phase-1 [responder] done — Phase 1 success.
•
Policy lookup for Phase-2 [responder] failed — Incorrect proxy IDs are received. In the
sample output, the two proxy IDs received are 192.168.168.0/24 (remote) and
10.10.20.0/24 (local) (for service=any). Based on the configuration example in
“Example: Configuring the Spoke (Westford Office)” on page 13, the expected local
address is 10.10.10.0/24. This shows that there is a mismatch of configurations on the
local peer, resulting in a failure of the proxy ID match.
NOTE: For a route-based VPN, the proxy ID is all zeroes (local=0.0.0.0/0,
remote=0.0.0.0/0, service=any) by default. If the remote peer specifies a
proxy ID other than all zeroes, then you must manually configure the proxy
ID within the IPsec profile of the peer.
Troubleshooting Common Problems Related to IKE and PKI
Problem
Troubleshoot common problems related to IKE and PKI.
Solution
Enabling the traceoptions feature helps you to gather more information for debugging
issues than is obtainable from the normal log entries. You can use the traceoptions log
to understand the reasons for traffic not passing through the tunnel because of problems
related to route lookup, security policy, or some other flow issue (assuming that the IPsec
tunnel is up).
Details of flow traceoption output are beyond the scope of this example. For more
information about traceoptions output, see Example: Configuring Route-Based VPN Using
an SRX Series or a J Series Device and an SSG Device.
Copyright © 2014, Juniper Networks, Inc.
31
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
NOTE: Enabling flow traceoptions increases the device resource usage, and
it should always be best avoided during peak traffic load times or when CPU
usage is very high.
We recommend enabling packet filters to reduce the resource usage and to
facilitate classification of the required packets.
NOTE: We recommend deleting or deactivating all flow traceoptions and
removing any unnecessary log files from flash memory after completing
troubleshooting. To disable traceoptions, you must delete or deactivate them
in configuration mode and then commit the configuration.
Enabling Flow Traceoption to View Messages on Routing or Policy Issues
Problem
Verify that the log files to verify that logging to the syslog is working and that there are
no errors in the security IKE debug messages or the security flow debug messages.
Solution
View the log messages for routing-related or policy-related issues by using the following
commands:
user@hub# set security flow traceoptions file ?
Possible completions:
<filename> Name of file in which to write trace information
files Maximum number of trace files (2..1000)
match Regular expression for lines to be logged
no-world-readable Don't allow any user to read the log file
size Maximum trace file size (10240..1073741824)
world-readable Allow any user to read the log file
user@hub# set security flow traceoptions flag ?
Possible completions:
ager Ager events
all All events
basic-datapath Basic packet flow
cli CLI configuration and commands changes
errors Flow errors
fragmentation Ip fragmentation and reassembly events
high-availability Flow high-availability information
host-traffic Flow host-traffic information
lookup Flow lookup events
multicast Multicast flow information
packet-drops Packet drops
route Route information
session Session creation and deletion events
session-scan Session scan information
tcp-advanced Advanced TCP packet flow
tcp-basic TCP packet flow
tunnel Tunnel information
32
Copyright © 2014, Juniper Networks, Inc.
NOTE: If you do not specify filenames for the filename field, then all flow
traceoptions are written to the security-trace log. However, you can specify
a different filename, if desired.
To write data to the log, you must specify at least one flag option. For example:
•
basic-datapath — Most common traceoption flag for troubleshooting flow issues.
•
packet-drops — Trace only packets that are dropped in flow.
NOTE: To start the trace, you must first commit the configuration.
Configuring Packet Filters to Reduce the Resource Usage
Problem
Limit the scope of the traffic to be captured by the flow traceoptions.
Solution
You can limit the scope of traffic captured by configuring packet filters as shown in the
following command:
user@hub# set security flow traceoptions packet-filter filter-name ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
destination-port Match TCP/UDP destination port
destination-prefix Destination IPv4 address prefix
interface Logical interface
protocol Match IP protocol type
source-port Match TCP/UDP source port
source-prefix Source IPv4 address prefix
NOTE: Be aware of the following points concerning the packet-filter:
Copyright © 2014, Juniper Networks, Inc.
•
By configuring the packet-filter option, you can filter the output based on
source or destination IP, source or destination port, interface, and IP
protocol.
•
You can configure up to 64 filters.
•
A packet filter can work in reverse direction to capture the reply traffic, if
the source of the original packet matches the filter. For more information
about flow packet-filter options, see “Troubleshooting the Traffic, Using
Traceoptions with Packet Filters” on page 34. Terms listed within the same
packet filter act as a Boolean logical AND statement. That means that all
statements within the packet filter need to match in order to write the
output to the log. A listing of multiple filter names acts as a logical OR.
33
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
Troubleshooting the Traffic, Using Traceoptions with Packet Filters
Problem
Troubleshoot the traffic flow from the remote peer (Westford office) to the local host
(Corporate office).
Solution
You can troubleshoot the traffic flow between the remote peer to the local host by using
packet filters. You can use the output details from each flow traceoption command (as
shown in Table 2 on page 34) to analyze the traffic.
[edit security flow traceoptions]
user@hub# set file size 1m files 3
user@hub# set flag basic-datapath
user@hub# set packet-filter remote-to-local source-prefix 192.168.178.0/24
user@hub# set packet-filter remote-to-local destination-prefix 10.10.10.0/24
user@hub# set packet-filter local-to-remote source-prefix 10.10.10.0/24
user@hub# set packet-filter local-to-remote destination-prefix 192.168.178.0/24
user@hub# set packet-filter remote-esp protocol 50
user@hub# set packet-filter remote-esp source-prefix 3.3.3.2/32
user@hub# commit
Table 2 on page 34 provides output details for each flow traceoption setting in this sample
configuration.
Table 2: Output Details for Flow Traceoption Setting
Output of the Settings
[edit security flow
traceoptions]
user@hub# show
file flow-trace-log size 1m
files 3;
flag basic-datapath;
packet-filter
remote-to-local {
source-prefix
192.168.168.0/24;
destination-prefix
10.10.10.0/24;
}
packet-filter
local-to-remote {
source-prefix
10.10.10.0/24;
destination-prefix
192.168.178.0/24;
}
34
What It Indicates
•
Because there are no filenames specified, all flow traceoptions
are written to the security-trace log file.
•
The security-trace log file is set to 1 MB, and up to three files can
be created. Because the flow traceoption might generate a
large log file to capture the traffic, a single file might not be
adequate.
•
Flag basic-datapath captures the details for most flow-related
problems.
•
The packet-filter remote-to-local statement is used for capturing
the decapsulated or unencrypted traffic from the remote peer
to the local host.
•
The filter acts as a Boolean logical AND statement because
there are multiple terms listed. This filter captures the packets
only if the source IP address and destination IP address match.
If one of the addresses does not match, then the packet is not
captured.
•
The packet filters are bidirectional, and it is not necessary to
configure a filter for the reply traffic.
The packet-filter local-to-remote statement is required even though
it is not required to set a filter for capturing the reply traffic.
However a filter can capture only the packets that are originally
sourced from the specified side. Thus, the local-to-remote filter in
this example might still be required to capture traffic from the
local side to the remote side.
Copyright © 2014, Juniper Networks, Inc.
Table 2: Output Details for Flow Traceoption Setting (continued)
Output of the Settings
packet-filter remote-esp
{
protocol 50;
source-prefix 3.3.3.2/32;
}
What It Indicates
•
The packet-filter remote-esp statement is optional and depends
on whether or not the previous filter could capture any packets.
•
This filter can capture all ESP (IP protocol 50) or encrypted
packets from remote peer 3.3.3.2.
NOTE: Because this filter is configured at the bottom of the
hierarchy, it captures all encrypted traffic from server 3.3.3.2,
which might not be required.
NOTE: However, the last filter can capture all encrypted traffic
from 3.3.3.2 including packets that are not required. Since the
last filter captures unencrypted traffic, this filter might not be
required.
Thus, using the filters, you can troubleshoot any traffic flow issues to and from the
Corporate office and the Westford site. Additional filters can be configured for
troubleshooting from Westford to Sunnyvale and vice versa. In addition, to help narrow
the scope, a single host can be specified with the /32 mask to avoid having too much
data written to the trace log.
If any assistance is needed in interpreting the data from any of the traceoption logs,
contact your regional JTAC (Juniper Technical Assistance Center). The JTAC web site
can be found at http://www.juniper.net/customers/support/.
Related
Documentation
•
Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding Overview on page 1
•
Verifying Hub-and-Spoke VPN Configuration on page 35
Verifying Hub-and-Spoke VPN Configuration
This topic includes the following sections:
•
Verifying Configuration of the Hub (Device in Corporate Office) on page 35
•
Verifying Configuration of the Spoke (Device in Westford Office) on page 39
Verifying Configuration of the Hub (Device in Corporate Office)
For reference, the configuration of the Corporate office router is shown.
NOTE: The following sample of output from the show configuration command
shows traceoption configuration for troubleshooting purposes.
system {
host-name CORPORATE;
root-authentication {
encrypted-password "$1$0wc5IQiB$MTQlktoQ9/nRF10Gntin./"; ## SECRET-DATA
}
Copyright © 2014, Juniper Networks, Inc.
35
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
services {
ssh;
web-management {
http {
interface ge-0/0/0.0;
}
}
}
syslog {
user * {
any emergency;
}
file messages {
any any;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.10.10.1/24;
}
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 1.1.1.2/30;
}
}
}
st0 {
unit 0 {
multipoint;
family inet {
next-hop-tunnel 10.11.11.11 ipsec-vpn sunnyvale-vpn;
address 10.11.11.10/24;
}
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop 1.1.1.1;
route 192.168.168.0/24 next-hop 10.11.11.11;
route 192.168.178.0/24 next-hop 10.11.11.12;
}
}
security {
ike {
traceoptions {
36
Copyright © 2014, Juniper Networks, Inc.
flag policy-manager;
flag ike;
flag routing-socket;
flag general;
}
policy ike-policy1 {
mode main;
proposal-set standard;
pre-shared-key ascii-text "$9$LrN7w2mPQF/t24jqmfn6rev"; ## SECRET-DATA
}
gateway sunnyvale-gate {
ike-policy ike-policy1;
address 2.2.2.2;
external-interface ge-0/0/3.0;
}
gateway westford-gate {
ike-policy ike-policy1;
address 3.3.3.2;
external-interface ge-0/0/3.0;
}
}
ipsec {
policy vpn-policy1 {
perfect-forward-secrecy {
keys group2;
}
proposal-set standard;
}
vpn sunnyvale-vpn {
bind-interface st0.0;
ike {
gateway sunnyvale-gate;
ipsec-policy vpn-policy1;
}
}
vpn westford-vpn {
bind-interface st0.0;
ike {
gateway westford-gate;
ipsec-policy vpn-policy1;
}
}
}
nat {
source {
rule-set nat-out {
from zone trust;
to zone untrust;
rule interface-nat {
match {
source-address 192.168.10.0/24;
destination-address 0.0.0.0/0;
}
then {
source-nat interface;
}
Copyright © 2014, Juniper Networks, Inc.
37
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
}
}
}
}
zones {
security-zone trust {
address-book {
address local-net 10.10.10.0/24;
}
host-inbound-traffic {
system-services {
all;
}
}
interfaces {
ge-0/0/0.0;
}
}
security-zone untrust {
host-inbound-traffic {
system-services {
ike;
}
}
interfaces {
ge-0/0/3.0;
}
}
security-zone vpn {
address-book {
address sunnyvale-net 192.168.168.0/24;
address westford-net 192.168.178.0/24;
}
interfaces {
st0.0;
}
}
}
policies {
from-zone trust to-zone untrust {
policy any-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit ;
}
}
}
from-zone trust to-zone vpn {
policy local-to-spokes {
match {
source-address local-net;
destination-address [ sunnyvale-net westford-net ];
38
Copyright © 2014, Juniper Networks, Inc.
application any;
}
then {
permit;
}
}
}
from-zone vpn to-zone trust {
policy spokes-to-local {
match {
source-address [ sunnyvale-net westford-net ];
destination-address local-net;
application any;
}
then {
permit;
}
}
}
from-zone vpn to-zone vpn {
policy spoke-to-spoke {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
}
flow {
tcp-mss {
ipsec-vpn {
mss 1350;
}
}
}
}
TIP: Delete or deactivate the traceoptions after you complete troubleshooting.
Verifying Configuration of the Spoke (Device in Westford Office)
For reference, the configuration of the spoke router is shown.
NOTE: The following sample of output from the show configuration command
shows traceoption configuration for troubleshooting purposes.
system {
host-name Westford;
Copyright © 2014, Juniper Networks, Inc.
39
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
root-authentication {
encrypted-password "$1$Qk3dVh9X$d3KOf3dhR6uQKhi8FWU.P0"; ## SECRET-DATA
}
services {
web-management {
http {
interface ge-0/0/0.0;
}
}
}
syslog {
user * {
any emergency;
}
file messages {
any any;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 3.3.3.2/30;
}
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 192.168.178.1/24;
}
}
}
st0 {
unit 0 {
family inet {
address 10.11.11.12/24;
}
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop 1.1.1.1;
route 10.10.10.0/24 next-hop 10.11.11.10;
route 192.168.168.0/24 next-hop 10.11.11.10;
}
}
security {
ike {
traceoptions {
40
Copyright © 2014, Juniper Networks, Inc.
flag policy-manager;
flag ike;
flag routing-socket;
flag general;
}
policy ike-policy1 {
mode main;
proposal-set standard;
pre-shared-key ascii-text "$9$VNsaGF39A0IGDPQFnpu8X7"; ## SECRET-DATA
}
gateway corp-gate {
ike-policy ike-policy1;
address 1.1.1.2;
external-interface ge-0/0/0.0;
}
}
ipsec {
policy vpn-policy1 {
perfect-forward-secrecy {
keys group2;
}
proposal-set standard;
}
vpn corp-vpn {
bind-interface st0.0;
ike {
gateway corp-gate;
ipsec-policy vpn-policy1;
}
}
}
nat {
source {
rule-set nat-out {
from zone trust;
to zone untrust;
rule interface-nat {
match {
source-address 192.168.178.0/24;
destination-address 0.0.0.0/0;
}
then {
source-nat interface;
}
}
}
}
}
zones {
security-zone trust {
address-book {
address local-net 192.168.178.0/24;
}
host-inbound-traffic {
system-services {
all;
Copyright © 2014, Juniper Networks, Inc.
41
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
}
}
interfaces {
ge-0/0/3.0;
}
}
security-zone untrust {
host-inbound-traffic {
system-services {
ike;
}
}
interfaces {
ge-0/0/0.0;
}
}
security-zone vpn {
address-book {
address corp-net 10.10.10.0/24;
address sunnyvale-net 192.168.168.0/24;
}
interfaces {
st0.0;
}
}
}
policies {
from-zone trust to-zone untrust {
policy any-permit {
match {
source-address any;
destination-address any;
application any;
}
then {
permit {
source-nat {
interface;
}
}
}
}
}
from-zone vpn to-zone trust {
policy from-corp {
match {
source-address [ corp-net sunnyvale-net ];
destination-address local-net;
application any;
}
then {
permit;
}
}
}
from-zone trust to-zone vpn {
42
Copyright © 2014, Juniper Networks, Inc.
policy to-corp {
match {
source-address local-net;
destination-address [ corp-net sunnyvale-net ];
application any;
}
then {
permit;
}
}
}
}
flow {
tcp-mss {
ipsec-vpn {
mss 1350;
}
}
}
}
NOTE: In the preceding sample of output from the show configuration
command, the highlighted lines show traceoptions for troubleshooting
purposes.
TIP: Delete or deactivate the traceoptions after you complete troubleshooting.
Related
Documentation
•
Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding Overview on page 1
•
Example: Configuring Hub-and-Spoke VPNs using Next-Hop Tunnel Binding on page 4
Copyright © 2014, Juniper Networks, Inc.
43
Configuring, Verifying, and Troubleshooting Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding
44
Copyright © 2014, Juniper Networks, Inc.

advertisement

Key Features

  • Next-hop tunnel binding
  • Route-based VPNs
  • Multipoint interfaces
  • Hub-and-spoke VPN topology
  • Multipoint secure tunnel interfaces
  • IPsec security associations
  • Route-to-tunnel mapping
  • Security zones
  • IPsec VPN
  • IKE policy

Frequently Answers and Questions

What is next-hop tunnel binding?
Next-hop tunnel binding (NHTB) is a feature in Junos OS that enables a device to bind multiple IPsec security associations (SAs) to a single secure tunnel interface (st0). This allows for easier management and scalability in hub-and-spoke VPN topologies.
How does route-to-tunnel mapping work?
Route-to-tunnel mapping allows the security device to map the next-hop gateway IP address specified in the route table to a particular IPsec tunnel name. This ensures that traffic is routed correctly through the appropriate VPN tunnel.
Why is it important to configure TCP MSS?
Configuring TCP MSS eliminates the possibility of fragmented TCP traffic across the tunnel. Fragmentation can increase bandwidth usage and device resource usage. The recommended value for TCP MSS is 1350 for most Ethernet-based networks.
What are the benefits of using security zones?
Security zones help to create a more secure network by isolating different types of traffic. In this example, a separate security zone is used for tunnel traffic, allowing for specific policies to be applied to VPN traffic.

Related manuals

Download PDF

advertisement