Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Deploying Service Chain (cSRX) with Cloud-Native Router

Read this section to learn how to customize and deploy a security services instance (cSRX) with the Cloud-Native Router.

You can integrate the Juniper Cloud-Native Router with Juniper's containerized SRX (cSRX) platform to provide security services such as IPsec. Using host-based service chaining, 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. The cSRX instance is customized and deployed via a Helm chart.

You have the option of deploying Juniper cSRX when you're installing Cloud-Native Router or after you've installed JCNR. See Cloud-Native Router Software Download Packages for a description of the available packages.

cSRX is supported on all Cloud-Native Router platforms:

Table 1: cSRX Supported Platforms
Platform cSRX
Bare Metal Yes
Red Hat OpenShift Yes
Amazon EKS Yes
Google Cloud Platform Yes
Wind River Cloud Platform Yes
Microsoft Azure Yes
VMWare Tanzu Yes

Deployment Patterns

Cloud-Native Router supports three deployment patterns for IPSec tunnels with cSRX service chaining. Each pattern addresses different scale and isolation requirements.

Single-Tenant, Multiple Tunnels

A single customer establishes multiple IPSec tunnels to different destinations using one cSRX instance. All tunnels share the same trust and untrust VRF pair on JCNR. For example, an enterprise with multiple branch offices can establish separate tunnels from each branch to a central site.

  • One trust VRF and one untrust VRF on JCNR

  • Two interfaces between JCNR and cSRX (ge-0/0/0 for untrust, ge-0/0/1 for trust)

  • Multiple IPSec tunnels share the same source IP address

Multi-Tenant, Multiple Tunnels

Multiple customers share the same 5G gateway infrastructure, with each customer receiving dedicated trust and untrust VRF pairs for traffic isolation. A single cSRX instance serves all tenants. For example, a telecommunications provider hosts IPSec services for multiple enterprise customers on shared gateway infrastructure.

  • Dedicated trust VRF per tenant (required for isolation)

  • Untrust VRFs may be shared or dedicated per tenant

  • Each tenant uses dedicated interfaces between JCNR and cSRX

Multiple cSRX Instances

For large-scale deployments requiring additional IPSec tunnel capacity, you can deploy multiple cSRX instances on a single JCNR. Each cSRX instance is deployed in a separate Kubernetes namespace with dedicated VRFs to ensure complete traffic isolation between instances.

  • Each cSRX instance deploys in a separate Kubernetes namespace with dedicated VRFs

  • Each cSRX instance requires minimum 2 vCPUs and appropriate memory resources

  • No hard limit on number of instances; limited only by available cluster resources

Choosing a Configuration Method

Cloud-Native Router supports two methods for configuring IPSec tunnels:

Helm-Based Configuration

Helm-based configuration (enableUserConfig: false):

  • All IPSec tunnel configuration happens at installation time

  • Configuration is defined in the ipSecTunnelConfigs section of values.yaml

  • Recommended for single-tunnel deployments

  • cSRX automatically generates and applies the configuration during installation

User-Based Configuration

User-based configuration (enableUserConfig: true):

  • Interface configuration happens at installation time via Helm

  • Allows you to apply IPSec tunnel configuration post-deployment using a configlet or CLI

  • Recommended for multi-tenant and multiple cSRX instance deployments

  • Enables dynamic configuration changes without redeploying cSRX

  • Supports additional IPSec parameters not available in Helm

Install cSRX on an Existing Cloud-Native Router Installation

Follow this procedure to install a cSRX instance on an existing Cloud-Native Router installation. Ensure all Cloud-Native Router components are up and running before you start this procedure.

  1. Download and expand the software package for installing Juniper cSRX on an existing Cloud-Native Router installation. See Cloud-Native Router Software Download Packages for a description of the software packages available.
  2. Change to the junos_csrx_<release>/helmchart directory and expand the Helm chart.
    The Helm chart is located in the junos-csrx directory.
  3. The cSRX container images are required for deployment. Choose one of the following options:
    • Configure your cluster to deploy images from the Juniper Networks enterprise-hub.juniper.net repository. See Configure Repository Credentials for example instructions on how to configure repository credentials in Helm charts.

    • Configure your cluster to deploy images from the image tarball included in the downloaded cSRX software package. See Deploy Prepackaged Images for example instructions on how to import images to the local containerd runtime.

  4. Follow the steps in Apply the cSRX License and Configure cSRX to apply your cSRX license and configure the cSRX Helm chart.
  5. Install cSRX.
    Navigate to the junos_csrx_<release>/helmchart/junos-csrx directory and issue the following command to install the cSRX instance.
    Note:

    To deploy additional cSRX instances on the same JCNR node, repeat these steps with a new namespace and a unique Helm release name. For example, to deploy a second instance in the jcnr2 namespace:

    Ensure the second instance uses different VRF targets and IP ranges from the first instance. See Apply the cSRX License and Configure cSRX for namespace and secret creation steps for additional instances.

Install cSRX During Cloud-Native Router Installation

Follow the steps in the respective Cloud-Native Router installation sections to install JCNR. One of the steps will refer you to Apply the cSRX License and Configure cSRX.

Apply the cSRX License and Configure cSRX

Follow this procedure to apply your cSRX license and configure Juniper cSRX.

The following steps assume you're in the Juniper_Cloud_Native_Router_CSRX_<release> directory if installing cSRX and Cloud-Native Router together, or in the junos_csrx_<release> directory if installing cSRX on an existing Cloud-Native Router installation.

  1. Copy the cluster kubeconfig to all nodes where you want to install the Cloud-Native Router and cSRX combination.
    This step applies to both installing cSRX during Cloud-Native Router installation and installing cSRX on an existing Cloud-Native Router installation. If you don't perform this step, the installation may fail.
    1. Copy the cluster kubeconfig to a location of your choice on the target node.
      For example, the following copies the cluster kubeconfig from its default location at ~/.kube/config to /root/kubeconfig on the target node:where <worker-node-ip> is the IP address of a node where you want to install both Cloud-Native Router and cSRX. Repeat for all nodes where you want to install both Cloud-Native Router and cSRX.
      Note:

      The destination file path must be the same on all target nodes.

    2. After copying the kubeconfig to all target nodes, set kubeConfigPath in values.yaml to the destination file location.
      For example:See Customize cSRX Helm Chart for information on the parameters in values.yaml.
  2. Apply your Juniper cSRX license.
    1. If the secrets/csrx-secrets.yaml doesn't exist in your software package, create it with the contents below:
    2. Encode your license in base64.

      Copy your Juniper cSRX license file onto your host server and issue the command:

      The output of this command is your base64-encoded license.
    3. Replace <add your license in base64 format> with your base64-encoded license.
      Note:

      You must obtain your license file from your account team and install it in the secrets/csrx-secrets.yaml file as instructed above. The csrx-init container performs a license check and proceeds only if the required secret service-chain-instance is found.

    4. Encode your root password in base64. The root password is required for NETCONF access for telemetry.
      Encode your password as follows: The output of this command is your base64-encoded root password.
    5. Replace <add your root password in base64 format> with your base64-encoded root password.
    6. Apply the secrets/csrx-secrets.yaml to the Kubernetes cluster.
    7. To deploy additional cSRX instances, create a namespace and apply a secret for each additional instance before installing it.

      For example, for a second instance in the jcnr2 namespace, create the namespace:

      Create and apply the secret to the jcnr2 namespace:

      Repeat this step for each additional cSRX instance, using a unique namespace for each.

  3. Configure the cSRX Helm chart.
    • If you're installing cSRX at the same time you're installing JCNR, then you're configuring the junos-csrx section of the combination Helm chart in Juniper_Cloud_Native_Router_CSRX_<release>/helmchart/jcnr_csrx/values.yaml.

    • If you're installing cSRX on an existing Cloud-Native Router installation, then you're configuring the csrx section of the standalone Helm chart in junos_csrx_<release>/helmchart/junos-csrx/values.yaml.

    Refer to the cSRX parameter descriptions in Customize cSRX Helm Chart.

Customize cSRX Helm Chart

The cSRX service chaining instance is deployed via a Helm chart, either a standalone Helm chart or a combined Helm chart with JCNR. The deployment consists of two essential components:

  • csrx-init: This is an init container that prepares the configuration for the main cSRX application. It extracts the necessary information from the values.yaml file, processes it, and generates the configuration data for cSRX. This ensures that the main cSRX application starts with a valid, up-to-date configuration.

  • csrx: The csrx is the main application container and the core component of the cSRX deployment. It relies on the configuration provided by the csrx-init container to function correctly.

You can customize the cSRX deployment by specifying a range of configuration parameters in the values.yaml file. Key configuration options include:

  • kubeConfigPath: This is the path to the cluster kubeconfig file on the node(s) where you're installing Cloud-Native Router and cSRX. You copied the cluster kubeconfig to this file location on this node(s) in step 1 in Apply the cSRX License and Configure cSRX. If this parameter is commented out, then the cluster kubeconfig is assumed to be at /etc/kubernetes/kubelet.conf.

  • 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. The interface IP must match the localAddress element in the ipSecTunnelConfigs array. The routes should contain prefixes to steer decrypted traffic to Cloud-Native Router and reachability route for IPSec gateway.

  • enableUserConfig:

    • Set to false if you want cSRX to create your IPSec tunnels now during installation. Define your IPSec tunnels in the ipSecTunnelConfigs section of this Helm chart. cSRX will automatically create a configlet based on that configuration and apply it for you during cSRX installation.

    • Set to true if you want to create your IPSec tunnels on your own later. In this case, you don't define your ipSecTunnelConfigs in this Helm chart. Instead, you'll define your IPSec configuration directly in a configlet and explicitly apply it anytime after cSRX is installed.

  • 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. This section is only applicable if enableUserConfig is set to false.

  • 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.

  • telemetry: Enable or disable telemetry.

Here is the default values.yaml for standalone cSRX deployment:

Configuring cSRX via Helm Chart

The cSRX configurations are required to bring up its containers and pods at the time of installation. The IPSec tunnel configuration can be defined at the time of installation or later using a configlet. The enableUserConfig flag in the cSRX Helm chart when set to true enables IPSec tunnel configuration via configlet.

By default the enableUserConfig flag is set to false in values.yaml and therefore requires ipSecTunnelConfigs to be configured at the time of installation. You can configure multiple tunnels in a cSRX instance for both single-tenancy and multi-tenancy deployment.

Single-Tenancy, Multiple Tunnel Deployment

A sample interface and tunnel configuration for single-tenancy, multiple tunnels is provided below:

Multi-tenancy, Multiple Tunnel Deployment

For customers sharing the same 5G gateways, Cloud-Native Router supports a single cSRX service-chained instance, with dedicated trust and untrust interfaces and VRFs per tenant. The untrust interfaces and VRFs may be shared between customers, however the trust interfaces and VRFs must be dedicated per tenant. A sample interface and tunnel configuration for multi-tenancy, multiple tunnels is provided below:

Multiple cSRX Instances Deployment

For large-scale deployments requiring more IPSec tunnels than a single cSRX instance supports, deploy multiple cSRX instances on a single JCNR. Each cSRX instance is deployed in a separate Kubernetes namespace with dedicated VRFs.

A sample interface and tunnel configuration for the first cSRX instance in the jcnr namespace is provided below:

For the second cSRX instance, use a separate namespace and VRF targets. A sample configuration for the second instance is provided below:

Configuring cSRX IPSec Tunnel Configuration via Configlets

You can configure the IPSec tunnels after cSRX has been deployed using a configlet. The installation Helm chart must have enableUserConfig flag value set to true. The ipSecTunnelConfigs configuration snippet must not be defined. Sample Helm charts are provided in the installer bundle— /csrx_examples/values-user-config-csrx.yaml for cSRX only installation and /charts/junos-csrx/csrx_examples/values-user-config-unified.yaml for unified JCNR and cSRX installation. Both single-tenancy and multi-tenancy deployments are supported.

Single-Tenancy, Multiple-Tunnel Deployment

An example Helm chart for single-tenancy, multiple-tunnel deployment is provided below:

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:

Multi-tenancy, Multiple-Tunnel Deployment

For customers sharing the 5G gateways, you can configure cSRX in a multi-tenancy, multiple-tunnel deployment mode. An example Helm chart is provided below:

Sample configlet for multi-tenancy deployment is provided below:

Multiple cSRX Instances Deployment

For large-scale deployments requiring more IPSec tunnels than a single cSRX instance supports, deploy multiple cSRX instances with configlet-based IPSec configuration. Each cSRX instance is deployed in a separate Kubernetes namespace with dedicated VRFs.

An example Helm chart for the first cSRX instance in the jcnr namespace is provided below:

Sample configlet for applying IPSec tunnel configuration to the first instance in the jcnr namespace:

For the second cSRX instance, use a separate namespace and VRF targets. An example Helm chart for the second instance is provided below:

Sample configlet for the second instance in the jcnr2 namespace. Note the namespace specification in the metadata:

Configuration Examples

Single cSRX Instance Deployment

Let us look at a configuration example for Cloud-Native Router with security services. Consider the following network topology:Network diagram showing OSPF connection between Cell-Site and Core DC. Cell-Site has IP 10.111.1.10/32 and Core DC has IP 10.222.1.10/32. Both sites use vRouters with VRF Trust and Untrust.

The topology consists of a Cloud-Native Router on the cell-site and a Cloud-Native Router in the core data center. Both Cloud-Native Routers 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 Cloud-Native Router'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 Cloud-Native Router.

  • 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 Cloud-Native Router.

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 Cloud-Native Router:

    2. Helm chart configuration for remote Cloud-Native Router:

      Once you have configured the Helm chart, you must deploy cSRX. See Install cSRX on an Existing Cloud-Native Router Installation for details on how to deploy cSRX for service chaining with Cloud-Native Router.

  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 Cloud-Native Router:

    2. Example configlet for OSPF on the remote Cloud-Native Router:

  3. Deploy the application pods with an interface attached to the trust VRF in Cloud-Native Router.

    1. Application pod on the cell-site:

    2. Application pod on the remote site:

Multiple cSRX Instances Deployment

This example demonstrates deploying two cSRX instances on a single JCNR to support additional IPSec tunnels beyond the capacity of a single cSRX instance. Each cSRX instance is deployed in a separate Kubernetes namespace with dedicated VRFs and independent IPSec tunnel configurations.

Let us look at the configuration steps:

  1. Deploy the first cSRX instance in the default jcnr namespace. Configure the Helm chart with enableUserConfig: true to enable configlet-based IPSec configuration.

    Deploy the first cSRX instance:

  2. Apply the IPSec tunnel configuration for the first cSRX instance via configlet in the jcnr namespace:

  3. Create a namespace for the second cSRX instance by running the following command:

  4. Create and apply the secret to the jcnr2 namespace by running the following command:

  5. For the second cSRX instance, configure the Helm chart with different VRFs and IP ranges:

    Deploy the second cSRX instance in the jcnr2 namespace:

  6. Apply the IPSec tunnel configuration for the second cSRX instance via configlet in the jcnr2 namespace:

  7. Deploy the application pod for the first cSRX instance with an interface attached to the trust VRF:

  8. Deploy the application pod for the second cSRX instance with an interface attached to the trust-1 VRF:

  9. To uninstall the cSRX instances, run the following commands:

    • First instance: helm uninstall csrx

    • Second instance: helm uninstall csrx2 -n jcnr2

Verify Configuration

Single cSRX Instance Verification

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:

Multiple cSRX Instances Verification

When deploying multiple cSRX instances, verify that each instance is running correctly, IPSec tunnels are established in their respective namespaces, and end-to-end traffic flows through the correct paths.

  1. Verify both cSRX instances are running in their respective namespaces:

  2. Verify namespace isolation by checking configlets are applied to the correct instances:

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

  4. Verify the cRPD Routing Tables:

  5. To verify the IPSec tunnel status for the first cSRX instance, 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:

  6. To verify the IPSec tunnel status for the second cSRX instance, login to the cSRX shell using the kubectl exec -it csrx_pod_name -n jcnr2 -- bash command. Type cli to navigate to the CLI mode. Verify the cSRX configuration, security associations and flows:

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