[an error occurred while processing this directive][an error occurred while processing this directive]

Example: IKE Dynamic SA Between an AS PIC and an ES PIC Configuration

Figure 1: AS PIC to ES PIC IKE Dynamic SA Topology Diagram

Image g015520.gif

Figure 1 shows a hybrid configuration that allows you to create an IPSec tunnel between the AS PIC and the ES PIC. Router 2 contains an AS PIC at sp-1/2/0 and Router 3 has an ES PIC at es-0/3/0. To establish an IPSec tunnel using an IKE dynamic SA, the key is to learn the default IKE SA and IPSec SA settings built into the AS PIC and configure them explicitly on the ES PIC. Routers 1 and 4 again provide basic connectivity and are used to verify that the IPSec tunnel is operational.

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, include match conditions in the rule-ike IPSec VPN rule to match inbound traffic from Router 1 that is destined for Router 4. Because the rule is already referenced by the service set, apply the service set to the so-0/0/1 interface. To count the amount of traffic that enters the IPSec tunnel, configure a firewall filter called ipsec-tunnel and apply it to the sp-1/2/0 interface.

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 { service { # Apply the service set here. input { service-set service-set-dynamic-BiEspsha3des;} output { service-set service-set-dynamic-BiEspsha3des;}}address 10.1.15.1/30;}}}sp-1/2/0 {services-options {syslog {host local {services info;}}}unit 0 {family inet {filter { input ipsec-tunnel; # Apply the firewall filter with the counter here.}}}}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 so-0/0/1.0;interface lo0.0;}}}firewall { filter ipsec-tunnel { # Configure a firewall filter to count IPSec traffic here.term 1 {then {count ipsec-tunnel;accept;}}}}services { service-set service-set-dynamic-BiEspsha3des { # Define your service set here.interface-service { service-interface sp-1/2/0; # Specify an interface to process IPSec.}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 {from {source-address {10.1.12.0/24;}destination-address {10.1.56.0/24;}}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 proposal here.}}} match-direction output; # 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 called sa-dynamic at the [edit security ipsec security-association] hierarchy level. To allow the ES PIC to communicate with the IKE dynamic SA established on Router 2, you must explicitly configure the same policies and proposals on the ES PIC that are available by default on the AS PIC. (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.)

For your IKE policy and proposal, use preshared keys for the authentication method, SHA-1 for the authentication algorithm, 3DES-CBC for encryption, group 2 for the Diffie-Hellman group, main mode, 3600 seconds for the lifetime, and a preshared key of juniper for the initial IKE negotiation. For your IPSec policy and proposal, use ESP for the protocol, HMAC-SHA1-96 for authentication, 3DES-CBC for encryption, 28800 seconds for the lifetime, and group 2 for the PFS group.

To direct traffic into the ES PIC and the IPSec tunnel, create two firewall filters. The es-traffic filter matches inbound traffic from Router 4 destined for Router 1, whereas the es-return filter matches the return path from Router 1 to Router 4. Apply the es-traffic filter to the so-0/0/0 interface; then apply both the es-return filter and the sa-dynamic SA to the es-0/3/0 interface.

Router 3

[edit]interfaces {so-0/0/0 {description "To R4 so-0/0/0";unit 0 {family inet {filter { input es-traffic; # Apply a filter that sends traffic to the IPSec tunnel here.}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;}}}es-0/3/0 {unit 0 { tunnel { # Specify the IPSec tunnel endpoints here.source 10.1.15.2;destination 10.1.15.1;}family inet { ipsec-sa sa-dynamic; # Apply the dynamic SA here.filter { input es-return; # Apply the filter that matches return IPSec traffic here.}}}}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 so-0/0/1.0;interface lo0.0;}}}security {ipsec { proposal es-ipsec-proposal { # Define your IPSec proposal specifications here.protocol esp;authentication-algorithm hmac-sha1-96;encryption-algorithm 3des-cbc;lifetime-seconds 28800;} policy es-ipsec-policy { # Define your IPSec policy specifications here.perfect-forward-secrecy {keys group2;} proposals es-ipsec-proposal; # Reference the IPSec proposal here.} security-association sa-dynamic { # Define your dynamic SA here. mode tunnel; dynamic { ipsec-policy es-ipsec-policy; # Reference the IPSec policy here.}}}ike { proposal es-ike-proposal { # Define your IKE proposal specifications here.authentication-method pre-shared-keys;dh-group group2;authentication-algorithm sha1;encryption-algorithm 3des-cbc;lifetime-seconds 3600;} policy 10.1.15.1 { # Define your IKE policy specifications here.mode main; proposals es-ike-proposal; # Reference the IKE proposal here. pre-shared-key ascii-text "$9$TF6ABIcvWxp0WxNdg4QFn"; ## The unencrypted preshared key for this example is juniper.}}}firewall { filter es-traffic { # Define a filter that sends traffic to the IPSec tunnel here.term to-es {from {source-address {10.1.56.0/24;}destination-address {10.1.12.0/24;}}then {count ipsec-tunnel;ipsec-sa sa-dynamic;}}term other {then accept;}} filter es-return { # Define a filter that matches return IPSec traffic here.term return {from {source-address {10.1.12.0/24;}destination-address {10.1.56.0/24;}}then accept;}}}

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)
  • traceroute

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

  • ping
  • show ike security-associations (detail)
  • show ipsec security-associations (detail)
  • 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 of 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=253 time=1.172 ms
64 bytes from 10.1.56.2: icmp_seq=1 ttl=253 time=1.020 ms
64 bytes from 10.1.56.2: icmp_seq=2 ttl=253 time=0.998 ms
64 bytes from 10.1.56.2: icmp_seq=3 ttl=253 time=1.037 ms
^C
--- 10.1.56.2 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.998/1.057/1.172/0.068 ms

You can also issue the traceroute command to verify that traffic to 10.1.56.2 travels over the IPSec tunnel between Router 2 and Router 3. Notice that the traced path does not reference 10.1.15.2—the physical interface on Router 3. Instead, traffic arriving at Router 2 is immediately filtered into the IPSec tunnel and the path is listed as unknown with the *** notation. This indicates that the IPSec tunnel is operating correctly.


user@R1> traceroute 10.1.56.2
traceroute to 10.1.56.2 (10.1.56.2), 30 hops max, 40 byte packets
 1  * * *
 2  10.1.56.2 (10.1.56.2)  1.045 ms  0.915 ms  0.850 ms

Router 2

One way to verify that matched traffic is being diverted to the bidirectional IPSec tunnel is to view the firewall filter counter. Before any traffic flows, the ipsec-tunnel firewall filter counter looks like this:


user@R2> show firewall filter ipsec-tunnel
Filter: ipsec-tunnel                                           
Counters:
Name                                                Bytes              Packets
ipsec-tunnel                                            0                    0

After you issue the ping command from Router 1 (four packets) to 10.1.56.2, the ipsec-tunnel firewall filter counter looks like this:


user@R2> show firewall filter ipsec-tunnel
Filter: ipsec-tunnel
Counters:
Name                                                Bytes              Packets
ipsec-tunnel                                          336                    4

After you issue the ping command from both Router 1 to 10.1.56.2 (four packets) and from Router 4 to 10.1.12.2 (six packets), the ipsec-tunnel firewall filter counter looks like this:


user@R2> show firewall filter ipsec-tunnel
Filter: es-traffic
Counters:
Name                                                Bytes              Packets
ipsec-tunnel                                          840                   10

To verify that the IKE SA negotiation is successful, issue the show services ipsec-vpn ike security-associations detail command. Notice that the SA contains the default IKE settings inherent in the AS PIC, such as SHA-1 for the authentication algorithm and 3DES-CBC for the encryption algorithm.


user@R2> show services ipsec-vpn ike security-associations detail
IKE peer 10.1.15.2
  Role: Responder, State: Matured
  Initiator cookie: c8e1e4c0da000040, Responder cookie: 4fbaa5184e000044
  Exchange type: Main, Authentication method: Pre-shared-keys
  Local: 10.1.15.1:500, Remote: 10.1.15.2:500
  Lifetime: Expires in 3535 seconds
  Algorithms:
   Authentication        : sha1 
   Encryption            : 3des-cbc
   Pseudo random function: hmac-sha1
  Traffic statistics:
   Input  bytes  :                  840
   Output bytes  :                  756
   Input  packets:                    5
   Output packets:                    4
  Flags: Caller notification sent 
  IPSec security associations: 1 created, 0 deleted
  Phase 2 negotiations in progress: 0

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: 407204513, AUX-SPI: 0
    Mode: tunnel, Type: dynamic, State: Installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
    Soft lifetime: Expires in 24546 seconds
    Hard lifetime: Expires in 24636 seconds
    Anti-replay service: Disabled
    Direction: outbound, SPI: 2957235894, AUX-SPI: 0
    Mode: tunnel, Type: dynamic, State: Installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
    Soft lifetime: Expires in 24546 seconds
    Hard lifetime: Expires in 24636 seconds
    Anti-replay service: Disabled

Router 3

View the firewall filter counter to continue verifying that matched traffic is being diverted to the bidirectional IPSec tunnel. After you issue the ping command from Router 1 (four packets), the es-traffic firewall filter counter looks like this:


user@R3> show firewall filter es-traffic
Filter: es-traffic
Counters:
Name                                                Bytes              Packets
ipsec-tunnel                                          336                    4

After you issue the ping command from both Router 1 (four packets) and Router 4 (six packets), the es-traffic firewall filter counter looks like this:


user@R3> show firewall filter es-traffic
Filter: es-traffic
Counters:
Name                                                Bytes              Packets
ipsec-tunnel                                          840                   10

To verify the success of the IKE security association on the ES PIC, issue the show ike security-associations detail command. Notice that the IKE SA on Router 3 contains the same settings you specified on Router 2.


user@R3> show ike security-associations detail
IKE peer 10.1.15.1
  Role: Initiator, State: Matured
  Initiator cookie: c8e1e4c0da000040, Responder cookie: 4fbaa5184e000044
  Exchange type: Main, Authentication method: Pre-shared-keys
  Local: 10.1.15.2:500, Remote: 10.1.15.1:500
  Lifetime: Expires in 3441 seconds
  Algorithms:
   Authentication        : sha1 
   Encryption            : 3des-cbc
   Pseudo random function: hmac-sha1
  Traffic statistics:
   Input  bytes  :                  756
   Output bytes  :                  840
   Input  packets:                    4
   Output packets:                    5
  Flags: Caller notification sent 
  IPSec security associations: 1 created, 0 deleted
  Phase 2 negotiations in progress: 0

To verify that the IPSec security association is active, issue the show ipsec security-associations detail command. Notice that the IPSec SA on Router 3 contains the same settings you specified on Router 2.


user@R3> show ipsec security-associations detail
Security association: sa-dynamic, Interface family: Up
  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: 2957235894, AUX-SPI: 0
    Mode: tunnel, Type: dynamic, State: Installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
    Soft lifetime: Expires in 28555 seconds
    Hard lifetime: Expires in 28690 seconds
    Anti-replay service: Disabled
    Direction: outbound, SPI: 407204513, AUX-SPI: 0
    Mode: tunnel, Type: dynamic, State: Installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
    Soft lifetime: Expires in 28555 seconds
    Hard lifetime: Expires in 28690 seconds
    Anti-replay service: Disabled

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

Again, the traceroute command verifies that traffic to 10.1.12.2 travels over the IPSec tunnel between Router 3 and Router 2. Notice that the second hop does not reference 10.1.15.1—the physical interface on Router 2. Instead, the second hop is listed as unknown with the *** notation. This indicates that the IPSec tunnel is operating correctly.


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.56.1 (10.1.56.1)  3.561 ms  0.613 ms  0.558 ms
 2  * * *
 3  10.1.12.2 (10.1.12.2)  1.073 ms  0.862 ms  0.818 ms

Published: 2010-04-15

[an error occurred while processing this directive]