Technical Documentation

Example: AS PIC IKE Dynamic SA Configuration

Figure 1: AS PIC IKE Dynamic SA Topology Diagram

Image g015519.gif

Figure 1 shows the same IPSec topology as seen in the AS PIC manual SA example. However, this configuration requires Routers 2 and 3 to establish an IPSec tunnel using an IKE dynamic SA, enhanced authentication, and stronger encryption. Routers 1 and 4 continue to provide basic connectivity and are used to verify that the IPSec tunnel is operational.

Note: When you do not specify an IKE proposal, an IPSec proposal, and an IPSec policy on an AS PIC, the JUNOS Software defaults to the highest level of encryption and authentication. As a result, the default authentication protocol is ESP, the default authentication mode is HMAC-SHA1-96, and the default encryption mode is 3DES-CBC. For more information about default IKE and IPSec policies and proposals on the AS PIC, see IKE and IPSec Proposal and Policy Default Values for the AS and MultiServices PICs.

On Router 1, provide basic OSPF connectivity to Router 2.

Router 1

[edit]interfaces {so-0/0/0 {description "To R2 so-0/0/0";unit 0 {family inet {address 10.1.12.2/30;}}}lo0 {unit 0 {family inet {address 10.0.0.1/32;}}}}routing-options {router-id 10.0.0.1;}protocols {ospf {area 0.0.0.0 {interface so-0/0/0.0;interface lo0.0;}}}

On Router 2, enable OSPF as the underlying routing protocol to connect to Routers 1 and 3. Configure a bidirectional IKE dynamic SA in a rule called rule-ike at the [edit ipsec-vpn rule] hierarchy level. Reference this rule in a service set called service-set-dynamic-BiEspsha3des at the [edit services service-set] hierarchy level.

Using default values in the AS PIC, you do not need to specify an IPSec proposal, IPSec policy, or IKE proposal. However, you do need to configure a preshared key in an IKE policy with the pre-shared-key statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level. (For more information about default IKE and IPSec policies and proposals on the AS PIC, see IKE and IPSec Proposal and Policy Default Values for the AS and MultiServices PICs.)

To direct traffic into the AS PIC and the IPSec tunnel, configure a next-hop style service set and add the adaptive services logical interface used as the IPSec inside interface into the OSPF configuration.

Router 2

[edit]interfaces {so-0/0/0 {description "To R1 so-0/0/0";unit 0 {family inet {address 10.1.12.1/30;}}}so-0/0/1 {description "To R3 so-0/0/1";unit 0 {family inet {address 10.1.15.1/30;}}}sp-1/2/0 {services-options {syslog {host local {services info;}}}unit 0 {family inet {} unit 1 { # sp-1/2/0.1 is the IPSec inside interface.family inet;service-domain inside;} unit 2 { # sp-1/2/0.2 is the IPSec outside interface.family inet;service-domain outside;}}lo0 {unit 0 {family inet {address 10.0.0.2/32;}}}}routing-options {router-id 10.0.0.2;}protocols {ospf {area 0.0.0.0 {interface so-0/0/0.0;interface lo0.0; interface sp-1/2/0.1; # This sends OSPF traffic over the IPSec tunnel.}}}services { service-set service-set-dynamic-BiEspsha3des { # Define your service set here. next-hop-service { # Required for dynamic routing protocols such as OSPF.inside-service-interface sp-1/2/0.1;outside-service-interface sp-1/2/0.2;}ipsec-vpn-options { local-gateway 10.1.15.1; # Specify the local IP address of the IPSec tunnel.} ipsec-vpn-rules rule-ike; # Reference your IPSec VPN rule here.}ipsec-vpn { rule rule-ike { # Define your IPSec VPN rule here.term term-ike {then { remote-gateway 10.1.15.2; # The remote IP address of the IPSec tunnel. dynamic { # This creates a dynamic SA. ike-policy ike-policy-preshared; # Reference your IKE policy here.}}} match-direction input; # Specify in which direction the rule should match.}ike { policy ike-policy-preshared { # Define your IKE policy specifications here. pre-shared-key ascii-text "$9$KtKWX-YgJHqfVwqfTzCAvWL"; ## The unencrypted preshared key for this example is juniper.}}}}}

On Router 3, enable OSPF as the underlying routing protocol to connect to Routers 2 and 4. Configure a bidirectional IKE dynamic SA in a rule called rule-ike at the [edit ipsec-vpn rule] hierarchy level. Reference this rule in a service set called service-set-dynamic-BiEspsha3des at the [edit services service-set] hierarchy level.

Again, use the same default policies and proposals that you used on Router 2. However, remember to configure a preshared key in an IKE policy with the pre-shared-key statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level. The key must match the one you specified on Router 2. (For more information about default IKE and IPSec policies and proposals on the AS PIC, see IKE and IPSec Proposal and Policy Default Values for the AS and MultiServices PICs.)

To direct traffic into the AS PIC and the IPSec tunnel, configure a next-hop style service set and add the adaptive services logical interface used as the IPSec inside interface into the OSPF configuration.

Router 3

[edit]interfaces {so-0/0/0 {description "To R4 so-0/0/0";unit 0 {family inet {address 10.1.56.1/30;}}}so-0/0/1 {description "To R2 so-0/0/1";unit 0 {family inet {address 10.1.15.2/30;}}}sp-1/2/0 {services-options {syslog {host local {services info;}}}unit 0 {family inet {} unit 1 { # sp-1/2/0.1 is the IPSec inside interface.family inet;service-domain inside;} unit 2 { # sp-1/2/0.2 is the IPSec outside interface.family inet;service-domain outside;}}lo0 {unit 0 {family inet {address 10.0.0.3/32;}}}}routing-options {router-id 10.0.0.3;}protocols {ospf {area 0.0.0.0 {interface so-0/0/0.0;interface lo0.0; interface sp-1/2/0.1; # This sends OSPF traffic over the IPSec tunnel.}}}services { service-set service-set-dynamic-BiEspsha3des { # Define your service set here. next-hop-service { # Required for dynamic routing protocols such as OSPF.inside-service-interface sp-1/2/0.1;outside-service-interface sp-1/2/0.2;}ipsec-vpn-options { local-gateway 10.1.15.2; # Specify the local IP address of the IPSec tunnel.} ipsec-vpn-rules rule-ike; # Reference your IPSec VPN rule here.}ipsec-vpn { rule rule-ike { # Define your IPSec VPN rule here.term term-ike {then { remote-gateway 10.1.15.1; # The remote IP address of the IPSec tunnel. dynamic { # This creates a dynamic SA. ike-policy ike-policy-preshared; # Reference your IKE policy here.}}} match-direction input; # Specify in which direction the rule should match.}ike { policy ike-policy-preshared { # Define your IKE policy specifications here. pre-shared-key ascii-text "$9$KtKWX-YgJHqfVwqfTzCAvWL"; ## The unencrypted preshared key for this example is juniper.}}}}}

On Router 4, provide basic OSPF connectivity to Router 3.

Router 4

[edit]interfaces {so-0/0/0 {description "To R3 so-0/0/0";unit 0 {family inet {address 10.1.56.2/30;}}}lo0 {unit 0 {family inet {address 10.0.0.4/32;}}}}routing-options { router-id 10.0.0.4;}protocols {ospf {area 0.0.0.0 {interface so-0/0/0.0;interface lo0.0;}}}

Verifying Your Work

To verify proper operation of an IKE-based dynamic SA on the AS PIC, use the following commands:

  • ping
  • show services ipsec-vpn ike security-associations (detail)
  • show services ipsec-vpn ipsec security-associations (detail)
  • show services ipsec-vpn ipsec statistics
  • traceroute

The following sections show the output of these commands used with the configuration example:

Router 1

On Router 1, issue a ping command to the so-0/0/0 interface on Router 4 to send traffic across the IPSec tunnel.


user@R1> ping 10.1.56.2
PING 10.1.56.2 (10.1.56.2): 56 data bytes
64 bytes from 10.1.56.2: icmp_seq=0 ttl=254 time=1.351 ms
64 bytes from 10.1.56.2: icmp_seq=1 ttl=254 time=1.187 ms
64 bytes from 10.1.56.2: icmp_seq=2 ttl=254 time=1.172 ms
64 bytes from 10.1.56.2: icmp_seq=3 ttl=254 time=1.154 ms
64 bytes from 10.1.56.2: icmp_seq=4 ttl=254 time=1.156 ms
^C
--- 10.1.56.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.154/1.204/1.351/0.074 ms

Router 2

To verify that the IKE SA negotiation is successful, issue the show services ipsec-vpn ike security-associations command.


user@R2> show services ipsec-vpn ike security-associations
Remote Address  State         Initiator cookie  Responder cookie  Exchange type
10.1.15.2       Matured       03075bd3a0000003  4bff26a5c7000003  Main

To verify that the IPSec security association is active, issue the show services ipsec-vpn ipsec security-associations detail command. Notice that the SA contains the default settings inherent in the AS PIC, such as ESP for the protocol and HMAC-SHA1-96 for the authentication algorithm.


user@R2> show services ipsec-vpn ipsec security-associations detail
Service set: service-set-dynamic-BiEspsha3des
  Rule: rule-ike, Term: term-ike, Tunnel index: 1
  Local gateway: 10.1.15.1, Remote gateway: 10.1.15.2
  Local identity: ipv4_subnet(any:0,[0..7]=10.1.12.0/24)
  Remote identity: ipv4_subnet(any:0,[0..7]=10.1.56.0/24)
    Direction: inbound, SPI: 2666326758, AUX-SPI: 0
    Mode: tunnel, Type: dynamic, State: Installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
    Soft lifetime: Expires in 26863 seconds
    Hard lifetime: Expires in 26998 seconds
    Anti-replay service: Enabled, Replay window size: 64
    Direction: outbound, SPI: 684772754, AUX-SPI: 0
    Mode: tunnel, Type: dynamic, State: Installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
    Soft lifetime: Expires in 26863 seconds
    Hard lifetime: Expires in 26998 seconds
    Anti-replay service: Enabled, Replay window size: 64

To verify that traffic is traveling over the bidirectional IPSec tunnel, issue the show services ipsec-vpn statistics command:


user@R2> show services ipsec-vpn ipsec statistics
PIC: sp-1/2/0, Service set: service-set-dynamic-BiEspsha3des
ESP Statistics:
  Encrypted bytes:             2248
  Decrypted bytes:             2120
  Encrypted packets:             27
  Decrypted packets:             25
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

Router 3

To verify that the IKE SA negotiation is successful, issue the show services ipsec-vpn ike security-associations command. To be successful, the SA on Router 3 must contain the same settings you specified on Router 2.


user@R3> show services ipsec-vpn ike security-associations
Remote Address  State         Initiator cookie  Responder cookie  Exchange type
10.1.15.1       Matured       03075bd3a0000003  4bff26a5c7000003  Main 

To verify that the IPSec SA is active, issue the show services ipsec-vpn ipsec security-associations detail command. To be successful, the SA on Router 3 must contain the same settings you specified on Router 2.


user@R3> show services ipsec-vpn ipsec security-associations detail
Service set: service-set-dynamic-BiEspsha3des
  Rule: rule-ike, Term: term-ike, Tunnel index: 1
  Local gateway: 10.1.15.2, Remote gateway: 10.1.15.1
  Local identity: ipv4_subnet(any:0,[0..7]=10.1.56.0/24)
  Remote identity: ipv4_subnet(any:0,[0..7]=10.1.12.0/24)
    Direction: inbound, SPI: 684772754, AUX-SPI: 0
    Mode: tunnel, Type: dynamic, State: Installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
    Soft lifetime: Expires in 26598 seconds
    Hard lifetime: Expires in 26688 seconds
    Anti-replay service: Enabled, Replay window size: 64
    Direction: outbound, SPI: 2666326758, AUX-SPI: 0
    Mode: tunnel, Type: dynamic, State: Installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
    Soft lifetime: Expires in 26598 seconds
    Hard lifetime: Expires in 26688 seconds
    Anti-replay service: Enabled, Replay window size: 64

To verify that traffic is traveling over the bidirectional IPSec tunnel, issue the show services ipsec-vpn statistics command:


user@R3> show services ipsec-vpn ipsec statistics
PIC: sp-1/2/0, Service set: service-set-dynamic-BiEspsha3des
ESP Statistics:
  Encrypted bytes:             2120
  Decrypted bytes:             2248
  Encrypted packets:             25
  Decrypted packets:             27
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

Router 4

On Router 4, issue a ping command to the so-0/0/0 interface on Router 1 to send traffic across the IPSec tunnel.


user@R4> ping 10.1.12.2
PING 10.1.12.2 (10.1.12.2): 56 data bytes
64 bytes from 10.1.12.2: icmp_seq=0 ttl=254 time=1.350 ms
64 bytes from 10.1.12.2: icmp_seq=1 ttl=254 time=1.161 ms
64 bytes from 10.1.12.2: icmp_seq=2 ttl=254 time=1.124 ms
64 bytes from 10.1.12.2: icmp_seq=3 ttl=254 time=1.142 ms
64 bytes from 10.1.12.2: icmp_seq=4 ttl=254 time=1.139 ms
64 bytes from 10.1.12.2: icmp_seq=5 ttl=254 time=1.116 ms
^C
--- 10.1.12.2 ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.116/1.172/1.350/0.081 ms

The final way you can confirm that traffic travels over the IPSec tunnel is by issuing the traceroute command to the so-0/0/0 interface on Router 1. Notice that the physical interface between Routers 2 and 3 is not referenced in the path; traffic enters the IPSec tunnel through the adaptive services IPSec inside interface on Router 3, passes through the loopback interface on Router 2, and ends at the so-0/0/0 interface on Router 1.


user@R4> traceroute 10.1.12.2
traceroute to 10.1.12.2 (10.1.12.2), 30 hops max, 40 byte packets
 1  10.1.15.2 (10.1.15.2)  0.987 ms  0.630 ms  0.563 ms
 2  10.0.0.2 (10.0.0.2)  1.194 ms  1.058 ms  1.033 ms
 3  10.1.12.2 (10.1.12.2)  1.073 ms  0.949 ms  0.932 ms

Published: 2010-04-15