[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

Configuring IPSec

To implement IPSec, complete the following configuration procedures:

Considering General IPSec Issues

Before you configure IPSec, it is helpful to understand some general guidelines.

Table 52: Comparison of IPSec Configuration Statements and Operational Mode Commands for the AS and MultiServices PICs and ES PIC

AS and MultiServices PICs Statements and Commands

ES PIC Statements and Commands
Configuration Mode Statements

[edit service-set name ]

–

[edit services ipsec-vpn ike]

  • policy {...}
  • proposal {...}

[edit security ike]

  • policy {...}
  • proposal {...}

[edit services ipsec-vpn ipsec]

  • policy {...}
  • proposal {...}

[edit security ipsec]

  • policy {...}
  • proposal {...}

[edit services ipsec-vpn rule rule-name ]

  • remote-gateway address

[edit interface es- fpc / pic /port ]

  • tunnel destination address

[edit services ipsec-vpn rule rule-name term term-name]

  • from match-conditions {...}
    then dynamic {...}
  • from match-conditions {...}
    then manual {...}

[edit security ipsec]

  • security-association name dynamic {...}
  • security-association name manual {...}

[edit services ipsec-vpn rule-set]

–

[edit services service-set ipsec-vpn]

  • local-gateway address

[edit interface es- fpc /pic /port ]

  • tunnel source address
Operational Mode Commands

clear security pki ca-certificate

–

clear security pki certificate-request

–

clear security pki local-certificate

–

clear services ipsec-vpn certificates

–

request security pki ca-certificate enroll

request security certificate (unsigned)

request security pki ca-certificate load

request system certificate add

request security pki generate-certificate-request

–

request security pki generate-key-pair

request security key-pair

request security pki local-certificate enroll

request security certificate (signed)

request security pki local-certificate load

request system certificate add

show security pki ca-certificate

show system certificate

show security pki certificate-request

–

show security pki crl

–

show security pki local-certificate

show system certificate

show services ipsec-vpn certificates

show ipsec certificates

show services ipsec-vpn ike security-associations

show ike security-associations

show services ipsec-vpn ipsec security-associations

show ipsec security-associations

Table 53: Authentication and Encryption Key Lengths

 

Number of
Hexadecimal Characters

Number of ASCII Characters

Authentication

    

HMAC-MD5-96

32

16

HMAC-SHA1-96

40

20

Encryption

    

AES-128-CBC

16

32

AES-192-CBC

24

48

AES-256-CBC

32

64

DES-CBC

16

8

3DES-CBC

48

24

Table 54: Weak and Semiweak Keys

Weak Keys

      

0101

0101

0101

0101

1F1F

1F1F

1F1F

1F1F

E0E0

E0E0

E0E0

E0E0

FEFE

FEFE

FEFE

FEFE
Semiweak Keys

01FE

01FE

01FE

01FE

1FE0

1FE0

0EF1

0EF1

01E0

01E0

01F1

01F1

1FFE

1FFE

0EFE

0EFE

011F

011F

010E

010E

E0FE

E0FE

F1FE

F1FE

FE01

FE01

FE01

FE01

E01F

E01F

F10E

F10E

E001

E001

F101

F101

FEF1

FEF1

FE0E

FE0E

1F01

1F01

0E01

0E01

FEE0

FEE0

FEF1

FEF1

Keep in mind the following limitations of IPSec services on the AS PIC:

Configuring Security Associations

The first IPSec configuration step is to select a type of security association for your IPSec connection. You must statically configure all specifications for manual SAs, but you can rely on some defaults when you configure an IKE dynamic SA. To configure a security association, see the following sections.

Configuring Manual SAs

On the ES PIC, you configure a manual security association at the [edit security ipsec security-association name] hierarchy level. Include your choices for authentication, encryption, direction, mode, protocol, and SPI. Be sure that these choices are configured exactly the same way on the remote IPSec gateway.

[edit security]
ipsec {
security-association sa-name {
description description;
manual {
direction (inbound | outbound | bidirectional) {
authentication {
algorithm (hmac-md5-96 | hmac-sha1-96);
key (ascii-text key | hexadecimal key);
}
auxiliary-spi auxiliary-spi;
encryption {
algorithm (des-cbc | 3des-cbc);
key (ascii-text key | hexadecimal key);
}
protocol (ah | esp | bundle);
spi spi-value;
}
}
mode (tunnel | transport);
}
}

On the AS and MultiServices PICs, you configure a manual security association at the [edit services ipsec-vpn rule rule-name] hierarchy level. Include your choices for authentication, encryption, direction, protocol, and SPI. Be sure that these choices are configured exactly the same way on the remote IPSec gateway.

[edit services ipsec-vpn]
rule rule-name {
match-direction (input | output);
term term-name {
from {
destination-address address;
source-address address;
}
then {
backup-remote-gateway address;
clear-dont-fragment-bit;
manual {
direction (inbound | outbound | bidirectional) {
authentication {
algorithm (hmac-md5-96 | hmac-sha1-96);
key (ascii-text key | hexadecimal key);
}
auxiliary-spi spi-value;
encryption {
algorithm algorithm; # This can be aes-128-cbc, aes-192-cbc,
# aes-256-cbc, des-cbc, or 3des-cbc.
key (ascii-text key | hexadecimal key);
}
protocol (ah | bundle | esp);
spi spi-value;
}
}
no-anti-replay;
remote-gateway address;
syslog;
}
}
}
rule-set rule-set-name {
[ rule rule-names ];
}

Configuring IKE Dynamic SAs

On the ES PIC, you configure an IKE dynamic SA at the [edit security ike] and [edit security ipsec] hierarchy levels. Include your choices for IKE policies and proposals, which include options for authentication algorithms, authentication methods, Diffie-Hellman groups, encryption, IKE modes, and preshared keys. The IKE policy must use the IP address of the remote end of the IPSec tunnel as the policy name. Also, include your choices for IPSec policies and proposals, which include options for authentication, encryption, protocols, Perfect Forward Secrecy (PFS), and IPSec modes. Be sure that these choices are configured exactly the same way on the remote IPSec gateway.

[edit security]
ike {
proposal ike-proposal-name {
authentication-algorithm (md5 | sha1);
authentication-method (dsa-signatures | pre-shared-keys | rsa-signatures);
description description;
dh-group (group1 | group2);
encryption-algorithm (3des-cbc | des-cbc);
lifetime-seconds seconds;
}
policy ike-peer-address {
description description;
encoding (binary | pem);
identity identity-name;
local-certificate certificate-filename;
local-key-pair private-public-key-file;
mode (aggressive | main);
pre-shared-key (ascii-text key | hexadecimal key);
proposals [ proposal-names ];
}
}
ipsec {
proposal ipsec-proposal-name {
authentication-algorithm (hmac-md5-96 | hmac-sha1-96);
description description;
encryption-algorithm (3des-cbc | des-cbc);
lifetime-seconds seconds;
protocol (ah | esp | bundle);
}
policy ipsec-policy-name {
description description;
perfect-forward-secrecy {
keys (group1 | group2);
}
proposals [ proposal-names ];
}
security-association sa-name {
description description;
dynamic {
ipsec-policy policy-name;
replay-window-size (32 | 64);
}
mode (tunnel | transport);
}
}

On the AS and MultiServices PICs, you configure an IKE dynamic security association at the [edit services ipsec-vpn ike], [edit services ipsec-vpn ipsec], and [edit services ipsec-vpn rule rule-name] hierarchy levels. Include your choices for IKE policies and proposals, which include options for authentication algorithms, authentication methods, Diffie-Hellman groups, encryption, IKE modes, and preshared keys. Also, include your choices for IPSec policies and proposals, which include options for authentication, encryption, protocols, PFS, and IPSec modes. Be sure that these choices are configured exactly the same way on the remote IPSec gateway.

If you choose not to explicitly configure IKE and IPSec policies and proposals on the AS and MultiServices PICs, your configuration can default to some preset values. These default values are shown in Table 55.

Table 55: IKE and IPSec Proposal and Policy Default Values for the AS and MultiServices PICs

IKE Policy Statement

Default Value

mode

main

proposals

default
IKE Proposal Statement

Default Value

authentication-algorithm

sha1

authentication-method

pre-shared-keys

dh-group

group2

encryption-algorithm

3des-cbc

lifetime-seconds

3600 (seconds)

IPSec Policy Statement

Default Value

perfect-forward-secrecy keys

group2

proposals

default
IPSec Proposal Statement

Default Value

authentication-algorithm

hmac-sha1-96

encryption-algorithm

3des-cbc

lifetime-seconds

28800 (seconds)

protocol

esp

Note: If you use the default IKE and IPSec policy and proposal values preset within the AS and MultiServices PICs, you must explicitly configure an IKE policy and include a preshared key. This is because the pre-shared-keys authentication method is one of the preset values in the default IKE proposal.

If you decide to configure values manually, the following information shows the complete statement hierarchy and options for dynamic IKE SAs on the AS and MultiServices PICs:

[edit services ipsec-vpn]
ike {
proposal proposal-name {
authentication-algorithm (md5 | sha1 | sha256);
authentication-method (pre-shared-keys | rsa-signatures);
description description;
dh-group (group1 | group2);
encryption-algorithm algorithm; # This can be aes-128-cbc, aes-192-cbc,
# aes-256-cbc, des-cbc, or 3des-cbc.
lifetime-seconds seconds;
}
policy policy-name {
description description;
local-id {
ipv4_addr [ values ];
key_id [ values ];
}
local-certificate certificate-id-name;
mode (aggressive | main);
pre-shared-key (ascii-text key | hexadecimal key);
proposals [ proposal-names ];
remote-id {
ipv4_addr [ values ];
key_id [ values ];
}
}
}
ipsec {
proposal proposal-name {
authentication-algorithm (hmac-md5-96 | hmac-sha1-96);
description description;
encryption-algorithm algorithm; # This can be aes-128-cbc, aes-192-cbc,
# aes-256-cbc, des-cbc, or 3des-cbc.
lifetime-seconds seconds;
protocol (ah | esp | bundle);
}
policy policy-name {
description description;
perfect-forward-secrecy {
keys (group1 | group2);
}
proposals [ proposal-names ];
}
}
rule rule-name {
match-direction (input | output);
term term-name {
from {
destination-address address;
source-address address;
}
then {
backup-remote-gateway address;
clear-dont-fragment-bit;
dynamic {
ike-policy policy-name;
ipsec-policy policy-name;
}
no-anti-replay;
remote-gateway address;
syslog;
}
}
}
rule-set rule-set-name {
[ rule rule-names ];
}

Using a Filter to Select Traffic to Be Secured

For the ES PIC, you need to configure a firewall filter to direct traffic into the IPSec tunnel. To apply a security association to traffic that matches a firewall filter, include the ipsec-sa sa-name statement at the [edit firewall filter filter-name term term-name then] hierarchy level.

[edit firewall filter filter-name]
term term-name {
from {
source-address {
ip-address;
}
destination-address {
ip-address;
}
}
then {
count counter-name;
ipsec-sa sa-name;
}
}
term other {
then accept;
}

For the AS and MultiServices PICs, you do not need to configure a separate firewall filter. A filter is already built into the IPSec VPN rule statement at the [edit services ipsec-vpn] hierarchy level. To apply a security association to traffic that matches the IPSec VPN rule, include the dynamic or manual statement at the [edit services rule rule-name term term-name then] hierarchy level. To specify whether the rule should match input or output traffic, include the match-direction statement at the [edit services rule rule-name] hierarchy level.

After defining the rules for your IPSec VPNs, you must apply the rules to a service set. To do this, include the ipsec-vpn-rules rule-name statement at the [edit services service-set service-set-name] hierarchy level. Include an IPv4 or IPv6 IPSec gateway with the local-gateway local-ip-address statement at the [edit services service-set service-set-name] hierarchy level.

Also, you must select either a single interface or a pair of interfaces that participate in IPSec. To select a single interface, include the interface-service interface-name statement at the [edit services service-set service-set-name] hierarchy level. To select a pair of interfaces and a next hop, include the next-hop-service statement at the [edit services service-set service-set-name] hierarchy level and specify an inside interface and an outside interface. Only next-hop service sets support IPSec within Layer 3 VPNs and use of routing protocols over the IPSec tunnel.

[edit services]
service-set service-set-name {
interface-service {
service-interface interface-name;
}
next-hop-service {
inside-service-interface interface-name;
outside-service-interface interface-name;
}
ipsec-vpn-options {
local-gateway local-ip-address <routing-instance instance-name>;
trusted-ca ca-profile-name;
}
ipsec-vpn-rules rule-name;
}
ipsec-vpn {
rule rule-name {
term term-name {
from {
source-address {
ip-address;
}
destination-address {
ip-address;
}
}
then {
remote-gateway remote-ip-address;
(dynamic | manual);
}
}
match-direction output;
}
}

Applying the Filter or Service Set to the Interface Receiving Traffic to Be Secured

For the ES PIC, apply your firewall filter on the input interface receiving the traffic that you wish to send to the IPSec tunnel. To do this, include the filter statement at the [edit interfaces interface-name unit unit-number family inet] hierarchy level.

[edit interfaces interface-name unit unit-number family inet]
filter {
input filter-name;
}

For the AS and MultiServices PICs, apply your IPSec-based interface service set to the input interface receiving the traffic that you wish to send to the IPSec tunnel. To do this, include the service-set service-set-name statement at the [edit interfaces interface-name unit unit-number family inet service (input | output)] hierarchy level.

[edit interfaces interface-name unit unit-number family inet]
service {
input {
service-set service-set-name;
}
output {
service-set service-set-name;
}
}

To configure a next-hop-based service set on the AS and MultiServices PICs, include the service-domain statement at the [edit interfaces interface-name unit unit-number] hierarchy level and specify one logical interface on the AS PIC as an inside interface and a second logical interface on the AS PIC as an outside interface.

[edit interfaces sp-fpc/pic/port]
unit 0 {
family inet {
address ip-address;
}
}
unit 1 {
family inet;
service-domain inside;
}
unit 2 {
family inet;
service-domain outside;
}

Option: Using Digital Certificates

A popular way for network administrators to scale an IPSec network is to use digital certificates instead of preshared keys. To enable digital certificates in your network, you need to use a combination of operational mode commands and configuration statements. The following steps enable you to implement digital certificates on J-series Services Routers and AS and MultiServices PICs installed in M-series and T-series routing platforms:

Configuring a CA Profile

The CA profile contains the name and URL of the CA or RA, as well as some retry timer settings. CA certificates issued by Entrust, VeriSign, and Microsoft are all compatible with J-series, M-series, and T-series routing platforms. To configure the domain name of the CA or RA, include the ca-identity statement at the [edit security pki ca-profile ca-profile-name] hierarchy level. To configure the URL of the CA, include the url statement at the [edit security pki ca-profile ca-profile-name enrollment] hierarchy level. To configure the number of enrollment attempts the routing platform should perform, include the retry statement at the [edit security pki ca-profile ca-profile-name enrollment] hierarchy level. To configure the amount of time the routing platform should wait between enrollment attempts, include the retry-interval statement at the [edit security pki ca-profile ca-profile-name enrollment] hierarchy level.

[edit security pki]
ca-profile ca-profile-name {
ca-identity ca-identity;
enrollment {
url url-name;
retry number-of-enrollment-attempts; # The range is 0 though 100 attempts.
retry-interval seconds; # The range is 0 though 3600 seconds.
}
}

Configuring a Certificate Revocation List

A certificate revocation list (CRL) contains a list of digital certificates that have been canceled before their expiration date. When a participating peer uses a digital certificate, it checks the certificate signature and validity. It also acquires the most recently issued CRL and checks that the certificate serial number is not on that CRL. By default, CRL verification is enabled on any CA profile running on JUNOS Release 8.1 or later. To disable CRL verification, include the disable statement at the [edit security pki ca-profile ca-profile-name revocation-check] hierarchy level.

To specify the URL for the Lightweight Directory Access Protocol (LDAP) server where your CA stores its current CRL, include the url statement at the [edit security pki ca-profile ca-profile-name revocation-check crl] hierarchy level. If the LDAP server requires a password to access the CRL, include the password statement at the [edit security pki ca-profile ca-profile-name revocation-check crl url] hierarchy level.

Note: You do not need to specify a URL for the LDAP server if the certificate includes a certificate distribution point (CDP). The CDP is a field within the certificate that contains information about how to retrieve the CRL for the certificate. The routing platform uses this information to download the CRL automatically. Any LDAP URL you configure takes precedence over the CDP included in the certificate.

If you manually downloaded the CRL, you must manually install it on the routing platform. To manually install the CRL, issue the request security pki crl load ca-profile ca-profile-name filename path/filename command.

To configure the time interval between CRL updates, include the refresh-interval statement at the [edit security ca-profile ca-profile-name revocation-check crl] hierarchy level.

To override the default behavior and permit IPSec peer authentication to continue when the CRL fails to download, include the disable on-download-failure statement at the [edit security ca-profile ca-profile-name revocation-check crl] hierarchy level.

[edit security pki ca-profile ca-profile-name]
revocation-check {
disable;
crl {
disable on-download-failure;
refresh-interval number-of-hours { # The range is 0 through 8784 hours.
url {
url-name;
password;
}
}
}
}

Requesting a CA Digital Certificate

You can request a CA digital certificate either online or manually. To request a digital certificate from a CA or RA online by using SCEP, issue the request security pki ca-certificate enroll ca-profile ca-profile-name command.

If you obtained the CA digital certificate manually through e-mail or other out-of-band mechanism, you must load it manually. To manually install a certificate in your routing platform, issue the request security pki local-certificate load command.

Generating a Private/Public Key Pair

A key pair is a critical element of a digital certificate implementation. The public key is included in the local digital certificate and the private key is used to decrypt data received from peers. To generate a private/public key pair, issue the request security pki generate-key-pair certificate-id certificate-id-name command.

Generating and Enrolling a Local Digital Certificate

You can generate and enroll a local digital certificate either online or manually. To generate and enroll a local certificate online by using SCEP, issue the request security pki local-certificate enroll command. To generate a local certificate request manually in the PKCS-10 format, issue the request security pki generate-certificate-request command.

If you create the local certificate request manually, you must also load the certificate manually. To manually install a certificate in your routing platform, issue the request security pki local-certificate load command.

Applying the Local Digital Certificate to an IPSec Configuration

To activate a local digital certificate, you configure the IKE proposal to use digital certificates instead of preshared keys, reference the local certificate in the IKE policy, and identify the CA or RA in the service set. To enable the IKE proposal for digital certificates, include the rsa-signatures statement at the [edit services ipsec-vpn ike proposal proposal-name authentication-method] hierarchy level. To reference the local certificate in the IKE policy, include the local-certificate statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level. To identify the CA or RA in the service set, include the trusted-ca statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level.

[edit services]
service-set service-set-name {
.....
ipsec-vpn-options {
trusted-ca ca-profile-name;
}
}
ipsec-vpn {
ike {
proposal proposal-name {
.....
authentication-method [pre-shared-keys | rsa-signatures];
}
policy policy-name {
....
local-certificate certificate-id-name;
}
}
}

Configuring Automatic Reenrollment of Digital Certificates

You can configure automatic reenrollment for digital certificates. This feature is by default not enabled. To configure automatic reenrollment for digital certificates, include the auto-re-enrollment statement at the [edit security pki] hierarchy level:

[edit]
security {
pki {
auto-re-enrollment {
certificate-id certificate-name {
ca-profile ca-profile-name;
challenge-password password;
re-enroll-trigger-time-percentage percentage; # Percentage of validity-period
# (specified in certificate) when automatic
# reenrollment should be initiated.
re-generate-keypair;
validity-period number-of-days;
}
}
}
}

Monitoring and Clearing Digital Certificates

You can issue various forms of the show security pki command to view digital certificates and certificate requests and certificate revocation lists:

Variations of the clear security pki command enable you to delete certificates or requests and certificate revocation lists:

To see a full example showing the use of digital certificates in an IPSec topology, see Example: AS PIC IKE Dynamic SA with Digital Certificates Configuration. For more information about operational mode commands used with digital certificates, see the JUNOS System Basics and Services Command Reference. For more information about configuration statements used with digital certificates, see the J-series Services Router Advanced WAN Access Configuration Guide, the JUNOS System Basics Configuration Guide, and the JUNOS Services Interfaces Configuration Guide.

Option: Using Filter-Based Forwarding to Select Traffic to Be Secured

Instead of using a firewall filter, you can also forward traffic into an IPSec security association by using a filter-based forwarding instance. First, configure the filter-based forwarding instance. Then, configure a routing table group to advertise the routes from the filter-based forwarding instance. Next, create a firewall filter for the ES PIC and reference the filter-based forwarding instance. Lastly, apply the filter and IPSec security association to the ES PIC.

[edit]
routing-instances {
forwarding {
instance-type forwarding;
routing-options {
static {
route 10.10.10.0/24 next-hop 192.168.0.5;
}
}
}
}
routing-options {
rib-groups {
group-name {
import-rib [ inet.0 forwarding.inet.0 ];
}
}
}
firewall {
family inet {
filter filter-name {
term term-name {
then routing-instance instance-name;
}
}
}
}
[edit]
interfaces {
es-0/0/0 {
unit 0 {
tunnel {
source source-ip-address;
destination destination-ip-address;
}
family inet {
ipsec-sa sa-name;
filter {
input filter-name;
}
address ip-address;
}
}
}
}

Option: Using IPSec with a Layer 3 VPN

Some key concepts to keep in mind when configuring IPSec within a VPN include the following:

The following configuration for an AS PIC on a provider edge (PE) router demonstrates the use of next-hop service sets with an IKE dynamic SA in a VPN routing and forwarding (VRF) routing instance.

[edit]
interfaces {
so-0/0/0 {
description "Interface connected to the customer edge (CE) router";
unit 0 {
family inet {
address 10.6.6.6/32;
}
}
}
so-2/2/0 {
description "Source IPSec tunnel interface to the network core";
unit 0 {
family inet {
address 10.10.1.1/30;
}
}
}
sp-3/1/0 {
description "AS PIC interface";
unit 0 {
family inet {
address 10.7.7.7/32;
}
}
unit 1 {
family inet;
service-domain inside;
}
unit 2 {
family inet;
service-domain outside;
}
}
}
policy-options {
policy-statement vpn-export-policy {
then {
community add community-name;
accept;
}
}
policy-statement vpn-import-policy {
term term-name {
from community community-name;
then accept;
}
}
community community-name members target:100:20;
}
routing-instances {
vrf {
instance-type vrf;
interface sp-3/1/0.1; # Inside sp interface.
interface so-0/0/0.0; # Interface that connects to the CE router.
route-distinguisher route-distinguisher;
vrf-import vpn-import-policy;
vrf-export vpn-export-policy;
routing-options {
static {
route ip-address/prefix next-hop so-0/0/0.0; # Routes for the CE router.
route ip-address/prefix next-hop sp-3/1/0.1; # Routes for IPSec.
}
}
}
}
services {
service-set service-set-name {
next-hop-service {
inside-service-interface sp-3/1/0.1;
outside-service-interface sp-3/1/0.2;
}
ipsec-vpn-options {
local-gateway 10.10.1.1;
}
ipsec-vpn-rules rule-name;
}
ipsec-vpn {
rule rule-name {
term term-name {
from {
source-address {
source-ip-address;
}
}
then {
remote-gateway 10.10.1.2;
dynamic {
ike-policy ike-policy-name;
}
}
}
match-direction direction;
}
ike {
policy ike-policy-name {
pre-shared-key ascii-text preshared-key;
}
}
}
}

For more information on VRF routing instances, see the JUNOS VPNs Configuration Guide. For more information on next-hop service sets, see the JUNOS Services Interfaces Configuration Guide.

Option: Securing BGP Sessions with Transport Mode

For the ES PIC, you can use IPSec to secure BGP sessions between Routing Engines in M-series and T-series platforms. To configure, create a transport mode security association and apply the SA to the BGP configuration by including the ipsec-sa statement at the [edit protocols bgp group group-name] hierarchy level.

[edit]
protocols {
bgp {
group group-name {
local-address ip-address;
export export-policy;
peer-as as-number;
ipsec-sa sa-name;
neighbor peer-ip-address;
}
}
}

Option: Securing OSPFv3 Networks with Transport Mode

OSPF version 3 (OSPFv3), unlike OSPF version 2, does not have a built-in authentication method and relies on IPSec to provide this functionality. Using the ES PIC syntax, you can use IPSec to secure OSPFv3 between Routing Engines in M-series and T-series platforms. You can secure specific OSPFv3 interfaces and protect OSPFv3 virtual links. To configure, create a transport mode security association and apply the SA to the OSPFv3 configuration by including the ipsec-sa statement at the [edit protocols ospf3 area area-number interface interface-name] or [edit protocols ospf3 area area-number virtual-link neighbor-id neighbor-ip-address transit-area area-number] hierarchy level.

[edit]
protocols {
ospf3 {
area area-number {
interface interface-name {
ipsec-sa sa-name;
}
virtual-link neighbor-id neighbor-ip-address transit-area area-number {
ipsec-sa sa-name;
}
}
}
}

Option: Securing OSPFv2 Networks with Transport Mode

By default, you can configure MD5 or simple text password-based authentication over OSPFv2 links. In addition to these basic authentications, the JUNOS software supports OSPFv2 with a security authentication header (AH), Encapsulating Security Payload (ESP), or an IPSec protocol bundle that supports both AH and ESP. You can configure IPSec over OSPFv2 using transport mode security associations on physical, sham, or virtual links.

Because the JUNOS software supports only bidirectional security associations over OSPFv2, OSPFv2 peers must be configured with the same IPSec security association. Configuring OSPFv2 peers with different security associations or with dynamic IKE will prevent adjacencies from being established. In addition, you must configure identical security associations for sham links with the same remote endpoint address, for virtual links with the same remote endpoint address, for all neighbors on OSPF nonbroadcast multiaccess (NBMA) or point-to-multipoint links, and for every subnet that is part of a broadcast link.

To create a manual bidirectional security association, include the security-association security-association-name statement at the [edit security ipsec] hierarchy level:

[edit]
security {
ipsec {
security-association security-association name {
mode transport;
manual {
direction bidirectional {
protocol (ah | esp | bundle);
spi spi--value;
authentication {
algorithm (hmac-md5-96 | hmac-sha1-96);
key (ascii-text key | hexadecimal key);
}
}
}
}
}
}

 

To configure IPSec on an OSPFv2 interface, create a transport mode security association and include the ipsec-sa name statement at the [edit protocols ospf area area-id] hierarchy level:

[edit]
protocols {
ospf {
area area-id {
interface interface-name {
ipsec-sa sa-name;
}
virtual-link neighbor-id a.b.c.d transit-area x.x.x.x {
ipsec-sa sa-name;
}
sham-link-remote {
ipsec-sa sa-name;
}
}
}
}

To verify your configuration, enter the show ospf interface detail command. This command gives detailed information about the ospfv2 interface and displays the interface’s security association at the bottom of the output. In the example below, the security association configured on this router is sa1.


user@router> show ospf interface detail 
Interface              State     Area            DR ID           BDR ID Nbrs
fe-0/0/1.0             BDR      0.0.0.0         192.168.37.12   10.255.245.215 1
Type LAN, address 192.168.37.11, Mask 255.255.255.248, MTU 4460, Cost 40
DR addr 192.168.37.12, BDR addr 192.168.37.11, Adj count 1, Priority 128
Hello 10, Dead 40, ReXmit 5, Not Stub
t1-0/2/1.0             PtToPt   0.0.0.0         0.0.0.0         0.0.0.0 0
Type P2P, Address 0.0.0.0, Mask 0.0.0.0, MTU 1500, Cost 2604
Adj count 0
Hello 10, Dead 40, ReXmit 5, Not Stub
Auth type: MD5, Active key ID 3, Start time 2002 Nov 19 10:00:00 PST
IPsec SA Name: sa1

Option: Monitoring IPSec by Using SNMP

In JUNOS Release 7.5 and later, the IPSec Monitoring MIB provides a way to monitor IPSec information on J-series Services Routers and AS PICs installed in M-series and T-series routing platforms by using Simple Network Management Protocol (SNMP). The MIB provides an IKE tunnel table to monitor IKE security associations and view related statistics, an IPSec tunnel table to view IPSec tunnel statistics, and an IPSec security associations table to view all IPSec SAs. For more information, see the JUNOS Network Management Configuration Guide.

Option: Configuring IPSec Dynamic Endpoints

IPSec tunnels can also be established using dynamic peer security gateways, in which the remote end of the tunnels do not have a statically assigned IPv4 or IPv6 address. Since the remote address is not known and is assigned from an address pool each time the remote host reboots, establishment of the tunnel relies on using IKE main mode with preshared global keys. Both policy-based and link-type tunnels are supported as follows:

This section includes the following topics:

Dynamic Endpoint Tunnel Architecture

When you configure dynamic endpoint tunnels, the following components are used:

Authentication Process

The remote dynamic peer initiates IKE and IPSec negotiations with the local (Juniper Networks) routing platform. The local router uses a default set of authentication and encryption values to match the IPSec and IKE proposals sent by the remote peer to establish the SA. If any of the values match, the tunnel establishment process continues. The default values are shown in Table 56.

Table 56: Default IKE and IPSec Proposals for Dynamic SA Negotiations

Statement Name

Values
Implicit IKE Proposal

authentication-method

preshared keys

dh-group

group1, group2

authentication-algorithm

sha1, md5

encryption-algorithm

3des-cbc, des-cbc

lifetime-seconds

3600 seconds
Implicit IPSec Proposal

protocol

esp, ah, bundle

authentication-algorithm

hmac-sha1-96, hmac-md5-96

encryption-algorithm

3des-cbc, des-cbc

lifetime-seconds

28,800 seconds (8 hours)

Phase 2 of the authentication process matches the proxy identities of the protected hosts and networks sent by the peer against a list of configured proxy identities. The accepted proxy identity is used to create the dynamic rules for encrypting the traffic. You can configure proxy identities by including the allowed-proxy-pair statement in an IKE access profile at the [edit access profile profile-name client * ike] hierarchy level. If no configured entry matches, the negotiation is rejected.

However, if you do not configure the allowed-proxy-pair statement, the default value ANY(0.0.0.0/0)-ANY is applied, and the local router accepts any proxy identities sent by the peer.

Once the phase 2 negotiation has been successfully completed, the routing platform builds dynamic rules and inserts the reverse route into the routing table using the accepted proxy identity.

Dynamic Implicit Rules

After successful negotiation with the dynamic peer, the key management process (kmd) creates a dynamic rule for the accepted phase 2 proxy and applies it on the local AS or MultiServices PIC. The source and destination addresses are specified by the accepted proxy. This rule is used to encrypt traffic directed to one of the end hosts in the phase 2 proxy identity.

Note: You do not configure this rule; it is created by the key management process (kmd).

The ipsec-inside-interface value is the interface name assigned to the dynamic tunnel. The source-address and destination-address values are accepted from the proxy ID. The match-direction value is input for next-hop-style service sets.

Rule lookup for static tunnels is unaffected by the presence of a dynamic rule; it is performed in the order configured. When a packet is received for a service-set, static rules are always matched first. Dynamic rules are matched only after the rule match for static rules has failed.

Reverse Route Insertion

Static routes are automatically inserted into the route table for those networks and hosts protected by a remote tunnel endpoint. These protected hosts and networks are known as remote proxy identities.

Each route is created based on the remote proxy network and prefix length sent by the peer and is inserted in the relevant route table after successful phase 1 and phase 2 negotiations.

The route preference for each of these static reverse routes is 1. This value is necessary to avoid conflict with similar routes that might be added by the routing protocol process (rpd).

No routes are added if the accepted remote proxy address is the default (0.0.0.0/0). In this case, you can run routing protocols over the IPSec tunnel to learn routes and add static routes for the traffic you want to be protected over this tunnel.

For next-hop style service sets, the reverse routes include next hops pointing to the locations specified by the inside-service-interface statements.

The selection of the routing table in which these routes are inserted depends on where you configure the inside-service-interface statement. If these interfaces are present in a VRF routing instance, then routes are added to the corresponding VRF routing table; otherwise, the routes are added to inet.0.

Note: Reverse route insertion takes place only for tunnels to dynamic peers. These routes are added only for next-hop style service sets.

Configuring an IKE Access Profile

You can configure only one tunnel profile per service set for all dynamic peers. The configured preshared key in the profile is used for IKE authentication of all dynamic peers terminating in that service set.

The IKE tunnel profile specifies all the information needed to complete the IKE negotiation. For more information on access profiles, see the JUNOS System Basics Configuration Guide.

[edit access]
profile profile-name {
client * {
ike {
allowed-proxy-pair {
remote remote-proxy-address local local-proxy-address;
}
pre-shared-key ([ ascii-text key-string ] | [hexadecimal key-string ]);
interface-id string-value;
}
}
}

Note: For dynamic peers, the JUNOS software supports only IKE main mode with the preshared key method of authentication. In this mode, an IPv4 or IPv6 address is used to identify a tunnel peer to get the preshared key information. The client value * (wildcard) means that the configuration within this profile is valid for all dynamic peers terminating within the service set accessing this profile.

The following statements are the parts of the IKE profile:

Configuring the Service Set

To complete a dynamic endpoint tunnel configuration, you need to reference the IKE access profile configured at the [edit access] hierarchy level in the service set. To do this, include the ike-access-profile statement at the [edit services service-set name ipsec-vpn-options] hierarchy level:

[edit services]
service-set name {
next-hop-service {
inside-service-interface interface-name;
outside-service-interface interface-name;
}
ipsec-vpn-options {
local-gateway address;
ike-access-profile profile-name;
}
}

You can reference only one access profile in each service set. This profile is used to negotiate IKE and IPSec security associations with dynamic peers only.

Note: If you configure an IKE access profile in a service set, no other service set can share the same local-gateway address.

Configuring the Interface Identifier

You can configure an interface identifier for a group of dynamic peers, which specifies which adaptive services logical interface(s) take part in the dynamic IPSec negotiation. By assigning the same interface identifier to multiple logical interfaces, you can create a pool of interfaces for this purpose. To configure, include the ipsec-interface-id statement at the [edit interfaces interface-name] hierarchy level:

[edit interfaces sp-fpc/pic/port]
unit logical-unit-number {
dial-options {
ipsec-interface-id identifier;
(shared | dedicated);
}
}

Specifying the interface identifierin the dial-options statement makes this logical interface part of the pool identified by the IPSec interface identifier.

Note: Only one interface identifier can be specified at a time. You can include the ipsec-interface-id statement or the l2tp-interface-id statement, but not both simultaneously.

The shared statement enables one logical interface to be shared across multiple tunnels. The dedicated statement specifies that the logical interface is associated with a single tunnel, which is necessary when you are configuring an IPSec link-type tunnel. You must include the dedicated statement when you specify an ipsec-interface-id value.

Option: Configuring Multiple Routed Tunnels in a Single Next-Hop Service Set

To save you time and simplify your configurations, an enhancement to the JUNOS software enables you to configure several routed IPSec tunnels within a single next-hop service set. To configure, establish multiple services interfaces as inside interfaces by including the service-domain inside statement at the [edit interfaces sp-fpc/pic/port unit logical-unit-number] hierarchy level. Then, include the ipsec-inside-interface statement at the [edit services ipsec-vpn rule rule-name term term-name from] hierarchy level.

Note: The full IPSec and IKE proposals and policies are not shown in the following example for the sake of brevity. For more information on proposals and policies, see Configuring IKE Dynamic SAs.

[edit]
interfaces {
sp-3/3/0 {
unit 3 {
family inet;
service-domain inside;
}
unit 4 {
family inet;
service-domain outside;
}
unit 5 {
family inet;
service-domain inside;
}
}
}
services {
service-set link_type_ss_1 {
next-hop-service {
inside-service-interface sp-3/3/0.3;
outside-service-interface sp-3/3/0.4;
}
ipsec-vpn-options {
local-gateway 10.8.7.2;
}
ipsec-vpn-rules link_rule_1;
}
ipsec-vpn {
rule link_rule_1 {
term 1 {
from {
ipsec-inside-interface sp-3/3/0.3;
}
then {
remote-gateway 10.10.7.3;
backup-remote-gateway 10.8.7.1;
dynamic {
ike-policy main_mode_ike_policy;
ipsec-policy dynamic_ipsec_policy;
}
}
}
term 2 {
from {
ipsec-inside-interface sp-3/3/0.5;
}
then {
remote-gateway 10.12.7.5;
dynamic {
ike-policy main_mode_ike_policy;
ipsec-policy dynamic_ipsec_policy;
}
}
}
match-direction input;
}
}
}

To confirm that your configuration is working, issue the show services ipsec-vpn ipsec security-associations command. Notice that each IPSec inside interface that you assigned to each IPSec tunnel is included in the output of this command.


user@router> show services ipsec-vpn ipsec security-associations 
Service set: link_type_ss_1

  Rule: link_rule_1, Term: 1, Tunnel index: 1
  Local gateway: 10.8.7.2, Remote gateway: 10.8.7.1
  IPSec inside interface: sp-3/3/0.3
    Direction SPI         AUX-SPI     Mode       Type     Protocol
    inbound   3216392497  0           tunnel     dynamic  ESP
    outbound  398917249   0           tunnel     dynamic  ESP

  Rule: link_rule_1, Term: 2, Tunnel index: 2
  Local gateway: 10.8.7.2, Remote gateway: 10.12.7.5
  IPSec inside interface: sp-3/3/0.5
    Direction SPI         AUX-SPI     Mode       Type     Protocol
    inbound   762146783   0           tunnel     dynamic  ESP
    outbound  319191515   0           tunnel     dynamic  ESP
[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]