Juniper SRX – ‘The Routing Subsystem Is Not Running’

KB ID 0001045 

Problem

While trying to deploy Solarwinds to monitor a Juniper SRX failover cluster, we were having no joy connecting to the management interface of the secondary/standby firewall. The management (fxp0) interface on the primary (node0) firewall we could get to OK.

]

After jumping on the secondary firewall (via the console connection) we observed the following;

error: the routing subsystem is not running

Solution

As you can see (above) I couldn’t get the routing services started. And I soon found out, this is quite normal, the primary (active) firewall maintains the routing instance, the secondary firewall does not.

Well that fine but what about out Solarwinds box, what happens if the secondary firewall goes down? No one would know, and we also can’t take daily backups of its config.

To fix this problem you need to use the ‘backup-router’ command. This lets the appliance maintain some routes in the event that it is not hosting the live routing instance.

1. I’ll connect to to the primary firewall from this console session on the secondary firewall with the following command;

[box]request routing-engine login node0[/box]

2. Now I can add the backup-router routes, but assign them to the secondary (node1) firewall. Note: Where 192.168.100.1 is the next hop.

[box]

To get traffic back to the Solarwinds Management Server

set groups node1 system backup-router 192.168.100.1 destination 10.1.20.10/32

To get traffic back to the Cisco ACS Appliance

set groups node1 system backup-router 192.168.100.1 destination 10.1.20.10/32

[/box]

3. Don’t forget if the firewalls failover you will have the same problem (but the opposite way round), so I need the same to the primary node as well.

[box]

To get traffic back to the Solarwinds Management Server

set groups node0 system backup-router 192.168.100.1 destination 10.1.20.10/32

To get traffic back to the Cisco ACS Appliance

set groups node0 system backup-router 192.168.100.1 destination 10.1.20.10/32

[/box]

3. Save the config with a ‘commit’ command.

Related Articles, References, Credits, or External Links

NA

 

Configure Your Firewall for SNMP

KB ID 0001034 

Problem

Had a requirement to let SNMP traffic though a firewall this week, I have a client that has both SolarWinds and SCOM, and they need to monitor the external Citrix ADC load balancers. For SNMP we simply need UDP ports 161 and 162 (See below) but SolarWinds maintains ‘ping’ connectivity to the monitored assets, so ICMP also needs to be open.

Inbound Ports

Outbound Ports

Solution

As my ‘weapon of choice’ is a Cisco ASA, here’s how to set it up.

1. Connect to the firewall and proceed to global configuration mode.

[box] User Access Verification

Password:*******
Type help or ‘?’ for a list of available commands.
Petes-ASA> enable
Password: ********
Petes-ASA# configure terminal
Petes-ASA(config)#

[/box]

2. Assuming my inside interface is called ‘inside’ allow the traffic outbound then apply that ACL to the firewall with an access-group command.

Cisco ASA – ‘access-group’ Warning

[box] Petes-ASA(config)# access-list outbound permit udp host 192.168.1.100 host 172.16.1.10 eq 161
Petes-ASA(config)# access-list outbound permit icmp host 192.168.1.100 host 172.16.1.10
Petes-ASA(config)# access-group outbound in interface inside [/box]

3. Assuming my outside interface is called ‘outside’ allow the traffic inbound then apply that ACL to the firewall with an access-group command.

Cisco ASA – ‘access-group’ Warning

[box]Petes-ASA(config)# access-list inbound permit udp host 172.16.1.10 host 192.168.1.100 eq 161
Petes-ASA(config)# access-list inbound permit icmp host 172.16.1.10 host 192.168.1.100
Petes-ASA(config)# access-group inbound in interface outside [/box]

Note: Simply allowing ICMP will not permit ‘ping’ see the following article;

Cisco Firewalls and PING

4. Save the changes.

[box]Petes-ASA(config)# write memory
Building configuration…
Cryptochecksum: aab5e5a2 c707770d f7350728 d9ac34de
[OK]
Petes-ASA(config)#[/box]

Also

You may want to open UDP 514 (syslog) from the device to the monitoring server, (assuming you have configured syslog on the monitored device). If the monitored device cannot communicate make sure it’s not using DNS to resolve the monitoring server (if so you may need to open UDP 53 to a DNS server).

Related Articles, References, Credits, or External Links

NA