Correcting readiness errors and warnings

Correcting connectivity errors

There are two categories of connectivity errors that you might encounter when you conduct readiness checks:

• Host (Ubuntu) SSH connectivity errors
• Gateway (vSRX) SSH connectivity errors

Many of these errors result from the fact that the gateway actions being checked require root SSH access to the private IP address for either the host (Ubuntu) OS, or the gateway (vSRX). If an SSH connectivity check fails, then the action cannot proceed.

For more information about establishing an SSH session, see Accessing the device using SSH. Note that for step 3, the example that is given is with the admin user. For a readiness check, substitute the root user for both the vSRX and the Hardware (host). Also, make sure that you use your private IP with this procedure, not your public IP.

To validate connectivity, open an SSH session to either the Ubuntu host's or vSRX's private IP using the root credentials that are listed in the Hardware section (for an Ubuntu host) or the vSRX section (for the gateway) of the Gateway Appliance Details page. Ensure that the SSH session can be established.

If the session cannot be established, check the following potential issues.

For host (Ubuntu) SSH connectivity errors:

• Is the Ubuntu firewall blocking SSH access to the private IP? The firewall rules must allow SSH access to the private 10.0.0.0/8 subnet. For more information, see IBM Cloud IP ranges for the service network.
• Is the root password listed on the Gateway Appliance Details page the correct password for the root user? If not, click the device link in the Hardware section and navigate to Passwords. Select Actions > Edit credentials and change the password to match the actual root password on the Ubuntu host.
• Is the root login disabled for the SSH server?
• Is the SSH server disabled or stopped?
• Is the root user account disabled on the Ubuntu host?

For gateway (vSRX) SSH connectivity errors:

• Is the vSRX firewall blocking SSH access to the private IP? The firewall rules must allow SSH access to the private 10.0.0.0/8 subnet. For more information, see IBM Cloud IP ranges for the service network.
• Is the root password listed on the Gateway Appliance Details page the correct password for the root user? If not, click the Edit icon next to the root password and change the password to match the actual root password for the vSRX.
• Is the root user account disabled for SSH access to the vSRX?

Correcting error 1119

The vSRX may have a configuration that is blocking local console access through telnet. Check for the following configuration and remove it before retrying the precheck operation:

set system ports console disable set system ports console insecure

Other issues may include an incorrect vSRX password.

Correcting error 1124

vSRX 18.4R1-S1 introduced an incompatibility that is documented in this Juniper problem report. You require a Juniper account to access this report.

If a redundant Ethernet (reth) interface includes vlan-tagging (which is the default), then the interface must also include the vlan-id tag. In 18.4R1-S1, it was possible to commit a configuration without the vlan-id tag. Newer versions, such as 19.4R2-S3, do not allow this configuration.

An example configuration without the vlan-id:

set interfaces reth2 vlan-tagging
set interfaces reth2 mtu 9000
set interfaces reth2 redundant-ether-options redundancy-group 1
set interfaces reth2 unit 2058 family inet address xx.xx.xxx.1/26
commit check

The output for this configuration is:

root@vSRX-Node0# commit check
[edit interfaces reth2]
 ‘unit 2058’
   VLAN-ID must be specified on tagged ethernet interfaces
error: configuration check-out failed

To address this error, add the vlan-id tag to the configuration and retry the readiness check:

set interfaces reth2 unit 2058 vlan-id 2058

Correcting error 1125

vSRX 18.4R1-S1 introduced an incompatibility that allowed the syslog configuration to contain both the structure-data and explicit-priority labels. In versions 19.4R2-S3 and later, this is no longer allowed.

For example, the following syslog configuration contains both labels (set system syslog file messages structured-data and set system syslog file default-log-messages explicit-priority).

set system syslog file messages any info
set system syslog file messages authorization warning
set system syslog file messages archive size 10m
set system syslog file messages archive files 10
set system syslog file messages archive world-readable
set system syslog file messages structured-data
set system syslog file interactive-commands interactive-commands info
set system syslog file interactive-commands archive size 1m
set system syslog file interactive-commands archive files 10
set system syslog file interactive-commands archive world-readable
set system syslog file interactive-commands structured-data
set system syslog file default-log-messages any warning
set system syslog file default-log-messages authorization info
set system syslog file default-log-messages user info
set system syslog file default-log-messages firewall any
set system syslog file default-log-messages interactive-commands info
set system syslog file default-log-messages explicit-priority
set system syslog file default-log-messages structured-data
set system syslog file kmd-logs daemon info
commit check

The output for this configuration is:

[Stage 3 - Build_vSRX][2021-01-11 15:38:00.623323] Commit check failed: CommitError(edit_path: [edit system syslog file default-log-messages], bad_element: explicit-priority, message: error: ‘explicit-priority’ cannot be configured if ‘structured-data’ is configured
error: configuration check-out failed: (statements constraint check failed))

To fix this issue, remove one of the syslog labels from the configuration and retry the readiness check.

Correcting unsupported vSRX configuration commands

The Juniper vSRX contains undocumented, or hidden, CLI commands. The vSRX configuration does not support some of these commands, even though, in some releases, they can be committed. Sometimes the behavior can unexpectedly change between release versions. The following information details some known unsupported configuration commands when you upgrade from an older vSRX version. It is critical that you remove unsupported, or hidden, commands from the vSRX configuration before upgrading your version. Do this even with commands that are not detected by the Readiness check.

Correcting error 1145

To remove the IDP-related policies and configurations. Run the following commands to gather all dependencies.

show security policies | match idp | display set
show system scripts | display set
show security idp | display set

Then, delete the configuration stanza for each of these dependencies.

Example:

delete security policies from-zone <$zone1> to-zone <$zone2> policy
<$policy> then permit application-services idp
delete system scripts commit file templates.xsl
delete security idp

Correcting error 1147

Similar to the previous section, a change in the way Junos parses configuration in the security section can lead to errors like:

error: Bad url pattern: *.googleapis.com/(*)

Examples of this configuration include:

set security utm custom-objects url-pattern AZURE value *.googleapis.com/*
set security utm custom-objects url-pattern website value *services.site.com

The use of * as the trailing character and the prefix is no longer valid. An alternative configuration is:

set security utm custom-objects url-pattern AZURE value *.googleapis.com
set security utm custom-objects url-pattern website value *.services.site.com

To fix this issue, modify the vSRX configuration as needed, commit, and retry the readiness check.

[edit]
root@asloma-vsrx-sa-sng0102-vsrx-vSRX# set interfaces st0 unit 0 family inet tcp-mss 1372

[edit]
root@asloma-vsrx-sa-sng0102-vsrx-vSRX# commit
commit complete

[edit]

.......
...

root@asloma-vsrx-sa-sng0102-vsrx-vSRX> show configuration interfaces st0
unit 0 {
    family inet {
        ##
        ## Warning: statement ignored: unsupported platform (vsrx)
        ##
        tcp-mss 1372;
    }
}

{primary:node0}[edit]
root@asloma-tc1-10g-csb-ha1-vsrx-vSRX# set interfaces st0 unit 0 family inet tcp-mss
                                                                             ^
syntax error.

set security datapath-debug capture-file pcap001
set security datapath-debug capture-file format pcap
set security datapath-debug capture-file size 10m
set security datapath-debug capture-file files 5
set security datapath-debug maximum-capture-size 1500

Correcting warning 1176

A VPN configuration with establish-tunnels not set to immediately was detected. After an upgrade, the IKE might not be immediately active depending on negotiations with the remote peer gateway, and whether data traffic is actively flowing. Without establish-tunnels immediately, the tunnel is established with on-traffic. With the establish-tunnels immediately statement, the tunnel is established immediately when the configuration is committed. However, establish-tunnels immediately might trigger an undesirable outcome when configured on both ends of the tunnel.

For more information, see (SRX) IPsec comes UP when SRX-A is the Initiator, but fails when SRX-A becomes the responder in the Juniper Knowledge Base. Consult vpn (Security) for more details on these settings.

Correcting warning 1177

One or more security zone policy rules with the dynamic-application any configuration was detected. If the vSRX is not installed with the Content Security Bundle (CSB) license and application signature database, then this configuration might cause traffic disruption due to changes in newer vSRX releases, such as 19.4R2-S3.

For example, the following security policy configuration contains the dynamic-application any label:

set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL match dynamic-application any
set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL match source-address SL8
set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL match destination-address SL8
set security policies from-zone untrust to-zone untrust policy DYNAMIC-APPLICATION-POLICY-LOCAL then permit

If you are using a similar configuration, it is recommended that you either install the CSB license and the application signature database or remove the dynamic-application any rule.

Correcting warning 1179

The vSRX version running on the Gateway is not certified on IBM Cloud and is unsupported. Operations such as OS Reload and Rebuild Cluster will overwrite the current unsupported vSRX version with the version that is currently listed on the Gateway Details page. Because the vSRX version is not certified on IBM Cloud, it is recommended you contact IBM Support to migrate to the certified version found here: IBM Cloud Juniper vSRX supported versions.

Correcting warning 1180

The vSRX license that is found on the Gateway was not procured through IBM Cloud and is unsupported. Operations such as OS Reload and Rebuild Cluster will overwrite the current license with the version that is currently listed on the Gateway Details page. Supported vSRX licenses can be found here: Viewing and changing vSRX licenses. If the license was procured outside of IBM Cloud, work with that procurement source for support. Otherwise, it is strongly recommended that you contact IBM Support to migrate to a supported vSRX license.

Correcting warning 1181

The vSRX license and version on the Gateway are both unsupported. Refer to Correcting warning 1179 and Correcting warning 1180 for help with resolving these warnings.