Description

Baseline IPSec VPN configuration and explanation with Interface-Style.

Solution

Topology 

                 sp-1/3/0.0                                    sp-1/2/0.0

                 fe-0/3/0.0   f e-0/3/0.0        fe-0/3/2.0 fe-0/3/0.0
LO:192.168.1.1 LAB----------------------DYSPROSIUM  -------------OXYGEN  LO:192.168.1.3
                 10.1.1.1        10.1.1.2        10.1.2.1    10.1.2.2
                   |                                                        |
                   |                                                        |
                   +--------------------------------------------------------+
                                       IPSEC TUNNEL
In the above topology the goal is to allow only interesting traffic from source 192.168.1.1 to destination 192.168.1.3 and vice-versa to use IPSec VPN tunnel.  In JUNOS there are two ways of accomplishing this goal i.e. by configuring IPSec VPN tunnel between LAB and OXYGEN router.  In JUNOS there are two methodologies to create an IPSec VPN tunnel:
  • Interface-style
  • Next-hop style

Interface-style Methodology:
Following steps explain about interface-style methodology with a minimum configuration and an explanation pertaining to the same to accomplish the above goal.

  1. First, define service-set.  Service-set basically contains the rule that identifies interesting traffic that can use the IPSec tunnel. The rules can include policies that link the various proposals that the tunnel will use. There can be separate policies and proposals for the Phase 1 (IKE) and Phase 2 (IPSec) SAs. Here is the relevant configuration:
    set interfaces sp-1/3/0 unit 0 family inet   <----- On LAB router
    set interfaces sp-1/2/0 unit 0 family inet   <----- On OXYGEN router
  2. Define an IKE policy referencing either a preshared key or a certificate on both routers i.e. LAB and OXYGEN.  The pre-shared key also must match on both routers for IKE phase to negotiate and to successfully be able to encrypt/decrypt the traffic.
    set services ipsec-vpn ike policy IKE-POLICY pre-shared-key ascii-text "$9$PTF/1IceMX/CyKvW-dk.P5T3"   <----- On LAB router
    set services ipsec-vpn ike policy IKE-POLICY pre-shared-key ascii-text "$9$PTF/1IceMX/CyKvW-dk.P5T3"   <----- On OXYGEN router
  3. Define an IPSec VPN rule to match on the interesting traffic using the IPSec VPN rule. The IKE policy defined in Step 2 also needs to be applied here to define the direction in which to encrypt the traffic.

    On LAB router
    set services ipsec-vpn rule secure-traffic term 1 from source-address 192.168.1.1/32
    set services ipsec-vpn rule secure-traffic term 1 from destination-address 192.168.1.3/32
    set services ipsec-vpn rule secure-traffic term 1 then remote-gateway 10.1.2.2
    set services ipsec-vpn rule secure-traffic term 1 then dynamic ike-policy IKE-POLICY
    set services ipsec-vpn rule secure-traffic match-direction output

    On OXYGEN router
    set services ipsec-vpn rule SECURE-TRAFFIC term 1 from source-address 192.168.1.3/32
    set services ipsec-vpn rule SECURE-TRAFFIC term 1 from destination-address 192.168.1.1/32
    set services ipsec-vpn rule SECURE-TRAFFIC term 1 then remote-gateway 10.1.1.1
    set services ipsec-vpn rule SECURE-TRAFFIC term 1 then dynamic ike-policy IKE-POLICY
    set services ipsec-vpn rule SECURE-TRAFFIC match-direction output
  4. Create the service set that maps the IPSec rule (defined in Step 3) and the service interface (defined in step1).   Additionally, configure the local gateway for the IPSec tunnel which will be the address used to source all IPSec packets; as well as the remote-gateway (which is configured in step3) which is the address for connecting the local tunnels to. Note, only a single gateway address can be in a service set, but you can configure multiple remote gateways in the IPSec rules.

    On LAB router
    set services service-set SP-INTERFACE-DEFINED ipsec-vpn-options local-gateway 10.1.1.1
    set services service-set SP-INTERFACE-DEFINED ipsec-vpn-rules secure-traffic
    set services service-set SP-INTERFACE-DEFINED interface-service service-interface sp-1/3/0.0

    On OXYGEN router
    set services service-set SP-INTERFACE-DEFINED ipsec-vpn-options local-gateway 10.1.2.2
    set services service-set SP-INTERFACE-DEFINED ipsec-vpn-rules SECURE-TRAFFIC
    set services service-set SP-INTERFACE-DEFINED interface-service service-interface sp-1/2/0.0
  5. Define the traffic that will be allowed service by AS-PIC and the traffic that should be skipped.  In the topology above,  we are running OSPF across all the interfaces for IPSec tunnel endpoints to be reachable by the intermediate routers.  Also, as per our goal, would like to have only traffic from source 1.1.1.1 and destination 3.3.3.3 (and vice-versa) should transit via the IPSec tunnel.  Hence only this traffic should be allowed from being serviced by the service-pic and all other traffic should be skipped from it.  Here is the relevant configuration defining the same.

    On LAB router
    set protocols ospf area 0.0.0.0 interface all
    set firewall family inet service-filter OUTPUT term 1 from source-address 192.168.1.1/32
    set firewall family inet service-filter OUTPUT term 1 from destination-address 192.168.1.3/32
    set firewall family inet service-filter OUTPUT term 1 then service
    set firewall family inet service-filter OUTPUT term 2 then skip

    set firewall family inet service-filter INPUT term 1 from source-address 10.1.2.2/32
    set firewall family inet service-filter INPUT term 1 from destination-address 10.1.1.1/32
    set firewall family inet service-filter INPUT term 1 then service
    set firewall family inet service-filter INPUT term 2 then skip

    On OXYGEN router
    set firewall family inet service-filter INPUT term 1 from source-address 10.1.1.1/32
    set firewall family inet service-filter INPUT term 1 from destination-address 10.1.2.2/32
    set firewall family inet service-filter INPUT term 1 then service
    set firewall family inet service-filter INPUT term 2 then skip

    set firewall family inet service-filter OUTPUT term 1 from source-address 192.168.1.3/32
    set firewall family inet service-filter OUTPUT term 1 from destination-address 192.168.1.1/32
    set firewall family inet service-filter OUTPUT term 1 then service
    set firewall family inet service-filter OUTPUT term 2 then skip

    Note: All other traffic should be skipped from being serviced as defined in term 2. This is very important else OSPF hello packets received from Dysprosium also may get serviced by service-pic; leading to the OSPF neighborship going down.
     
  6. Finally, apply these filters on the tunnel outbound interface i.e. fe-0/3/0.0 on LAB and fe-0/3/0.0 on OXYGEN.

    On LAB router
    set interfaces fe-0/3/0 unit 0 family inet service input service-set SP-INTERFACE-DEFINED service-filter INPUT
    set interfaces fe-0/3/0 unit 0 family inet service output service-set SP-INTERFACE-DEFINED service-filter OUTPUT
    set interfaces fe-0/3/0 unit 0 family inet address 10.1.1.1/30

    On OXYGEN router
    set interfaces fe-0/3/0 unit 0 family inet service input service-set SP-INTERFACE-DEFINED service-filter INPUT
    set interfaces fe-0/3/0 unit 0 family inet service output service-set SP-INTERFACE-DEFINED service-filter OUTPUT
    set interfaces fe-0/3/0 unit 0 family inet address 10.1.2.2/30

After configuring all the required steps as given on both LAB and OXYGEN routers, it is time to configure the Dysprosium router. Dysprosium simply needs to be configured for OSPF.  No other special configuration is required since it is simply acting as a transit router in between the IPSEC tunnel.  Here is the configuration:

lab@DYP-R4# show | display set
set version 9.3R2.8
set interfaces fe-0/3/0 unit 0 family inet address 10.1.1.2/30
set interfaces fe-0/3/2 unit 0 family inet address 10.1.2.1/30
set protocols ospf area 0.0.0.0 interface all

To test out the configuration, ping from source 192.168.1.1 to destination 192.168.1.3.  You should be able to see that traffic is transiting via IPSec VPN tunnel.  Following commands can be used to verify whether IPSec VPN is working as expected:
  • show services ipsec-vpn ike security-associations   <-----  Check whether IKE is in a matured state under state
  • show services ipsec-vpn ipsec security-associations   <----- If there is a continuous ping then should be able to see that packets in inbound/outbound direction are increasing.
  • show services ipsec-vpn ipsec statistics   <----- Use to verify whether packets transiting via IPSec tunnel are getting encrypted/decrypted.

Note: When pinging between source and destination, if the counters for encrypted/decrypted packets do not increment then possibly the traffic is not going via IPSec VPN tunnel thereby defeating the goal. In that case there is a need to check the configuration to that given above.

Modification History

2022-12-29: Updated non-compliant IP addresses to RFC standards