ON THIS PAGE
Recommended Configuration Options for Site-to-Site VPN with Static IP Addresses
Recommended Configuration Options for Site-to-Site or Dialup VPNs with Dynamic IP Addresses
Understanding OSPF and OSPFv3 Authentication on SRX Series Firewalls
Example: Configuring IPsec Authentication for an OSPF Interface on an SRX Series Firewall
IPsec VPN Configuration Overview
A VPN connection can link two LANs (site-to-site VPN) or a remote dial-up user and a LAN. The traffic that flows between these two points passes through shared resources such as routers, switches, and other network equipment that make up the public WAN. An IPsec tunnel is created between two participant devices to secure VPN communication.
IPsec VPN with Autokey IKE Configuration Overview
IPsec VPN negotiation occurs in two phases. In Phase 1, participants establish a secure channel in which to negotiate the IPsec security association (SA). In Phase 2, participants negotiate the IPsec SA for authenticating traffic that will flow through the tunnel.
This overview describes the basic steps to configure a route-based or policy-based IPsec VPN using autokey IKE (preshared keys or certificates).
To configure a route-based or policy-based IPsec VPN using autokey IKE:
See Also
Recommended Configuration Options for Site-to-Site VPN with Static IP Addresses
Table 1 lists the configuration options for a generic site-to-site VPN between two security devices with static IP addresses. The VPN can be either route-based or policy-based.
Configuration Option |
Comment |
|---|---|
IKE configuration options: |
|
Main mode |
Used when peers have static IP addresses. |
RSA or DSA certificates |
RSA or DSA certificates can be used on the local device. Specify the type of certificate (PKCS7 or X.509) on the peer. |
Diffie-Hellman (DH) group 14 |
DH group 14 provides more security than DH groups 1, 2, or 5. |
Advanced Encryption Standard (AES) encryption |
AES is cryptographically stronger than Data Encryption Standard (DES) and Triple DES (3DES) when key lengths are equal. Approved encryption algorithm for Federal Information Processing Standards (FIPS) and Common Criteria EAL4 standards. |
Secure Hash Algorithm 256 (SHA-256) authentication |
SHA-256 provides more cryptographic security than SHA-1 or Message Digest 5 (MD5) . |
IPsec configuration options: |
|
Perfect Forward Secrecy (PFS) DH group 14 |
PFS DH group 14 provides increased security because the peers perform a second DH exchange to produce the key used for IPsec encryption and decryption. |
Encapsulating Security Payload (ESP) protocol |
ESP provides both confidentiality through encryption and encapsulation of the original IP packet and integrity through authentication. |
AES encryption |
AES is cryptographically stronger than DES and 3DES when key lengths are equal. Approved encryption algorithm for FIPS and Common Criteria EAL4 standards. |
SHA-256 authentication |
SHA-256 provides more cryptographic security than SHA-1 or MD5. |
Anti-replay protection |
Enabled by default. Disabling this feature might resolve compatibility issues with third-party peers. |
See Also
Recommended Configuration Options for Site-to-Site or Dialup VPNs with Dynamic IP Addresses
Table 2 lists the configuration options for a generic site-to-site or dialup VPN, where the peer devices have dynamic IP addresses.
Configuration Option |
Comment |
|---|---|
IKE configuration options: |
|
Main mode |
Used with certificates. |
2048-bit certificates |
RSA or DSA certificates can be used. Specify the certificate to be used on the local device. Specify the type of certificate (PKCS7 or X.509) on the peer. |
Diffie-Hellman (DH) group 14 |
DH group 14 provides more security than DH groups 1, 2, or 5. |
Advanced Encryption Standard (AES) encryption |
AES is cryptographically stronger than Data Encryption Standard (DES) and Triple DES (3DES) when key lengths are equal. Approved encryption algorithm for Federal Information Processing Standards (FIPS) and Common Criteria EAL4 standards. |
Secure Hash Algorithm 256 (SHA-256) authentication |
SHA-256 provides more cryptographic security than SHA-1 or Message Digest 5 (MD5). |
IPsec configuration options: |
|
Perfect Forward Secrecy (PFS) DH group 14 |
PFS DH group 14 provides increased security because the peers perform a second DH exchange to produce the key used for IPsec encryption and decryption. |
Encapsulating Security Payload (ESP) protocol |
ESP provides both confidentiality through encryption and encapsulation of the original IP packet and integrity through authentication. |
AES encryption |
AES is cryptographically stronger than DES and 3DES when key lengths are equal. Approved encryption algorithm for FIPS and Common Criteria EAL4 standards. |
SHA-256 authentication |
SHA-256 provides more cryptographic security than SHA-1 or MD5. |
Anti-replay protection |
Enabled by default. Disabling this might resolve compatibility issues with third-party peers. |
See Also
Understanding IPsec VPNs with Dynamic Endpoints
- Overview
- IKE Identity
- Aggressive Mode for IKEv1 Policy
- IKE Policies and External Interfaces
- NAT
- Group and Shared IKE IDs
Overview
An IPsec VPN peer can have an IP address that is not known to the peer with which it is establishing the VPN connection. For example, a peer can have an IP address dynamically assigned by means of Dynamic Host Configuration Protocol (DHCP). This could be the case with a remote access client in a branch or home office or a mobile device that moves between different physical locations. Or, the peer can be located behind a NAT device that translates the peer’s original source IP address into a different address. A VPN peer with an unknown IP address is referred to as a dynamic endpoint and a VPN established with a dynamic endpoint is referred to as a dynamic endpoint VPN.
On SRX Series Firewalls, IKEv1 or IKEv2 is supported with dynamic endpoint VPNs. Dynamic endpoint VPNs on SRX Series Firewalls support IPv4 traffic on secure tunnels. Starting with Junos OS Release 15.1X49-D80, dynamic endpoint VPNs on SRX Series Firewalls support IPv6 traffic on secure tunnels.
IPv6 traffic is not supported for AutoVPN networks.
The following sections describe items to note when configuring a VPN with a dynamic endpoint.
IKE Identity
On the dynamic endpoint, an IKE identity must be configured for the device to identify itself to its peer. The local identity of the dynamic endpoint is verified on the peer. By default, the SRX Series Firewall expects the IKE identity to be one of the following:
When certificates are used, a distinguished name (DN) can be used to identify users or an organization.
A hostname or fully qualified domain name (FQDN) that identifies the endpoint.
A user fully qualified domain name (UFQDN), also known as user-at-hostname. This is a string that follows the e-mail address format.
Aggressive Mode for IKEv1 Policy
When IKEv1 is used with dynamic endpoint VPNs, the IKE policy must be configured for aggressive mode.
IKE Policies and External Interfaces
Starting with Junos OS Release 12.3X48-D40, Junos OS Release 15.1X49-D70, and Junos OS Release 17.3R1, all dynamic endpoint gateways configured on SRX Series Firewalls that use the same external interface can use different IKE policies, but the IKE policies must use the same IKE proposal. This applies to IKEv1 and IKEv2.
NAT
If the dynamic endpoint is behind a NAT device, NAT-T must be configured on the SRX Series Firewall. NAT keepalives might be required to maintain the NAT translation during the connection between the VPN peers. By default, NAT-T is enabled on SRX Series Firewalls and NAT keepalives are sent at 20-second intervals.
Group and Shared IKE IDs
You can configure an individual VPN tunnel for each dynamic endpoint. For IPv4 dynamic endpoint VPNs, you can use the group IKE ID or shared IKE ID features to allow a number of dynamic endpoints to share an IKE gateway configuration.
The group IKE ID allows you to define a common part of a full IKE ID for all dynamic endpoints, such as “example.net.” A user-specific part, such as the username “Bob,” concatenated with the common part forms a full IKE ID (Bob.example.net) that uniquely identifies each user connection.
The shared IKE ID allows dynamic endpoints to share a single IKE ID and preshared key.
See Also
Understanding IKE Identity Configuration
The IKE identification (IKE ID) is used for validation of VPN peer devices during IKE negotiation. The IKE ID received by the SRX Series Firewall from a remote peer can be an IPv4 or IPv6 address, a hostname, a fully qualified domain name (FQDN), a user FQDN (UFQDN), or a distinguished name (DN). The IKE ID sent by the remote peer needs to match what is expected by the SRX Series Firewall. Otherwise, IKE ID validation fails and the VPN is not established.
- IKE ID Types
- Remote IKE IDs and Site-to-Site VPNs
- Remote IKE IDs and Dynamic Endpoint VPNs
- Local IKE ID of the SRX Series Firewall
IKE ID Types
The SRX Series Firewalls support the following types of IKE identities for remote peers:
An IPv4 or IPv6 address is commonly used with site-to-site VPNs, where the remote peer has a static IP address.
A hostname is a string that identifies the remote peer system. This can be an FQDN that resolves to an IP address. It can also be a partial FQDN that is used in conjunction with an IKE user type to identify a specific remote user.
When a hostname is configured instead of an IP address, the committed configuration and subsequent tunnel establishment is based on the currently-resolved IP address. If the remote peer’s IP address changes, the configuration is no longer valid.
A UFQDN is a string that follows the same format as an e-mail address, such as
user@example.com.A DN is a name used with digital certificates to uniquely identify a user. For example, a DN can be “CN=user, DC=example, DC=com.” Optionally, you can use the
containerkeyword to specify that the order of the fields in a DN and their values exactly match the configured DN, or use thewildcardkeyword to specify that the values of fields in a DN must match but the order of the fields does not matter.Starting in Junos OS Release 19.4R1, you can now configure only one dynamic DN attribute among
container-stringandwildcard-stringat[edit security ike gateway gateway_name dynamic distinguished-name]hierarchy. If you try configuring the second attribute after you configure the first attribute, the first attribute is replaced with the second attribute. Before your upgrade your device, you must remove one of the attributes if you have configured both the attributes.An IKE user type can be used with AutoVPN and remote access VPNs when there are multiple remote peers connecting to the same VPN gateway on the SRX Series Firewall. Configure
ike-user-type group-ike-idto specify a group IKE ID orike-user-type shared-ike-idto specify a shared IKE ID.
Remote IKE IDs and Site-to-Site VPNs
For site-to-site VPNs, the remote peer’s IKE ID can be the IP address of the egress network interface card, a loopback address, a hostname, or a manually configured IKE ID, depending on the configuration of the peer device.
By default, SRX Series Firewalls expect the remote peer’s IKE ID to be the IP address configured
with the set security ike gateway gateway-name
address configuration. If the remote peer’s IKE ID is a different
value, you need to configure the remote-identity statement at the
[edit security ike gateway gateway-name]
hierarchy level.
For example, an IKE gateway on the SRX Series Firewalls is configured with the set
security ike gateway remote-gateway address 203.0.113.1 command.
However, the IKE ID sent by the remote peer is host.example.net.
There is a mismatch between what the SRX Series Firewall expects for the remote
peer’s IKE ID (203.0.113.1) and the actual IKE ID
(host.example.net) sent by the peer. In this case, IKE ID
validation fails. Use the set security ike gateway remote-gateway
remote-identity hostname host.example.net to match the IKE ID received
from the remote peer.
Remote IKE IDs and Dynamic Endpoint VPNs
For dynamic endpoint VPNs, the remote peer’s expected
IKE ID is configured with the options at the [edit security ike
gateway gateway-name dynamic] hierarchy
level. For AutoVPN, hostname combined with ike-user-type
group-ike-id can be used where there are multiple peers that
have a common domain name. If certificates are used for verifying
the peer, a DN can be configured.
Local IKE ID of the SRX Series Firewall
By default, the SRX Series Firewall uses the IP address of its external interface to the remote
peer as its IKE ID. This IKE ID can be overridden by configuring the
local-identity statement at the [edit security ike
gateway gateway-name] hierarchy level. If you need
to configure the local-identity statement on an SRX Series
Firewall, make sure that the configured IKE ID matches the IKE ID expected by the
remote peer.
See Also
Configuring Remote IKE IDs for Site-to-Site VPNs
By default, SRX Series Firewalls validate the IKE ID received from the peer with the IP address configured for the IKE gateway. In certain network setups, the IKE ID received from the peer (which can be an IPv4 or IPv6 address, fully qualified domain name [FQDN], distinguished name, or e-mail address) does not match the IKE gateway configured on the SRX Series Firewall. This can lead to a Phase 1 validation failure.
To modify the configuration of the SRX Series Firewall or the peer device for the IKE ID that is used:
On the SRX Series Firewall, configure the
remote-identitystatement at the [edit security ike gateway gateway-name] hierarchy level to match the IKE ID that is received from the peer. Values can be an IPv4 or IPv6 address, FQDN, distinguished name, or e-mail address.If you do not configure
remote-identity, the device uses the IPv4 or IPv6 address that corresponds to the remote peer by default.On the peer device, ensure that the IKE ID is the same as the
remote-identityconfigured on the SRX Series Firewall. If the peer device is an SRX Series Firewall, configure thelocal-identitystatement at the [edit security ike gateway gateway-name] hierarchy level. Values can be an IPv4 or IPv6 address, FQDN, distinguished name, or e-mail address.
See Also
Understanding OSPF and OSPFv3 Authentication on SRX Series Firewalls
OSPFv3 does not have a built-in authentication method and relies on the IP Security (IPsec) suite to provide this functionality. IPsec provides authentication of origin, data integrity, confidentiality, replay protection, and nonrepudiation of source. You can use IPsec to secure specific OSPFv3 interfaces and virtual links and to provide encryption for OSPF packets.
OSPFv3 uses the IP authentication header (AH) and the IP Encapsulating Security Payload (ESP) portions of the IPsec protocol to authenticate routing information between peers. AH can provide connectionless integrity and data origin authentication. It also provides protection against replays. AH authenticates as much of the IP header as possible, as well as the upper-level protocol data. However, some IP header fields might change in transit. Because the value of these fields might not be predictable by the sender, they cannot be protected by AH. ESP can provide encryption and limited traffic flow confidentiality or connectionless integrity, data origin authentication, and an anti-replay service.
IPsec is based on security associations (SAs). An SA is a set of IPsec specifications that are negotiated between devices that are establishing an IPsec relationship. This simplex connection provides security services to the packets carried by the SA. These specifications include preferences for the type of authentication, encryption, and IPsec protocol to be used when establishing the IPsec connection. An SA is used to encrypt and authenticate a particular flow in one direction. Therefore, in normal bidirectional traffic, the flows are secured by a pair of SAs. An SA to be used with OSPFv3 must be configured manually and use transport mode. Static values must be configured on both ends of the SA.
To configure IPsec for OSPF or OSPFv3, first define a manual
SA with the security-association sa-name option at the [edit security ipsec] hierarchy level.
This feature only supports bidirectional manual key SAs in transport
mode. Manual SAs require no negotiation between the peers. All values,
including the keys, are static and specified in the configuration.
Manual SAs statically define the security parameter index (SPI) values,
algorithms, and keys to be used and require matching configurations
on both endpoints (OSPF or OSPFv3 peers). As a result, each peer must
have the same configured options for communication to take place.
The actual choice of encryption and authentication algorithms is left to your IPsec administrator; however, we have the following recommendations:
Use ESP with null encryption to provide authentication to protocol headers but not to the IPv6 header, extension headers, and options. With null encryption, you are choosing not to provide encryption on protocol headers. This can be useful for troubleshooting and debugging purposes. For more information about null encryption, see RFC 2410, The NULL Encryption Algorithm and Its Use with IPsec.
Use ESP with DES or 3DES for full confidentiality.
Use AH to provide authentication to protocol headers, immutable fields in IPv6 headers, and extension headers and options.
The configured SA is applied to the OSPF or OSPFv3 configurations as follows:
For an OSPF or OSPFv3 interface, include the
ipsec-sa namestatement at the [edit protocols ospf area area-id interface interface-name] or [edit protocols ospf3 area area-id interface interface-name] hierarchy level. Only one IPsec SA name can be specified for an OSPF or OSPFv3 interface; however, different OSPF/OSPFv3 interfaces can specify the same IPsec SA.For an OSPF or OSPFv3 virtual link, include the
ipsec-sa namestatement at the [edit protocols ospf area area-id virtual-link neighbor-id router-id transit-area area-id] or [edit protocols ospf3 area area-id virtual-link neighbor-id router-id transit-area area-id] hierarchy level. You must configure the same IPsec SA for all virtual links with the same remote endpoint address.
The following restrictions apply to IPsec authentication for OSPF or OSPFv3 on SRX Series Firewalls:
Manual VPN configurations that are configured at the [
edit security ipsec vpn vpn-name manual] hierarchy level cannot be applied to OSPF or OSPFv3 interfaces or virtual links to provide IPsec authentication and confidentiality.You cannot configure IPsec for OSPF or OSPFv3 authentication if there is an existing IPsec VPN configured on the device with the same local and remote addresses.
IPsec for OSPF or OSPFv3 authentication is not supported over secure tunnel st0 interfaces.
Rekeying of manual keys is not supported.
Dynamic Internet Key Exchange (IKE) SAs are not supported.
Only IPsec transport mode is supported. In transport mode, only the payload (the data you transfer) of the IP packet is encrypted, authenticated, or both. Tunnel mode is not supported.
Because only bidirectional manual SAs are supported, all OSPFv3 peers must be configured with the same IPsec SA. You configure a manual bidirectional SA at the [
edit security ipsec] hierarchy level.You must configure the same IPsec SA for all virtual links with the same remote endpoint address.
See Also
Example: Configuring IPsec Authentication for an OSPF Interface on an SRX Series Firewall
This example shows how to configure and apply a manual security association (SA) to an OSPF interface.
Requirements
Before you begin:
Configure the device interfaces.
Configure the router identifiers for the devices in your OSPF network.
Control OSPF designated router election.
Configure a single-area OSPF network.
Configure a multiarea OSPF network.
Overview
You can use IPsec authentication for both OSPF and OSPFv3. You configure the manual SA separately and apply it to the applicable OSPF configuration. Table 3 lists the parameters and values configured for the manual SA in this example.
Parameter |
Value |
|---|---|
SA name |
sa1 |
Mode |
transport |
Direction |
bidirectional |
Protocol |
AH |
SPI |
256 |
Authentication algorithm Key |
hmac-md5-96 (ASCII) 123456789012abc |
Encryption algorithm Key |
des (ASCII) cba210987654321 |
Configuration
Configuring a Manual SA
CLI Quick Configuration
To quickly configure a manual SA to be used
for IPsec authentication on an OSPF interface, copy the following
commands, paste them into a text file, remove any line breaks, change
any details necessary to match your network configuration, copy and
paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration
mode.
[edit] set security ipsec security-association sa1 set security ipsec security-association sa1 mode transport set security ipsec security-association sa1 manual direction bidirectional set security ipsec security-association sa1 manual direction bidirectional protocol ah set security ipsec security-association sa1 manual direction bidirectional spi 256 set security ipsec security-association sa1 manual direction bidirectional authentication algorithm hmac-md5-96 key ascii-text 123456789012abc set security ipsec security-association sa1 manual direction bidirectional encryption algorithm des key ascii-text cba210987654321
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure a manual SA:
Specify a name for the SA.
[edit] user@host# edit security ipsec security-association sa1
Specify the mode of the manual SA.
[edit security ipsec security-association sa1] user@host# set mode transport
Configure the direction of the manual SA.
[edit security ipsec security-association sa1] user@host# set manual direction bidirectional
Configure the IPsec protocol to use.
[edit security ipsec security-association sa1] user@host# set manual direction bidirectional protocol ah
Configure the value of the SPI.
[edit security ipsec security-association sa1] user@host# set manual direction bidirectional spi 256
Configure the authentication algorithm and key.
[edit security ipsec security-association sa1] user@host# set manual direction bidirectional authentication algorithm hmac-md5-96 key ascii-text 123456789012abc
Configure the encryption algorithm and key.
[edit security ipsec security-association sa1] user@host# set manual direction bidirectional encryption algorithm des key ascii-text cba210987654321
Results
Confirm your configuration by entering the show
security ipsec command. If the output does not display the intended
configuration, repeat the instructions in this example to correct
the configuration.
After you configure the password, you do not see the password itself. The output displays the encrypted form of the password you configured.
[edit]
user@host# show security ipsec
security-association sa1 {
mode transport;
manual {
direction bidirectional {
protocol ah;
spi 256;
authentication {
algorithm hmac-md5-96;
key ascii-text "$9$AP5Hp1RcylMLxSygoZUHk1REhKMVwY2oJx7jHq.zF69A0OR"; ## SECRET-DATA
}
encryption {
algorithm des;
key ascii-text "$9$AP5Hp1RcylMLxSygoZUHk1REhKMVwY2oJx7jHq.zF69A0OR"; ## SECRET-DATA
}
}
}
}
If you are done configuring the device, enter commit from configuration mode.
Enabling IPsec Authentication for an OSPF Interface
CLI Quick Configuration
To quickly apply a manual SA used for IPsec
authentication to an OSPF interface, copy the following command, paste
it into a text file, change any details necessary to match your network
configuration, copy and paste the command into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
[edit] set protocols ospf area 0.0.0.0 interface so-0/2/0 ipsec-sa sa1
Step-by-Step Procedure
To enable IPsec authentication for an OSPF interface:
Create an OSPF area.
To specify OSPFv3, include the
ospf3statement at the[edit protocols]hierarchy level.[edit] user@host# edit protocols ospf area 0.0.0.0
Specify the interface.
[edit protocols ospf area 0.0.0.0] user@host# edit interface so-0/2/0
Apply the IPsec manual SA.
[edit protocols ospf area 0.0.0.0 interface so-0/2/0.0] user@host# set ipsec-sa sa1
Results
Confirm your configuration by entering the show ospf interface detail command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.
[edit]
user@host# show protocols ospf
area 0.0.0.0 {
interface so-0/2/0.0 {
ipsec-sa sa1;
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
- Verifying the IPsec Security Association Settings
- Verifying the IPsec Security Association on the OSPF Interface
Verifying the IPsec Security Association Settings
Purpose
Verify the configured IPsec security association settings. Verify the following information:
The Security association field displays the name of the configured security association.
The SPI field displays the value you configured.
The Mode field displays transport mode.
The Type field displays manual as the type of security association.
Action
From operational mode, enter the show ospf interface detail command.
Verifying the IPsec Security Association on the OSPF Interface
Purpose
Verify that the IPsec security association that you configured has been applied to the OSPF interface. Confirm that the IPsec SA name field displays the name of the configured IPsec security association.
Action
From operational mode, enter the show ospf interface detail command for OSPF, and enter the show ospf3 interface detail command for OSPFv3.
Configuring IPsec VPN Using the VPN Wizard
The VPN Wizard enables you to perform basic IPsec VPN configuration, including both Phase 1 and Phase 2. For more advanced configuration, use the J-Web interface or the CLI. This feature is supported on SRX300, SRX320, SRX340, SRX345, and SRX550HM devices.
To configure IPsec VPN using the VPN Wizard:
- Select
Configure>Device Setup>VPNin the J-Web interface. - Click the Launch VPN Wizard button.
- Follow the wizard prompts.
The upper left area of the wizard page shows where you are in the configuration process. The lower left area of the page shows field-sensitive help. When you click a link under the Resources heading, the document opens in your browser. If the document opens in a new tab, be sure to close only the tab (not the browser window) when you close the document.
See Also
Example: Configuring a Hub-and-Spoke VPN
This example shows how to configure a hub-and-spoke IPsec VPN for an enterprise-class deployment. For site-to-site IPSec VPN with IKEv1 and IKEv2, see Route-Based IPsec VPN with IKEv1 and Route-Based IPsec VPN with IKEv1 respectively.
Requirements
This example uses the following hardware:
SRX240 device
SRX5800 device
SSG140 device
Before you begin, read IPsec Overview.
Overview
This example describes how to configure a hub-and-spoke VPN typically found in branch deployments. The hub is the corporate office, and there are two spokes—a branch office in Sunnyvale, California, and a branch office in Westford, Massachusetts. Users in the branch offices will use the VPN to securely transfer data with the corporate office.
Figure 1 shows an example of a hub-and-spoke VPN topology. In this topology, an SRX5800 device is located at the corporate office. An SRX Series Firewall is located at the Westford branch, and an SSG140 device is located at the Sunnyvale branch.
In this example, you configure the corporate office hub, the Westford spoke, and the Sunnyvale spoke. First you configure interfaces, IPv4 static and default routes, security zones, and address books. Then you configure IKE Phase 1 and IPsec Phase 2 parameters, and bind the st0.0 interface to the IPsec VPN. On the hub, you configure st0.0 for multipoint and add a static NHTB table entry for the Sunnyvale spoke. Finally, you configure security policy and TCP-MSS parameters. See Table 4 through Table 8 for specific configuration parameters used in this example.
Hub or Spoke |
Feature |
Name |
Configuration Parameters |
|---|---|---|---|
Hub |
Interfaces |
ge-0/0/0.0 |
192.168.10.1/24 |
ge-0/0/3.0 |
10.1.1.2/30 |
||
st0 |
10.11.11.10/24 |
||
Spoke |
Interfaces |
ge-0/0/0.0 |
10.3.3.2/30 |
ge-0/0/3.0 |
192.168.178.1/24 |
||
st0 |
10.11.11.12/24 |
||
Hub |
Security zones |
trust |
|
untrust |
|
||
vpn |
The st0.0 interface is bound to this zone. |
||
Spoke |
Security zones |
trust |
|
untrust |
|
||
vpn |
The st0.0 interface is bound to this zone. |
||
Hub |
Address book entries |
local-net |
|
sunnyvale-net |
|
||
westford-net |
|
||
Spoke |
Address book entries |
local-net |
|
corp-net |
|
||
sunnyvale-net |
|
Hub or Spoke |
Feature |
Name |
Configuration Parameters |
|---|---|---|---|
Hub |
Proposal |
ike-phase1-proposal |
|
Policy |
ike-phase1-policy |
|
|
Gateway |
gw-westford |
|
|
gw-sunnyvale |
|
||
Spoke |
Proposal |
ike-phase1-proposal |
|
Policy |
ike-phase1-policy |
|
|
Gateway |
gw-corporate |
|
Hub or Spoke |
Feature |
Name |
Configuration Parameters |
|---|---|---|---|
Hub |
Proposal |
ipsec-phase2-proposal |
|
Policy |
ipsec-phase2-policy |
|
|
VPN |
vpn-sunnyvale |
|
|
vpn-westford |
|
||
Spoke |
Proposal |
ipsec-phase2-proposal |
|
Policy |
ipsec-phase2-policy |
|
|
VPN |
vpn-corporate |
|
Hub or Spoke |
Purpose |
Name |
Configuration Parameters |
|---|---|---|---|
Hub |
The security policy permits traffic from the trust zone to the vpn zone. |
local-to-spokes |
|
The security policy permits traffic from the vpn zone to the trust zone. |
spokes-to-local |
Match criteria:
|
|
The security policy permits intrazone traffic. |
spoke-to-spoke |
Match criteria:
|
|
Spoke |
The security policy permits traffic from the trust zone to the vpn zone. |
to-corp |
|
The security policy permits traffic from the vpn zone to the trust zone. |
from-corp |
Match criteria:
|
|
The security policy permits traffic from the untrust zone to the trust zone. |
permit-any |
Match criteria:
|
Purpose |
Configuration Parameters |
|---|---|
TCC-MSS is negotiated as part of the TCP three-way handshake and limits the maximum size of a TCP segment to better fit the MTU limits on a network. For VPN traffic, 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, which causes fragmentation. Fragmentation results in increased use of bandwidth and device resources. The value of 1350 is a recommended starting point for most Ethernet-based networks with an MTU of 1500 or greater. You might need to experiment with different TCP-MSS values to obtain optimal performance. For example, you might need to change the value if any device in the path has a lower MTU, or if there is any additional overhead such as PPP or Frame Relay. |
MSS value: 1350 |
Configuration
- Configuring Basic Network, Security Zone, and Address Book Information for the Hub
- Configuring IKE for the Hub
- Configuring IPsec for the Hub
- Configuring Security Policies for the Hub
- Configuring TCP-MSS for the Hub
- Configuring Basic Network, Security Zone, and Address Book Information for the Westford Spoke
- Configuring IKE for the Westford Spoke
- Configuring IPsec for the Westford Spoke
- Configuring Security Policies for the Westford Spoke
- Configuring TCP-MSS for the Westford Spoke
- Configuring the Sunnyvale Spoke
Configuring Basic Network, Security Zone, and Address Book Information for the Hub
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.
set interfaces ge-0/0/0 unit 0 family inet address 192.168.10.1/24 set interfaces ge-0/0/3 unit 0 family inet address 10.1.1.2/30 set interfaces st0 unit 0 family inet address 10.11.11.10/24 set routing-options static route 0.0.0.0/0 next-hop 10.1.1.1 set routing-options static route 192.168.168.0/24 next-hop 10.11.11.11 set routing-options static route 192.168.178.0/24 next-hop 10.11.11.12 set security zones security-zone untrust interfaces ge-0/0/3.0 set security zones security-zone untrust host-inbound-traffic system-services ike set security zones security-zone trust interfaces ge-0/0/0.0 set security zones security-zone trust host-inbound-traffic system-services all set security zones security-zone vpn interfaces st0.0 set security address-book book1 address local-net 192.168.10.0/24 set security address-book book1 attach zone trust set security address-book book2 address sunnyvale-net 192.168.168.0/24 set security address-book book2 address westford-net 192.168.178.0/24 set security address-book book2 attach zone vpn
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure basic network, security zone, and address book information for the hub:
Configure Ethernet interface information.
[edit] user@hub# set interfaces ge-0/0/0 unit 0 family inet address 192.168.10.1/24 user@hub# set interfaces ge-0/0/3 unit 0 family inet address 10.1.1.2/30 user@hub# set interfaces st0 unit 0 family inet address 10.11.11.10/24
Configure static route information.
[edit] user@hub# set routing-options static route 0.0.0.0/0 next-hop 10.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
Configure the untrust security zone.
[edit ] user@hub# set security zones security-zone untrust
Assign an interface to the untrust security zone.
[edit security zones security-zone untrust] user@hub# set interfaces ge-0/0/3.0
Specify allowed system services for the untrust security zone.
[edit security zones security-zone untrust] user@hub# set host-inbound-traffic system-services ike
Configure the trust security zone.
[edit] user@hub# edit security zones security-zone trust
Assign an interface to the trust security zone.
[edit security zones security-zone trust] user@hub# set interfaces ge-0/0/0.0
Specify allowed system services for the trust security zone.
[edit security zones security-zone trust] user@hub# set host-inbound-traffic system-services all
Create an address book and attach a zone to it.
[edit security address-book book1] user@hub# set address local-net 10.10.10.0/24 user@hub# set attach zone trust
Configure the vpn security zone.
[edit] user@hub# edit security zones security-zone vpn
Assign an interface to the vpn security zone.
[edit security zones security-zone vpn] user@hub# set interfaces st0.0
Create another address book and attach a zone to it.
[edit security address-book book2] user@hub# set address sunnyvale-net 192.168.168.0/24 user@hub# set address westford-net 192.168.178.0/24 user@hub# set attach zone vpn
Results
From configuration mode, confirm your configuration
by entering the show interfaces, show routing-options, show security zones, and show security address-book commands. If the output does not display the intended configuration,
repeat the configuration instructions in this example to correct it.
[edit]
user@hub# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 192.168.10.1/24;
}
}
}
ge-0/0/3 {
unit 0 {
family inet {
address 10.1.1.2/30
}
}
}
st0{
unit 0 {
family inet {
address 10.11.11.10/24
}
}
}
[edit]
user@hub# show routing-options
static {
route 0.0.0.0/0 next-hop 10.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;
}
[edit]
user@hub# show security zones
security-zone untrust {
host-inbound-traffic {
system-services {
ike;
}
}
interfaces {
ge-0/0/3.0;
}
}
security-zone trust {
host-inbound-traffic {
system-services {
all;
}
}
interfaces {
ge-0/0/0.0;
}
}
security-zone vpn {
host-inbound-traffic {
}
interfaces {
st0.0;
}
}
[edit]
user@hub# show security address-book
book1 {
address local-net 10.10.10.0/24;
attach {
zone trust;
}
}
book2 {
address sunnyvale-net 192.168.168.0/24;
address westford-net 192.168.178.0/24;
attach {
zone vpn;
}
}
If you are done configuring the device, enter commit from configuration mode.
Configuring IKE for the Hub
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.
set security ike proposal ike-phase1-proposal authentication-method pre-shared-keys set security ike proposal ike-phase1-proposal dh-group group2 set security ike proposal ike-phase1-proposal authentication-algorithm sha1 set security ike proposal ike-phase1-proposal encryption-algorithm aes-128-cbc set security ike policy ike-phase1-policy mode main set security ike policy ike-phase1-policy proposals ike-phase1-proposal set security ike policy ike-phase1-policy pre-shared-key ascii-text “$ABC123” set security ike gateway gw-westford external-interface ge-0/0/3.0 set security ike gateway gw-westford ike-policy ike-phase1-policy set security ike gateway gw-westford address 10.3.3.2 set security ike gateway gw-sunnyvale external-interface ge-0/0/3.0 set security ike gateway gw-sunnyvale ike-policy ike-phase1-policy set security ike gateway gw-sunnyvale address 10.2.2.2
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure IKE for the hub:
Create the IKE Phase 1 proposal.
[edit security ike] user@hub# set proposal ike-phase1-proposal
Define the IKE proposal authentication method.
[edit security ike proposal ike-phase1-proposal] user@hub# set authentication-method pre-shared-keys
Define the IKE proposal Diffie-Hellman group.
[edit security ike proposal ike-phase1-proposal] user@hub# set dh-group group2
Define the IKE proposal authentication algorithm.
[edit security ike proposal ike-phase1-proposal] user@hub# set authentication-algorithm sha1
Define the IKE proposal encryption algorithm.
[edit security ike proposal ike-phase1-proposal] user@hub# set encryption-algorithm aes-128-cbc
Create an IKE Phase 1 policy.
[edit security ike] user@hub# set policy ike-phase1-policy
Set the IKE Phase 1 policy mode.
[edit security ike policy ike-phase1-policy] user@hub# set mode main
Specify a reference to the IKE proposal.
[edit security ike policy ike-phase1-policy] user@hub# set proposals ike-phase1-proposal
Define the IKE Phase 1 policy authentication method.
[edit security ike policy ike-phase1-policy] user@hub# set pre-shared-key ascii-text “$ABC123”
Create an IKE Phase 1 gateway and define its external interface.
[edit security ike] user@hub# set gateway gw-westford external-interface ge-0/0/3.0
Define the IKE Phase 1 policy reference.
[edit security ike] user@hub# set gateway gw-westford ike-policy ike-phase1-policy
Define the IKE Phase 1 gateway address.
[edit security ike] user@hub# set gateway gw-westford address 10.3.3.2
Create an IKE Phase 1 gateway and define its external interface.
[edit security ike] user@hub# set gateway gw-sunnyvale external-interface ge-0/0/3.0
Define the IKE Phase 1 policy reference.
[edit security ike gateway] user@hub# set gateway gw-sunnyvale ike-policy ike-phase1-policy
Define the IKE Phase 1 gateway address.
[edit security ike gateway] user@hub# set gateway gw-sunnyvale address 10.2.2.2
Results
From configuration mode, confirm your configuration
by entering the show security ike command. If the output
does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
[edit]
user@hub# show security ike
proposal ike-phase1-proposal {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;
}
policy ike-phase1-policy {
mode main;
proposals ike-phase1-proposal;
pre-shared-key ascii-text "$ABC123"; ## SECRET-DATA
}
gateway gw-sunnyvale {
ike-policy ike-phase1-policy;
address 10.2.2.2;
external-interface ge-0/0/3.0;
}
gateway gw-westford {
ike-policy ike-phase1-policy;
address 10.3.3.2;
external-interface ge-0/0/3.0;
}
If you are done configuring the device, enter commit from configuration mode.
Configuring IPsec for the Hub
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.
set security ipsec proposal ipsec-phase2-proposal protocol esp set security ipsec proposal ipsec-phase2-proposal authentication-algorithm hmac-sha1-96 set security ipsec proposal ipsec-phase2-proposal encryption-algorithm aes-128-cbc set security ipsec policy ipsec-phase2-policy proposals ipsec-phase2-proposal set security ipsec policy ipsec-phase2-policy perfect-forward-secrecy keys group2 set security ipsec vpn vpn-westford ike gateway gw-westford set security ipsec vpn vpn-westford ike ipsec-policy ipsec-phase2-policy set security ipsec vpn vpn-westford bind-interface st0.0 set security ipsec vpn vpn-sunnyvale ike gateway gw-sunnyvale set security ipsec vpn vpn-sunnyvale ike ipsec-policy ipsec-phase2-policy set security ipsec vpn vpn-sunnyvale bind-interface st0.0 set interfaces st0 unit 0 multipoint set interfaces st0 unit 0 family inet next-hop-tunnel 10.11.11.11 ipsec-vpn vpn-sunnyvale set interfaces st0 unit 0 family inet next-hop-tunnel 10.11.11.12 ipsec-vpn vpn-westford
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure IPsec for the hub:
Create an IPsec Phase 2 proposal.
[edit] user@hub# set security ipsec proposal ipsec-phase2-proposal
Specify the IPsec Phase 2 proposal protocol.
[edit security ipsec proposal ipsec-phase2-proposal] user@hub# set protocol esp
Specify the IPsec Phase 2 proposal authentication algorithm.
[edit security ipsec proposal ipsec-phase2-proposal] user@hub# set authentication-algorithm hmac-sha1-96
Specify the IPsec Phase 2 proposal encryption algorithm.
[edit security ipsec proposal ipsec-phase2-proposal] user@hub# set encryption-algorithm aes-128-cbc
Create the IPsec Phase 2 policy.
[edit security ipsec] user@hub# set policy ipsec-phase2-policy
Specify the IPsec Phase 2 proposal reference.
[edit security ipsec policy ipsec-phase2-policy] user@hub# set proposals ipsec-phase2-proposal
Specify IPsec Phase 2 PFS to use Diffie-Hellman group 2.
[edit security ipsec policy ipsec-phase2-policy] user@host# set perfect-forward-secrecy keys group2
Specify the IKE gateways.
[edit security ipsec] user@hub# set vpn vpn-westford ike gateway gw-westford user@hub# set vpn vpn-sunnyvale ike gateway gw-sunnyvale
Specify the IPsec Phase 2 policies.
[edit security ipsec] user@hub# set vpn vpn-westford ike ipsec-policy ipsec-phase2-policy user@hub# set vpn vpn-sunnyvale ike ipsec-policy ipsec-phase2-policy
Specify the interface to bind.
[edit security ipsec] user@hub# set vpn vpn-westford bind-interface st0.0 user@hub# set vpn vpn-sunnyvale bind-interface st0.0
Configure the st0 interface as multipoint.
[edit] user@hub# set interfaces st0 unit 0 multipoint
Add static NHTB table entries for the Sunnyvale and Westford offices.
[edit] user@hub# set interfaces st0 unit 0 family inet next-hop-tunnel 10.11.11.11 ipsec-vpn vpn-sunnyvale user@hub# set interfaces st0 unit 0 family inet next-hop-tunnel 10.11.11.12 ipsec-vpn vpn-westford
Results
From configuration mode, confirm your configuration
by entering the show security ipsec command. If the output
does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
[edit]
user@hub# show security ipsec
proposal ipsec-phase2-proposal {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;
}
policy ipsec-phase2-policy {
perfect-forward-secrecy {
keys group2;
}
proposals ipsec-phase2-proposal;
}
vpn vpn-sunnyvale {
bind-interface st0.0;
ike {
gateway gw-sunnyvale;
ipsec-policy ipsec-phase2-policy;
}
}
vpn vpn-westford {
bind-interface st0.0;
ike {
gateway gw-westford;
ipsec-policy ipsec-phase2-policy;
}
}
If you are done configuring the device, enter commit from configuration mode.
Configuring Security Policies for the Hub
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.
set security policies from-zone trust to-zone vpn policy local-to-spokes match source-address local-net set security policies from-zone trust to-zone vpn policy local-to-spokes match destination-address sunnyvale-net set security policies from-zone trust to-zone vpn policy local-to-spokes match destination-address westford-net set security policies from-zone trust to-zone vpn policy local-to-spokes match application any set security policies from-zone trust to-zone vpn policy local-to-spokes then permit set security policies from-zone vpn to-zone trust policy spokes-to-local match source-address sunnyvale-net set security policies from-zone vpn to-zone trust policy spokes-to-local match source-address westford-net set security policies from-zone vpn to-zone trust policy spokes-to-local match destination-address local-net set security policies from-zone vpn to-zone trust policy spokes-to-local match application any set security policies from-zone vpn to-zone trust policy spokes-to-local then permit set security policies from-zone vpn to-zone vpn policy spoke-to-spoke match source-address any set security policies from-zone vpn to-zone vpn policy spoke-to-spoke match destination-address any set security policies from-zone vpn to-zone vpn policy spoke-to-spoke match application any set security policies from-zone vpn to-zone vpn policy spoke-to-spoke then permit
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure security policies for the hub:
Create the security policy to permit traffic from the trust zone to the vpn zone.
[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
Create the security policy to permit traffic from the vpn zone to the trust zone.
[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
Create the security policy to permit intrazone traffic.
[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
Results
From configuration mode, confirm your configuration
by entering the show security policies command. If the
output does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
[edit]
user@hub# show security policies
from-zone trust to-zone vpn {
policy local-to-spokes {
match {
source-address local-net;
destination-address [ sunnyvale-net westford-net ];
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;
}
}
}
If you are done configuring the device, enter commit from configuration mode.
Configuring TCP-MSS for the Hub
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.
set security flow tcp-mss ipsec-vpn mss 1350
Step-by-Step Procedure
To configure TCP-MSS information for the hub:
Configure TCP-MSS information.
[edit] user@hub# set security flow tcp-mss ipsec-vpn mss 1350
Results
From configuration mode, confirm your configuration
by entering the show security flow command. If the output
does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
[edit]
user@hub# show security flow
tcp-mss {
ipsec-vpn {
mss 1350;
}
}
If you are done configuring the device, enter commit from configuration mode.
Configuring Basic Network, Security Zone, and Address Book Information for the Westford Spoke
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.
set interfaces ge-0/0/0 unit 0 family inet address 10.3.3.2/30 set interfaces ge-0/0/3 unit 0 family inet address 192.168.178.1/24 set interfaces st0 unit 0 family inet address 10.11.11.12/24 set routing-options static route 0.0.0.0/0 next-hop 10.3.3.1 set routing-options static route 10.10.10.0/24 next-hop 10.11.11.10 set routing-options static route 192.168.168.0/24 next-hop 10.11.11.10 set security zones security-zone untrust interfaces ge-0/0/0.0 set security zones security-zone untrust host-inbound-traffic system-services ike set security zones security-zone trust interfaces ge-0/0/3.0 set security zones security-zone trust host-inbound-traffic system-services all set security zones security-zone vpn interfaces st0.0 set security address-book book1 address local-net 192.168.178.0/24 set security address-book book1 attach zone trust set security address-book book2 address corp-net 10.10.10.0/24 set security address-book book2 address sunnyvale-net 192.168.168.0/24 set security address-book book2 attach zone vpn
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure basic network, security zone, and address book information for the Westford spoke:
Configure Ethernet interface information.
[edit] user@spoke# set interfaces ge-0/0/0 unit 0 family inet address 10.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
Configure static route information.
[edit] user@spoke# set routing-options static route 0.0.0.0/0 next-hop 10.3.3.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
Configure the untrust security zone.
[edit] user@spoke# set security zones security-zone untrust
Assign an interface to the security zone.
[edit security zones security-zone untrust] user@spoke# set interfaces ge-0/0/0.0
Specify allowed system services for the untrust security zone.
[edit security zones security-zone untrust] user@spoke# set host-inbound-traffic system-services ike
Configure the trust security zone.
[edit] user@spoke# edit security zones security-zone trust
Assign an interface to the trust security zone.
[edit security zones security-zone trust] user@spoke# set interfaces ge-0/0/3.0
Specify allowed system services for the trust security zone.
[edit security zones security-zone trust] user@spoke# set host-inbound-traffic system-services all
Configure the vpn security zone.
[edit] user@spoke# edit security zones security-zone vpn
Assign an interface to the vpn security zone.
[edit security zones security-zone vpn] user@spoke# set interfaces st0.0
Create an address book and attach a zone to it.
[edit security address-book book1] user@spoke# set address local-net 192.168.178.0/24 user@spoke# set attach zone trust
Create another address book and attach a zone to it.
[edit security address-book book2] user@spoke# set address corp-net 10.10.10.0/24 user@spoke# set address sunnyvale-net 192.168.168.0/24 user@spoke# set attach zone vpn
Results
From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, show security zones, and show security address-book commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
[edit]
user@spoke# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.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.10/24;
}
}
}
[edit]
user@spoke# show routing-options
static {
route 0.0.0.0/0 next-hop 10.3.3.1;
route 192.168.168.0/24 next-hop 10.11.11.10;
route 10.10.10.0/24 next-hop 10.11.11.10;
}
[edit]
user@spoke# show security zones
security-zone untrust {
host-inbound-traffic {
system-services {
ike;
}
}
interfaces {
ge-0/0/0.0;
}
}
security-zone trust {
host-inbound-traffic {
system-services {
all;
}
}
interfaces {
ge-0/0/3.0;
}
}
security-zone vpn {
interfaces {
st0.0;
}
}
[edit]
user@spoke# show security address-book
book1 {
address corp-net 10.10.10.0/24;
attach {
zone trust;
}
}
book2 {
address local-net 192.168.178.0/24;
address sunnyvale-net 192.168.168.0/24;
attach {
zone vpn;
}
}
If you are done configuring the device, enter commit from configuration mode.
Configuring IKE for the Westford Spoke
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.
set security ike proposal ike-phase1-proposal authentication-method pre-shared-keys set security ike proposal ike-phase1-proposal dh-group group2 set security ike proposal ike-phase1-proposal authentication-algorithm sha1 set security ike proposal ike-phase1-proposal encryption-algorithm aes-128-cbc set security ike policy ike-phase1-policy mode main set security ike policy ike-phase1-policy proposals ike-phase1-proposal set security ike policy ike-phase1-policy pre-shared-key ascii-text “$ABC123” set security ike gateway gw-corporate external-interface ge-0/0/0.0 set security ike gateway gw-corporate ike-policy ike-phase1-policy set security ike gateway gw-corporate address 10.1.1.2
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure IKE for the Westford spoke:
Create the IKE Phase 1 proposal.
[edit security ike] user@spoke# set proposal ike-phase1-proposal
Define the IKE proposal authentication method.
[edit security ike proposal ike-phase1-proposal] user@spoke# set authentication-method pre-shared-keys
Define the IKE proposal Diffie-Hellman group.
[edit security ike proposal ike-phase1-proposal] user@spoke# set dh-group group2
Define the IKE proposal authentication algorithm.
[edit security ike proposal ike-phase1-proposal] user@spoke# set authentication-algorithm sha1
Define the IKE proposal encryption algorithm.
[edit security ike proposal ike-phase1-proposal] user@spoke# set encryption-algorithm aes-128-cbc
Create an IKE Phase 1 policy.
[edit security ike] user@spoke# set policy ike-phase1-policy
Set the IKE Phase 1 policy mode.
[edit security ike policy ike-phase1-policy] user@spoke# set mode main
Specify a reference to the IKE proposal.
[edit security ike policy ike-phase1-policy] user@spoke# set proposals ike-phase1-proposal
Define the IKE Phase 1 policy authentication method.
[edit security ike policy ike-phase1-policy] user@spoke# set pre-shared-key ascii-text “$ABC123”
Create an IKE Phase 1 gateway and define its external interface.
[edit security ike] user@spoke# set gateway gw-corporate external-interface ge-0/0/0.0
Define the IKE Phase 1 policy reference.
[edit security ike] user@spoke# set gateway gw-corporate ike-policy ike-phase1-policy
Define the IKE Phase 1 gateway address.
[edit security ike] user@spoke# set gateway gw-corporate address 10.1.1.2
Results
From configuration mode, confirm your configuration
by entering the show security ike command. If the output
does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
[edit]
user@spoke# show security ike
proposal ike-phase1-proposal {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;
}
policy ike-phase1-policy {
mode main;
proposals ike-phase1-proposal;
pre-shared-key ascii-text "$ABC123"; ## SECRET-DATA
}
gateway gw-corporate {
ike-policy ike-phase1-policy;
address 10.1.1.2;
external-interface ge-0/0/0.0;
}
If you are done configuring the device, enter commit from configuration mode.
Configuring IPsec for the Westford Spoke
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.
set security ipsec proposal ipsec-phase2-proposal protocol esp set security ipsec proposal ipsec-phase2-proposal authentication-algorithm hmac-sha1-96 set security ipsec proposal ipsec-phase2-proposal encryption-algorithm aes-128-cbc set security ipsec policy ipsec-phase2-policy proposals ipsec-phase2-proposal set security ipsec policy ipsec-phase2-policy perfect-forward-secrecy keys group2 set security ipsec vpn vpn-corporate ike gateway gw-corporate set security ipsec vpn vpn-corporate ike ipsec-policy ipsec-phase2-policy set security ipsec vpn vpn-corporate bind-interface st0.0
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure IPsec for the Westford spoke:
Create an IPsec Phase 2 proposal.
[edit] user@spoke# set security ipsec proposal ipsec-phase2-proposal
Specify the IPsec Phase 2 proposal protocol.
[edit security ipsec proposal ipsec-phase2-proposal] user@spoke# set protocol esp
Specify the IPsec Phase 2 proposal authentication algorithm.
[edit security ipsec proposal ipsec-phase2-proposal] user@spoke# set authentication-algorithm hmac-sha1-96
Specify the IPsec Phase 2 proposal encryption algorithm.
[edit security ipsec proposal ipsec-phase2-proposal] user@spoke# set encryption-algorithm aes-128-cbc
Create the IPsec Phase 2 policy.
[edit security ipsec] user@spoke# set policy ipsec-phase2-policy
Specify the IPsec Phase 2 proposal reference.
[edit security ipsec policy ipsec-phase2-policy] user@spoke# set proposals ipsec-phase2-proposal
Specify IPsec Phase 2 PFS to use Diffie-Hellman group 2.
[edit security ipsec policy ipsec-phase2-policy] user@host# set perfect-forward-secrecy keys group2
Specify the IKE gateway.
[edit security ipsec] user@spoke# set vpn vpn-corporate ike gateway gw-corporate
Specify the IPsec Phase 2 policy.
[edit security ipsec] user@spoke# set vpn vpn-corporate ike ipsec-policy ipsec-phase2-policy
Specify the interface to bind.
[edit security ipsec] user@spoke# set vpn vpn-corporate bind-interface st0.0
Results
From configuration mode, confirm your configuration
by entering the show security ipsec command. If the output
does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
[edit]
user@spoke# show security ipsec
proposal ipsec-phase2-proposal {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;
}
policy ipsec-phase2-policy {
perfect-forward-secrecy {
keys group2;
}
proposals ipsec-phase2-proposal;
}
vpn vpn-corporate {
bind-interface st0.0;
ike {
gateway gw-corporate;
ipsec-policy ipsec-phase2-policy;
}
}
If you are done configuring the device, enter commit from configuration mode.
Configuring Security Policies for the Westford Spoke
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.
set security policies from-zone trust to-zone vpn policy to-corporate match source-address local-net set security policies from-zone trust to-zone vpn policy to-corporate match destination-address corp-net set security policies from-zone trust to-zone vpn policy to-corporate match destination-address sunnyvale-net set security policies from-zone trust to-zone vpn policy to-corporate application any set security policies from-zone trust to-zone vpn policy to-corporate then permit set security policies from-zone vpn to-zone trust policy from-corporate match source-address corp-net set security policies from-zone vpn to-zone trust policy from-corporate match source-address sunnyvale-net set security policies from-zone vpn to-zone trust policy from-corporate match destination-address local-net set security policies from-zone vpn to-zone trust policy from-corporate application any set security policies from-zone vpn to-zone trust policy from-corporate then permit
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure security policies for the Westford spoke:
Create the security policy to permit traffic from the trust zone to the vpn zone.
[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
Create the security policy to permit traffic from the vpn zone to the trust zone.
[edit security policies from-zone vpn to-zone trust] user@spoke# set policy spokes-to-local match source-address corp-net user@spoke# set policy spokes-to-local match source-address sunnyvale-net user@spoke# set policy spokes-to-local match destination-address local-net user@spoke# set policy spokes-to-local match application any user@spoke# set policy spokes-to-local then permit
Results
From configuration mode, confirm your configuration
by entering the show security policies command. If the
output does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
[edit]
user@spoke# show security policies
from-zone trust to-zone vpn {
policy to-corp {
match {
source-address local-net;
destination-address [ sunnyvale-net westford-net ];
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;
}
}
}
If you are done configuring the device, enter commit from configuration mode.
Configuring TCP-MSS for the Westford Spoke
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration mode.
set security flow tcp-mss ipsec-vpn mss 1350
Step-by-Step Procedure
To configure TCP-MSS for the Westford spoke:
Configure TCP-MSS information.
[edit] user@spoke# set security flow tcp-mss ipsec-vpn mss 1350
Results
From configuration mode, confirm your configuration
by entering the show security flow command. If the output
does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
[edit]
user@spoke# show security flow
tcp-mss {
ipsec-vpn {
mss 1350;
}
}
If you are done configuring the device, enter commit from configuration mode.
Configuring the Sunnyvale Spoke
CLI Quick Configuration
This example uses an SSG Series device for the Sunnyvale spoke. For reference, the configuration for the SSG Series device is provided. For information about configuring SSG Series devices, see the Concepts and Examples ScreenOS Reference Guide, which is located at https://www.juniper.net/documentation.
To quickly configure this section of the example, copy the following
commands, paste them into a text file, remove any line breaks, change
any details necessary to match your network configuration, copy and
paste the commands into the CLI at the [edit] hierarchy
level, and then enter commit from configuration
mode.
set zone name "VPN" set interface ethernet0/6 zone "Trust" 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 10.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 10.1.1.2 Main outgoing-interface ethernet0/0 preshare "395psksecr3t" sec-level standard set vpn corp-vpn monitor optimized rekey set vpn "corp-vpn" bind interface tunnel.1 set vpn "corp-vpn" gateway "corp-ike" replay tunnel idletime 0 sec-level standard 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 exit set dst-address "westford-net" exit set policy id 3 from "VPN" to "Trust" "corp-net" "sunnyvale-net" "ANY" permit set policy id 3 set src-address "westford-net" exit 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 10.2.2.1
Verification
To confirm that the configuration is working properly, perform these tasks:
- Verifying the IKE Phase 1 Status
- Verifying the IPsec Phase 2 Status
- Verifying Next-Hop Tunnel Bindings
- Verifying Static Routes for Remote Peer Local LANs
- Reviewing Statistics and Errors for an IPsec Security Association
- Testing Traffic Flow Across the VPN
Verifying the IKE Phase 1 Status
Purpose
Verify the IKE Phase 1 status.
Action
Before starting the verification process, you need to send traffic from a host in the 192.168.10/24 network to a host in the 192.168.168/24 and 192.168.178/24 networks to bring the tunnels up. For route-based VPNs, you can send traffic initiated from the SRX Series Firewall through the tunnel. We recommend that when testing IPsec tunnels, you send test traffic from a separate device on one side of the VPN to a second device on the other side of the VPN. For example, initiate a ping from 192.168.10.10 to 192.168.168.10.
From operational mode, enter the show security ike security-associations command. After obtaining an index number from the command, use the show security ike security-associations index index_number detail command.
user@hub> show security ike security-associations Index Remote Address State Initiator cookie Responder cookie Mode 6 10.3.3.2 UP 94906ae2263bbd8e 1c35e4c3fc54d6d3 Main 7 10.2.2.2 UP 7e7a1c0367dfe73c f284221c656a5fbc Main
user@hub> show security ike security-associations index 6 detail
IKE peer 10.3.3.2, Index 6,
Role: Responder, State: UP
Initiator cookie: 94906ae2263bbd8e,, Responder cookie: 1c35e4c3fc54d6d3
Exchange type: Main, Authentication method: Pre-shared-keys
Local: 10.1.1.2:500, Remote: 10.3.3.2:500
Lifetime: Expires in 3571 seconds
Algorithms:
Authentication : sha1
Encryption : aes-cbc (128 bits)
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: 10.1.1.2:500, Remote: 10.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 doneMeaning
The show security ike security-associations command lists all active IKE Phase 1 SAs. If no SAs are listed,
there was a problem with Phase 1 establishment. Check the IKE policy
parameters and external interface settings in your configuration.
If SAs are listed, review the following information:
Index—This value is unique for each IKE SA, which you can use in the
show security ike security-associations index detailcommand to get more information about the SA.Remote Address—Verify that the remote IP address is correct.
State
UP—The Phase 1 SA has been established.
DOWN—There was a problem establishing the Phase 1 SA.
Mode—Verify that the correct mode is being used.
Verify that the following information is correct in your configuration:
External interfaces (the interface must be the one that receives IKE packets)
IKE policy parameters
Preshared key information
Phase 1 proposal parameters (must match on both peers)
The show security ike security-associations index 1 detail command lists additional information about the security association
with an index number of 1:
Authentication and encryption algorithms used
Phase 1 lifetime
Traffic statistics (can be used to verify that traffic is flowing properly in both directions)
Initiator and responder role information
Troubleshooting is best performed on the peer using the responder role.
Number of IPsec SAs created
Number of Phase 2 negotiations in progress
Verifying the IPsec Phase 2 Status
Purpose
Verify the IPsec Phase 2 status.
Action
From operational mode, enter the show security
ipsec security-associations command. After obtaining an index
number from the command, use the show security ipsec security-associations
index index_number detail command.
user@hub> show security ipsec security-associations total configured sa: 4 ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys <16384 10.2.2.2 500 ESP:aes-128/sha1 b2fc36f8 3364/ unlim - 0 >16384 10.2.2.2 500 ESP:aes-128/sha1 5d73929e 3364/ unlim - 0 ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys <16385 10.3.3.2 500 ESP:3des/sha1 70f789c6 28756/unlim - 0 >16385 10.3.3.2 500 ESP:3des/sha1 80f4126d 28756/unlim - 0
user@hub> show security ipsec security-associations index 16385 detail
Virtual-system: Root
Local Gateway: 10.1.1.2, Remote Gateway: 10.3.3.2
Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/24)
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: aes-cbc (128 bits)
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: aes-cbc (128 bits)
Anti-replay service: enabled, Replay window size: 32
Meaning
The output from the show security ipsec security-associations command lists the following information:
The ID number is 16385. Use this value with the
show security ipsec security-associations indexcommand to get more information about this particular SA.There is one IPsec SA pair using port 500, which indicates that no NAT-traversal is implemented. (NAT-traversal uses port 4500 or another random high-number port.)
The SPIs, lifetime (in seconds), and usage limits (or lifesize in KB) are shown for both directions. The 28756/ unlim value indicates that the Phase 2 lifetime expires in 28756 seconds, and that no lifesize has been specified, which indicates that it is unlimited. Phase 2 lifetime can differ from Phase 1 lifetime, as Phase 2 is not dependent on Phase 1 after the VPN is up.
VPN monitoring is not enabled for this SA, as indicated by a hyphen in the Mon column. If VPN monitoring is enabled, U indicates that monitoring is up, and D indicates that monitoring is down.
The virtual system (vsys) is the root system, and it always lists 0.
The output from the show security ipsec security-associations
index 16385 detail command lists the following information:
The local identity and remote identity make up the proxy ID for the SA.
A proxy ID mismatch is one of the most common causes for a Phase 2 failure. If no IPsec SA is listed, confirm that Phase 2 proposals, including the proxy ID settings, are correct for both peers. For route-based VPNs, the default proxy ID is local=0.0.0.0/0, remote=0.0.0.0/0, and service=any. Issues can occur with multiple route-based VPNs from the same peer IP. In this case, a unique proxy ID for each IPsec SA must be specified. For some third-party vendors, the proxy ID must be manually entered to match.
Another common reason for Phase 2 failure is not specifying the ST interface binding. If IPsec cannot complete, check the kmd log or set trace options.
Verifying Next-Hop Tunnel Bindings
Purpose
After Phase 2 is complete for all peers, verify the next-hop tunnel bindings.
Action
From operational mode, enter the show security
ipsec next-hop-tunnels command.
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
Meaning
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. If no NHTB entry exists, there is no way for the hub device to differentiate which IPsec VPN is associated with which next hop.
The Flag field has one of the following values:
Static— NHTB was manually configured in the st0.0 interface configurations, which is required if the peer is not an SRX Series Firewall.
Auto— NHTB was not configured, but the entry was automatically populated into the NHTB table during Phase 2 negotiations between two SRX Series Firewalls
There is no NHTB table for any of the spoke sites in this example. From the spoke perspective, the st0 interface is still a point-to-point link with only one IPsec VPN binding.
Verifying Static Routes for Remote Peer Local LANs
Purpose
Verify that the static route references the spoke peer’s st0 IP address.
Action
From operational mode, enter the show route command.
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.0user@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.0The next hop is the remote peer’s st0 IP address, and both routes point to st0.0 as the outgoing interface.
Reviewing Statistics and Errors for an IPsec Security Association
Purpose
Review ESP and authentication header counters and errors for an IPsec security association.
Action
From operational mode, enter the show security
ipsec statistics index command.
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
You can also use the show security ipsec statistics command to review statistics and errors for all SAs.
To clear all IPsec statistics, use the clear security ipsec
statistics command.
Meaning
If you see packet loss issues across a VPN, you can
run the show security ipsec statistics or show security
ipsec statistics detail command several times to confirm that
the encrypted and decrypted packet counters are incrementing. You
should also check whether the other error counters are incrementing.
Testing Traffic Flow Across the VPN
Purpose
Verify the traffic flow across the VPN.
Action
You can use the ping command from the SRX Series Firewall to test traffic flow
to a remote host PC. Make sure that you specify the source interface so that
the route lookup is correct and the appropriate security zones are
referenced during policy lookup.
From operational mode, enter the ping command.
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 ms 64 bytes from 192.168.168.10: icmp_seq=1 ttl=127 time=4.119 ms 64 bytes from 192.168.168.10: icmp_seq=2 ttl=127 time=5.399 ms 64 bytes from 192.168.168.10: icmp_seq=3 ttl=127 time=4.361 ms 64 bytes from 192.168.168.10: icmp_seq=4 ttl=127 time=5.137 ms --- 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
You can also use the ping command from the SSG Series
device.
user@hub> ping 192.168.10.10 from ethernet0/6 Type escape sequence to abort Sending 5, 100-byte ICMP Echos to 192.168.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
ssg-> 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
Meaning
If the ping command fails from the SRX Series
or SSG Series device, there might be a problem with the routing, security
policies, end host, or encryption and decryption of ESP packets.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
container-string and wildcard-string at [edit security ike gateway gateway_name dynamic
distinguished-name] hierarchy. If you try configuring the second
attribute after you configure the first attribute, the first attribute
is replaced with the second attribute. Before your upgrade your device,
you must remove one of the attributes if you have configured both
the attributes.