Example: AS PIC IKE Dynamic SA Configuration
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.
When you do not specify an IKE proposal, an IPSec proposal, and an IPSec policy on an AS PIC, the Junos OS 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 Configuring IKE Dynamic SAs.
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 Configuring IKE Dynamic SAs.)
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 "$ABC123";
## 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 Configuring IKE Dynamic SAs.)
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 "$ABC123";
## 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