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
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
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
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
On Router 4, provide basic OSPF connectivity to Router 3.
Router 4
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
