IPsec Security Services

Overview

Let us consider an IPsec security services use case with JCNR. In the figure below, the cloud-native router connects the provider edge (PE) routers in a service provider network. The customer edge (CE) routers or devices in the source network securely transfer data to the destination CEs via an IPsec tunnel. In the given scenario, the IPsec tunnel initiates from the cloud-native router's security services (cSRX) and terminates on the destination CEs. The cloud-native router and its peer PE provides the underlay connectivity to the IPsec tunnel.

The cloud-native router is chained with a security service instance (cSRX) in the same Kubernetes cluster. The cSRX instance runs as a pod service in L3 mode.

Note:

A cloud-native router instance is service chained with only one instance of cSRX. It can support multiple IPSec tunnels.

Configuration

Cloud-Native Router can steer selective traffic through IPsec services. This is achieved by defining static routes to a destination via the cSRX interface. When the selective traffic is received on JCNR, it is forwarded to cSRX. The cSRX subjects the packet to IPsec encryption based on the configuration and forwards it to JCNR. Cloud-Native Router performs a route lookup in the untrust VRF and forwards traffic through the configured fabric interface. When IPsec packet is received from the remote end, Cloud-Native Router sends it to the security services. The cSRX decrypts the packet and forwards it to Cloud-Native Router on the trust interface. Cloud-Native Router then forwards the packet to the pod. The IP addresses of the tunnel endpoints are configured in Cloud-Native Router as static routes and advertised through an IGP to the remote end.

You can customize the cSRX deployment by specifying a range of configuration parameters in the helm chart (values.yaml) for cSRX. Key configuration options include:

• interfaceType: This is the type of interface on the cSRX to connect to JCNR. Must be set to vhost only.

• interfaceConfigs: This is an array defining the interface IP address, gateway address and optionally routes. One of the interface IP must match the localAddress element in the ipSecTunnelConfigs array. This will be the interface in the untrust zone. The routes should contain prefixes to steer decrypted traffic to Cloud-Native Router and reachability route for IPSec gateway.

• ipSecTunnelConfigs: This is an array defining the IPsec configuration details such as ike-phase1, proposal, policy and gateway configuration. Traffic selector should contain traffic that is expected to be encrypted. You can define one or multiple tunnel configurations. You can either define the tunnel configuration using the installation helm chart or configure them post-deployment using a configlet.

• jcnr_config: This is an array defining the routes to be configured in Cloud-Native Router to steer traffic from Cloud-Native Router to cSRX and to steer IPsec traffic from the remote IPsec gateway to the cSRX to apply the security service chain.

You can create IPSec tunnels or modify tunnel configuration after deployment using a configlet. A sample configlet has been provided in the installer bundle—/csrx_examples/ipsec-tunnel-config-cr.yaml for cSRX only installation and /charts/junos-csrx/csrx_examples/ipsec-tunnel-config-cr.yaml for unified JCNR and cSRX installation. An example configlet is provided below:

Configuration Example

Let us look at a configuration example for Cloud-Native Router with security services. Consider the following network topology:

The topology consists of a Cloud-Native Router on the cell-site and a Cloud-Native Router in the core data center. Both JCNRs are service chained with cSRX. The core data center can also have any other physical or virtual firewall function as the tunnel endpoint. The traffic between pods 10.111.1.10 and 10.222.1.10 must be encrypted through an IPsec tunnel. The IP addresses and gateway addresses for the cSRX-Cloud-Native Router interface are also illustrated.

cSRX connects with JCNR’s forwarding plane (vRouter) using two interfaces:

• ge-0/0/1 interface is used to send traffic from Cloud-Native Router to security services for IPsec encryption and from security services to Cloud-Native Router after IPsec decryption. This interface is a part of the trust zone in cSRX and trust VRF in JCNR.
• ge-0/0/0 interface is used to send traffic from security services to Cloud-Native Router after IPsec encryption and from Cloud-Native Router to security services for IPsec decryption. This interface is part of the untrust zone in cSRX and untrust VRF in JCNR.

Let us look at the configuration steps:

1. Configure the cSRX helm chart with correct interfaceConfigs, ipSecTunnelConfigs and jcnr_config for the topology.
   1. Helm chart configuration for cell-site JCNR:

   2. Helm chart configuration for remote JCNR:

      Once you have configured the helm chart, you must deploy cSRX.

      Please review the Deploying Service Chain (cSRX) with JCNR topic for details on how to deploy cSRX for service chaining with JCNR.

2. Configure the Cloud-Native Router fabric interface (ens192) to participate in the IGP running in the core. The configuration is performed in the untrust VRF.

   1. Example configlet for OSPF on the cell-site JCNR:

   2. Example configlet for OSPF on the remote JCNR:

3. Deploy the application pods with an interface attached to the trust VRF in JCNR.

   1. Application pod on the cell-site:

   2. Application pod on the remote site:

Verify Configuration

You can verify the configuration and traffic flows in cRPD, cSRX and vRouter.

1. Verify cRPD configuration for trust and untrust VRFs via the cRPD shell. The configuration is available under the cni configuration group.

2. Verify the cRPD Routing Tables:

3. Login to the cSRX shell using the kubectl exec -it csrx_pod_name -n jcnr -- bash command. Type cli to navigate to the CLI mode. Verify the cSRX configuration, security associations and flows:

4. You can also verify the flow in the vRouter CLI: