- play_arrow Port Security
- play_arrow Port Security Overview
-
- play_arrow Digital Certificates
- play_arrow Configuring Digital Certificates
- Public Key Cryptography
- Configuring Digital Certificates
- Configuring Digital Certificates for an ES PIC
- IKE Policy for Digital Certificates on an ES PIC
- Configuring Digital Certificates for Adaptive Services Interfaces
- Configuring Auto-Reenrollment of a Router Certificate
- IPsec Tunnel Traffic Configuration
- Tracing Operations for Security Services
- play_arrow Configuring SSH and SSL Router Access
-
- play_arrow Trusted Platform Module
- play_arrow MACsec
- play_arrow Understanding MACsec
- play_arrow MACsec Examples
-
- play_arrow MAC Limiting and Move Limiting
- play_arrow MAC Limiting and Move Limiting Configurations and Examples
- Understanding MAC Limiting and MAC Move Limiting
- Understanding MAC Limiting on Layer 3 Routing Interfaces
- Understanding and Using Persistent MAC Learning
- Configuring MAC Limiting
- Example: Configuring MAC Limiting
- Verifying That MAC Limiting Is Working Correctly
- Override a MAC Limit Applied to All Interfaces
- Configuring MAC Move Limiting (ELS)
- Verifying That MAC Move Limiting Is Working Correctly
- Verifying That the Port Error Disable Setting Is Working Correctly
-
- play_arrow DHCP Protection
- play_arrow DHCPv4 and DHCPv6
- play_arrow DHCP Snooping
- Understanding DHCP Snooping (ELS)
- Understanding DHCP Snooping (non-ELS)
- Understanding DHCP Snooping Trust-All Configuration
- Enabling DHCP Snooping (non-ELS)
- Configuring Static DHCP IP Addresses
- Example: Protecting Against Address Spoofing and Layer 2 DoS Attacks
- Example: Protecting Against DHCP Snooping Database Attacks
- Example: Protecting Against ARP Spoofing Attacks
- Example: Prioritizing Snooped and Inspected Packet
- Configuring DHCP Security with Q-in-Q Tunneling in Service Provider Style
- play_arrow DHCP Option 82
- play_arrow Dynamic ARP Inspection (DAI)
-
- play_arrow IP Source Guard
- play_arrow Understanding IP Source Guard
- play_arrow IP Source Guard Examples
- Example: Configuring IP Source Guard on a Data VLAN That Shares an Interface with a Voice VLAN
- Example: Configuring IP Source Guard with Other EX Series Switch Features to Mitigate Address-Spoofing Attacks on Untrusted Access Interfaces
- Example: Configuring IP Source Guard and Dynamic ARP Inspection to Protect the Switch from IP Spoofing and ARP Spoofing
- Example: Configuring IPv6 Source Guard and Neighbor Discovery Inspection to Protect a Switch from IPv6 Address Spoofing
- Configuring IP Source Guard to Mitigate the Effects of Source IP Address Spoofing and Source MAC Address Spoofing
- Example: Configuring IP Source Guard and Dynamic ARP Inspection on a Specified Bridge Domain to Protect the Devices Against Attacks
- Example: Configuring IPv6 Source Guard and Neighbor Discovery Inspection to Protect a Switch from IPv6 Address Spoofing
-
- play_arrow IPv6 Access Security
- play_arrow Neighbor Discovery Protocol
- play_arrow SLAAC Snooping
- play_arrow Router Advertisement Guard
-
- play_arrow Control Plane Distributed Denial-of-Service (DDoS) Protection and Flow Detection
- play_arrow Control Plane DDoS Protection
- play_arrow Flow Detection and Culprit Flows
-
- play_arrow Unicast Forwarding
- play_arrow Unicast Reverse Path Forwarding
- play_arrow Unknown Unicast Forwarding
-
- play_arrow Storm Control
- play_arrow Malware Protection
- play_arrow Juniper Malware Removal Tool
-
- play_arrow Configuration Statements and Operational Commands
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 statisticstraceroute
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
