Performing vSRX Virtual Firewall Advanced Tasks in IBM Cloud
Working with Firewalls
The IBM Cloud™ Juniper vSRX Virtual Firewall uses the concept of security zones, where each vSRX Virtual Firewall 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 Virtual Firewall 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:
-
Create security zones and assign the respective interfaces:
Standalone scenario:
set security zones security-zone CUSTOMER-PRIVATE interfaces ge-0/0/0.1set security zones security-zone CUSTOMER-PUBLIC interfaces ge-0/0/1.1High Availability scenario:
set security zones security-zone CUSTOMER-PRIVATE interfaces reth2.1set security zones security-zone CUSTOMER-PUBLIC interfaces reth2.1 -
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 policyset security policies from-zone CUSTOMER-PRIVATE to-zone CUSTOMER-PUBLIC policy -
Use the following commands to allow traffic that is directed to the vSRX Virtual Firewall:
-
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
-
-
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 Virtual Firewall 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:
-
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 icmpset firewall filter ALLOW-PING term ICMP then accept -
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 Virtual Firewall 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 Virtual Firewall, see Network Address Translation User Guide on the Juniper website.
Working with Failover
You can initiate failover from your primary IBM Cloud™ Juniper vSRX Virtual Firewall to a backup device, so that all control and data plane traffic is routed through the secondary gateway device after failover.
This section is only applicable if your Juniper vSRX Virtual Firewall gateway devices are provisioned in High-Availability mode.
Perform the following procedure:
-
Login to your primary vSRX Virtual Firewall gateway device.
-
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.
-
On the primary vSRX Virtual Firewall gateway device, run the command:
show chassis cluster statusMonitor Failure codes: CS Cold Sync monitoring FL Fabric Connection monitoring GR GRES monitoring HW Hardware monitoring IF Interface monitoring IP IP monitoring LB Loopback monitoring MB Mbuf monitoring NH Nexthop monitoring NP NPC monitoring SP SPU monitoring SM Schedule monitoring CF Config Sync monitoring Cluster ID: 2 Node Priority Status Preempt Manual Monitor-failures Redundancy group: 0 , Failover count: 1 node0 100 primary no no None node1 1 secondary no no None Redundancy group: 1 , Failover count: 1 node0 100 primary yes no None node1 1 secondary yes no None {primary:node0}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 Virtual Firewall, 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.
-
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.
-
After failover is complete, verify the console output. It should now be listed as secondary.
-
Login to the other vSRX Virtual Firewall 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 Virtual Firewall 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 Virtual Firewall Default Configuration to learn more about redundancy groups, as well as the control and data planes.
Working with Routing
The IBM Cloud™ Juniper vSRX Virtual Firewall 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 65001command. -
Then configure the BGP neighbor and its session attributes:
set protocols bgp group CUSTOMER local-address 10.1.1.1set protocols bgp group CUSTOMER family inet unicastset protocols bgp group CUSTOMER family inet6 unicastset protocols bgp group CUSTOMER peer-as 65002set protocols bgp group CUSTOMER neighbor 2.2.2.2In this example, BGP is configured for the following:
-
To use source IP address of 10.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 10.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
Sample configuration for Site A (Dallas):
# show security address-book global address Network-A
10.84.237.200/29;
[edit]
# show security address-book global address Network-B
10.45.53.48/29;
# show security ike
proposal IKE-PROP {
authentication-method pre-shared-keys;
dh-group group5;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;
lifetime-seconds 3600;
}
policy IKE-POL {
mode main;
proposals IKE-PROP;
pre-shared-key ascii-text "$9$ewkMLNs2aikPdbkP5Q9CKM8"; ## SECRET-DATA
}
gateway IKE-GW {
ike-policy IKE-POL;
address 10.158.100.100;
external-interface ge-0/0/1.0;
}
#show security ipsec
proposal IPSEC-PROP {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;
lifetime-seconds 3600;
}
policy IPSEC-POL {
perfect-forward-secrecy {
keys group5;
}
proposals IPSEC-PROP;
}
vpn IPSEC-VPN {
bind-interface st0.1;
vpn-monitor;
ike {
gateway IKE-GW;
ipsec-policy IPSEC-POL;
}
establish-tunnels immediately;
}
#show interfaces
ge-0/0/0 {
description PRIVATE_VLANs;
flexible-vlan-tagging;
native-vlan-id 1121;
unit 0 {
vlan-id 1121;
family inet {
address 10.184.108.158/26;
}
}
unit 10 {
vlan-id 1811;
family inet {
address 10.184.237.201/29;
}
}
unit 20 {
vlan-id 1812;
family inet {
address 10.185.48.9/29;
}
}
}
st0 {
unit 1 {
family inet {
address 10.169.200.0/31;
}
}
#show security policies
from-zone CUSTOMER-PRIVATE to-zone VPN {
policy Custprivate-to-VPN {
match {
source-address any;
destination-address Network-B;
application any;
}
then {
permit;
}
}
}
from-zone VPN to-zone CUSTOMER-PRIVATE {
policy VPN-to-Custprivate {
match {
source-address Network-B;
destination-address any;
application any;
}
then {
permit;
}
}Sample configuration for Site B (London):
# show interfaces
ge-0/0/0 {
description PRIVATE_VLANs;
flexible-vlan-tagging;
native-vlan-id 822;
unit 0 {
vlan-id 822;
family inet {
address 10.45.165.140/26;
}
}
unit 10 {
vlan-id 821;
family inet {
address 10.45.53.49/29;
}
}
}
st0 {
unit 1 {
family inet {
address 10.169.200.1/31;
}
}
#show security ike
proposal IKE-PROP {
authentication-method pre-shared-keys;
dh-group group5;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;
lifetime-seconds 3600;
}
policy IKE-POL {
mode main;
proposals IKE-PROP;
pre-shared-key ascii-text "$9$H.fz9A0hSe36SevW-dk.P"; ## SECRET-DATA
}
gateway IKE-GW {
ike-policy IKE-POL;
address 10.169.100.100;
external-interface ge-0/0/1.0;
}
# show security ipsec
proposal IPSEC-PROP {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;
lifetime-seconds 3600;
}
policy IPSEC-POL {
perfect-forward-secrecy {
keys group5;
}
proposals IPSEC-PROP;
}
vpn IPSEC-VPN {
bind-interface st0.1;
vpn-monitor;
ike {
gateway IKE-GW;
ipsec-policy IPSEC-POL;
}
establish-tunnels immediately;
}
#show security zone security-zone CUSTOMER_PRIVATE
security-zone CUSTOMER-PRIVATE {
interfaces {
ge-0/0/0.10 {
host-inbound-traffic {
system-services {
all;
}
}
}
}
}
security-zone VPN {
interfaces {
st0.1;
}
}
#show security policies from-zone CUSTOMER-PRIVATE to-zone VPN
policy Custprivate-to-VPN {
match {
source-address any;
destination-address Network-A;
application any;
}
then {
permit;
}
}
#show security zones security-zone VPN
interfaces {
st0.1;
}
#show security policies from-zone VPN to-zone CUSTOMER-PRIVATE
policy VPN-to-Custprivate {
match {
source-address Network-A;
destination-address any;
application any;
}
then {
permit;
}
}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 Virtual Firewall 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 Virtual Firewall 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 Virtual Firewall 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:
-
Modify /etc/ssh/sshd_config
-
Ensure the following values are set.
ChallengeResponseAuthentication no PasswordAuthentication no
-
Add the following filter rules to the end of the file.
Match Address 10.0.0.0/8 Password Authentication yes
-
-
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 Virtual Firewall HA cluster to be disabled. The vSRX Virtual Firewall 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 Virtual Firewall architecture influences the firewall rules discussed below. Details on the two architectures can be found in vSRX default configuration.
For vSRX Virtual Firewall version 18.4 HA deployments running with the legacy architecture, the following rules are required to allow cluster communication for UFW:
-
To allow protocol 47 (used for heartbeat communication) in /etc/ufw/before.rules:
-A ufw-before-input -p 47 -j ACCEPT
-
To allow private network communication:
ufw allow in from 10.0.0.0/8 to 10.0.0.0/8
-
To enable UFW:
ufw enable
For vSRX Virtual Firewall versions running with the newer architecture, the firewall rules must allow multicast communication.
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 Virtual Firewall. 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 Virtual Firewall 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 Virtual Firewall 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: