Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Performing vSRX Advanced Tasks in IBM Cloud

Working with Firewalls

The IBM Cloud™ Juniper vSRX uses the concept of security zones, where each vSRX interface is mapped to a "zone" for handling stateful firewalls. Stateless firewalls are controlled by firewall filters.

Policies are used to allow and block traffic between these defined zones, and the rules defined here are stateful.

In the IBM Cloud, a vSRX is designed to have four different security zones:

Zone

Standalone Interface

HA Interface

SL-Private (untagged)

ge-0/0/0.0 or ae0.0

reth0.0

SL-Public (untagged)

ge-0/0/1.0 or ae1.0

reth1.1

Customer-Private (tagged)

ge-0/0/0.1 or ae0.1

reth2.1

Customer-Public (tagged)

ge-0/0/1.1 or ae1.1

reth3.1

Zone Policies

Following are some of the attributes that can be defined in your policies:

  • Source addresses

  • Destination addresses

  • Applications

  • Action (permit/deny/reject/count/log)

Since this is a stateful operation, there is no need to allow return packets (in this case, the echo replies).

To configure a stateful firewall, follow these steps:

  1. Create security zones and assign the respective interfaces:

    Standalone scenario:

    set security zones security-zone CUSTOMER-PRIVATE interfaces ge-0/0/0.1

    set security zones security-zone CUSTOMER-PUBLIC interfaces ge-0/0/1.1

    High Availability scenario:

    set security zones security-zone CUSTOMER-PRIVATE interfaces reth2.1

    set security zones security-zone CUSTOMER-PUBLIC interfaces reth2.1

  2. Define the policy and rules between two different zones.

    The following example illustrates pinging traffic from the zone Customer-Private to Customer-Public:

    set security policies from-zone CUSTOMER-PRIVATE to-zone CUSTOMER-PUBLIC policy

    set security policies from-zone CUSTOMER-PRIVATE to-zone CUSTOMER-PUBLIC policy

  3. Use the following commands to allow traffic that is directed to the vSRX:

    • Standalone scenario:

      set security zones security-zone CUSTOMER-PRIVATE interfaces ge-0/0/0.0 host-inbound-traffic system-services all

    • High Availability scenario:

      set security zones security-zone CUSTOMER-PRIVATE interfaces reth2.0 host-inbound-traffic system-services all

  4. To allow protocols, such as OSPF or BGP, use the following command:

    • Standalone scenario:

      set security zones security-zone trust interfaces ge-0/0/0.0 host-inbound-traffic protocols all

    • High Availability scenario:

      set security zones security-zone trust interfaces reth2.0 host-inbound-traffic protocols all

Firewall Filters

By default the IBM Cloud™ Juniper vSRX allows ping, SSH, and HTTPS to itself and drops all other traffic by applying the PROTECT-IN filter to the lo interface.

To configure a new stateless firewall, follow these steps:

  1. Create the firewall filter and term (the following filter allows only ICMP and drops all other traffic)

    set firewall filter ALLOW-PING term ICMP from protocol icmp

    set firewall filter ALLOW-PING term ICMP then accept

  2. Apply the filter rule to the interface (the following command applies the filter to all private network traffic)

    set interfaces ge-0/0/0 unit 0 family inet filter input ALLOW-PING

Working with sNAT

You can refer a sample configuration for sNAT on a vSRX appliance, where a private node routed behind the Gateway can communicate with the outside world at Working with sNAT

To configure NAT for the IBM Cloud™ Juniper vSRX, see Network Address Translation User Guide on the Juniper website.

Working with Failover

You can initiate failover from your primary IBM Cloud™ Juniper vSRX to a backup device, so that all control and data plane traffic is routed through the secondary gateway device after failover.

Note:

This section is only applicable if your Juniper vSRX gateway devices are provisioned in High-Availability mode.

Perform the following procedure:

  1. Login to your primary vSRX gateway device.

  2. Enter CLI mode by running the command cli at the console prompt. When you enter CLI mode, the console displays the node role, either primary or secondary.

  3. On the primary vSRX gateway device, run the command:

    show chassis cluster status

    Ensure that, for both redundancy groups, the same node is set as primary. It is possible for different nodes to be set as the primary role in different redundancy groups.

    Note:

    The vSRX, by default, sets Preempt to yes for Redundancy group 1, and no for Redundancy group 0. Refer to this link to learn more about pre-emption and failover behavior.

  4. Initiate failover by running the following command in the console prompt:

    request chassis cluster failover redundancy-group <redundancy group number> node <node number>

    Select the appropriate redundancy group number and node number from the output of the command in step two. To failover both redundancy groups, execute the previous command twice, one for each group.

  5. After failover is complete, verify the console output. It should now be listed as secondary.

  6. Login to the other vSRX gateway of your pair. Enter into CLI mode by again executing the command cli and then verify that the console output shows as primary.

    Tip:

    When you enter CLI mode in your Juniper vSRX gateway device, the output will show as primary from the control plane perspective. Always check the show chassis cluster status output to determine which gateway device is primary from data plane perspective. Refer to vSRX Default Configuration to learn more about redundancy groups, as well as the control and data planes.

Working with Routing

The IBM Cloud™ Juniper vSRX is based on JunOS, giving you access to the full Juniper routing stack.

  • Static routing—To configure static routes, run the following commands:

    Setting a default route—set routing-options static route 0/0 next-hop <Gateway IP>

  • Creating a static route—Run the set routing-options static route <PREFIX/MASK> next-hop <Gateway IP>

  • Basic OSPF routing—To setup basic OSPF routing, only using area 0, run the following commands using md5 authentication using the set protocols ospf area 0 interface ge-0/0/1.0 authentication md5 0 key <key> command.

  • Basic BGP routing

    • To setup basic BGP routing, first define the local AS by running the set routing-options autonomous-system 65001 command.

    • Then configure the BGP neighbor and its session attributes:

      set protocols bgp group CUSTOMER local-address 1.1.1.1

      set protocols bgp group CUSTOMER family inet unicast

      set protocols bgp group CUSTOMER family inet6 unicast

      set protocols bgp group CUSTOMER peer-as 65002

      set protocols bgp group CUSTOMER neighbor 2.2.2.2

      In this example, BGP is configured for the following:

      • To use source IP address of 1.1.1.1 to establish the session

      • To negotiate both ipv4 and ipv6 unicast families

      • To peer with a neighbor that belongs to AS 65002

      • Peer neighbor IP 2.2.2.2

For more configurations, see Junos OS Documentation

Working with VPN

This topic details a sample configuration for a Route based VPN between two sites. In this sample configuration Server 1 (Site A) can communicate with Server 2 (Site B), and each site utilizes two phase IPSEC authentication. For more information see Working with VPN and

Sample configuration for Site A (Dallas):

Sample configuration for Site B (London):

Performance Consideration

In order to achieve the best IPSEC VPN performance, use AES-GCM as the encryption algorithm for both IKE and IPSEC proposals.

For example:

set security ike proposal IKE-PROP encryption-algorithm aes-128-gcm

set security ipsec proposal IPSEC-PROP encryption-algorithm aes-128-gcm

With AES-GCM as the encryption algorithm, you don't need to specify the authentication algorithm in the same proposal. AES-GCM provides both encryption and authentication.

For more information on VPN configurations, see IPsec VPN User Guide for Security Devices and Example: Configuring a Route-Based VPN

Securing the Host Operating System

The IBM Cloud™ Juniper vSRX runs as a Virtual Machine on a bare-metal server installed with Ubuntu and KVM. To secure the host OS, you should ensure that no other critical services are hosted on the same OS.

SSH Access

The IBM Cloud™ Juniper vSRX can be deployed with public and private network access or private network access only. By default, password based SSH access to the public IP of the host OS will be disabled on new provisions and OS reloads. Access to the host can be achieved through the private IP address. Alternatively, key based authentication can be used to access the public IP. To do so, specify the public SSH key when placing a new Gateway order.

Some existing deployments of the IBM Cloud™ Juniper vSRX may allow password based SSH access to the public IP of the host OS. For these deployments, you can manually disable password based SSH access to the public IP of the OS by following these steps:

  1. Modify /etc/ssh/sshd_config

    • Ensure the following values are set.

    • Add the following filter rules to the end of the file.

  2. Restart the SSH service using the command /usr/sbin/service ssh restart.

    The procedure above ensures addresses in the private infrastructure network 10.0.0.0/8 subnet are allowed SSH access. This access is needed for actions such as: OS reloads, Cluster rebuilding, Version upgrades.

Firewalls

Implementing an Ubuntu firewall (UFW, Iptables, and so on) without required rules can cause the vSRX HA cluster to be disabled. The vSRX solution depends on heartbeat communication between the primary and secondary nodes. If the firewall rules do not allow communication between the nodes, then cluster communication will be lost.

The vSRX architecture influences the firewall rules discussed below. Details on the two architectures can be found in vSRX default configuration.

For vSRX version 18.4 HA deployments running with the legacy architecture, the following rules are required to allow cluster communication for UFW:

  1. To allow protocol 47 (used for heartbeat communication) in /etc/ufw/before.rules:

    -A ufw-before-input -p 47 -j ACCEPT

  2. To allow private network communication:

    ufw allow in from 10.0.0.0/8 to 10.0.0.0/8

  3. To enable UFW:

    ufw enable

For vSRX versions running with the newer architecture, the firewall rules must allow multicast communication.

Note:

In some cases, troubleshooting operations may require disabling the firewall for access to public repositories. In these cases, you should work with IBM Support to understand how to proceed.

Most Gateway actions require SSH access to the private 10.0.0.0/8 subnet for the host OS and the vSRX. Blocking this access with a firewall can cause the following actions to fail: OS reloads, Cluster rebuilding, and Version upgrades

As a result, if SSH access is disabled for the 10.0.0.0/8 subnet, you must re-enable it prior to executing any of these actions.

Configuring the Management Interfaces

The IBM Cloud™ Juniper vSRX nodes provide built-in management interfaces ("fxp0") that are not configured by default. When configured, these private interfaces can be used to communicate with the individual node, which might be useful in a high availability cluster for monitoring the status of the secondary node over SSH, ping, SNMP, and so on. Since the private IP for the vSRX floats to the primary node, it is not possible to directly access the secondary node.

Configuration of the fxp0 interface requires IPs in a subnet that is attached to the private transit VLAN for the gateway. Although the primary subnet that comes with the gateway has IPs that might be available, it is not recommended for this use. This is because the primary subnet is reserved for the gateway provisioning infrastructure, and IP collisions could occur if additional gateways are deployed in the same pod.

You can allocate a secondary subnet for the private transit VLAN, and use IPs from this subnet to configure fxp0 and the host bridge interface for PING and SSH access. To do so, perform the following procedure:

  1. Order a portable private subnet and assign it to the vSRX private transit VLAN. You can find the private transit VLAN on the gateway details page.
    Note:

    Ensure the subnet includes at least 8 addresses in order to support 2 IPs for the host bridge interfaces, and 2 IPs for the vSRX fxp0 interfaces.

  2. Configure the host br0:0 bridge interfaces using 2 IPs from the new subnet. For example:

    On Ubuntu host 0: ifconfig br0:0 10.177.75.140 netmask 255.255.255.248

    On Ubuntu host 1: ifconfig br0:0 10.177.75.141 netmask 255.255.255.248

  3. Persist the bridge interface configurations across reboots by modifying /etc/network/interfaces on each Ubuntu host. For example:
  4. Assign the 2 IP's to the vSRX fxp0 interface and create backup router configurations for access to the secondary node's fxp0 interface:
    Note:

    Additional information on configuring the backup router can be found in this Juniper article at: KB17161.

  5. Create a static route to the subnet. For example:

    set routing-options static route 10.177.75.136/29 next-hop 10.177.75.137

  6. Create firewall filters to allow PING and SSH to the fxp0 management interfaces:

    set firewall filter PROTECT-IN term PING from destination-address 10.177.75.136/29

    set firewall filter PROTECT-IN term SSH from destination-address 10.177.75.136/29