Generic selectors
Exact matches only
Search in title
Search in content
post
page
How can we help?
Print

Firewalls, Routers, Switches

The following table is a comprehensive list of supported devices. The instructions provided in the table can be used to manually extract data from the device for import. While we do our best to support the below devices, it is impossible for us to test the parsers with every possible device configuration combination. If errors occur during device import, Network Perception is committed to working with our customers to resolve their specific parsing issues.

Note that Network Perceptions device support policy follows that of the manufacturer.  When a manufacturer ends support for a product, so does Network Perception.  End of support devices are not removed from NP-View but will not be upgraded if issues arise.

Supported Devices with Vendor Partnership

The devices in this list are actively tested in our lab to support the most current versions of the manufacturer software. Network Perception has an active partnership with these vendors for software and support.

Manufacturer Type/Model/OS Configuration files needed
Check Point R81/ R81.10 (Gaia)/ R81.20 (Titan) including Multi-Domain Security

We support the database loading using the NP Check Point R80 Exporter (PDF documentation, video).

Zip File Shasum:
5d22b182d773c020fd2a58838498b8be8221468e
Exporter Tool Shasum:
cc3131da37362da1291fa4a77cd8496fcb010596

Cisco

ASA Firewall (9.8 and up) with multi-context.

FTD Firewall (6.7, 7.1.x)

Catalyst Switch (IOS 15.7)

ISR (IOS-XE 17.3.x, 17.6.x)

We do not support Application Centric Infrastructure (ACI) or NX-OS

For a Cisco IOS device, the sequence would be:

  • enable (to log into enable mode)
  • terminal length 0 (it eliminates the message between screens)
  • show running-config

For a Cisco ASA, the sequence would be:

  • enable
  • terminal pager 0
  • show running-config

For FTD, see additional instructions below

Fortinet

FortiGate Firewall, FortiSwitch

(FortiOS 6.4, 7.0.x, 7.2.x)

To get a config capture from the CLI using Putty (or some similar SSH) client, here is the process:

  • Turn on logging of the CLI session to a file
  • In the CLI of the FortiGate, issue these commands in sequence:
  • config system console
  • set output standard
  • end
  • show full-configuration
  • Turn off logging
Palo Alto

Next Gen Firewall (PanOS 10.x, 11.x) including multiple virtual firewalls (vsys) and virtual routers (vrf).

We do not support SD-WAN

See additional instructions below

 

Supported Devices with no Vendor Partnership

The devices in this list are actively tested in our lab to support the most current versions of the manufacturer software. 

Manufacturer Type/Model/OS Configuration files needed
Dell – SonicWall SonicOS (5.9.x, 6.5.x) “From GUI, Go to Export Settings, then Export (default file name: sonicwall.exp)”
see additional instructions below
FS Switch (FSOS S5800 Series; Version 7.4)

show running-config

Note that FS configs are Cisco like and not tagged specifically as FS so these switches will display as Cisco devices in NP-View

Juniper Junos Firewall SRX-V (20.x)

NetScreen Firewall (ISG, SSG)

For JunOS, the command should be:

  • show configuration | no-more

For Juniper ScreenOS, the sequence is:

  • set console (N would be the number of expected lines like 1000)
  • get config all
Schweitzer Ethernet Security Gateway (SEL-3620)

SEL Firmware: from “Diagnostics”, click on “Update Diagnostics” and copy the text

OPNsense: from ‘System > Configuration > Backup’ export .XML backup file

Note: IPTables from OPNsense are not supported in NP-View.

Siemens – RUGGEDCCOM ROX Firewall RX1000-RX5000 (2.x) admin > save-fullconfiguration. Choose format “cli” and indicate file name

 

Historical Devices

The devices in this list were developed based on customer provided configuration files.  We are no longer actively developing these parsers but they are supported for break/fix and require customers sanitized config files to assist with the debug of issues.

Manufacturer Type/Model/OS Configuration files needed
Dell PowerConnect Switch console#copy running-config startup-config (instructions)
Nokia Service Router (SR7755; TiMOS-C-12.0.Rx)

admin# save

ftp://test:test@192.168.x.xx/./1.cfg

↳Alcatel-Lucent Service Aggregation Router (SAR7705; TiMOS-B-8.0.R10)

admin# save

ftp://test:test@192.168.x.xx/./1.cfg

Berkeley Software Distribution (BSD) Firewall (Open, Free and Net; 3 series) ifconfig -a > hostname_interfaces.txt
See additional instructions below
Extreme Switch (x400, x600; XOC 22.6) save configuration
Hirschmann Eagle One Firewall (One-05.3.02) copy config running-config nv [profile_name]
HP / Aruba ProCurve Switch (2600, 2800, 4100, 6108) show running-config
  NetScreen Firewall (ISG, SSG) get config all
Linux BSD IP Tables Firewall iptables-save
See additional instructions below
NETGEAR Smart managed Pro Switch (FS/GS-Series; 6.x) CLI: show running-config all
Web UI: Maintenance > Download Configuration
pfSense Firewall (2.4, BSD 11.1) Diagnostics > Backup & Restore > Download configuration as XML
Siemens ROS Switch (RSG2-300; 4.2) config.csv
↳Scalance X300-400 Switch cfgsave
Sophos Firewall (v16) Admin console: System > Backup & Firmware > Import Export
VMware NSX Firewall GET https://{nsxmgr-ip}/api/4.0/edges/ (XML format)
Learn more about vCenter and VSX
WatchGuard Firewall (XTM 3300, XTM 850) Select Manage System > Import/Export Configuration

 

Additional Instructions

Collecting configuration information from the device console can be an easy way to get the device data.

Following the below rules will help ensure success when importing the files into NP-View.

Note that not all data can be retrieved from the console. Please review the section for you specific device for additional instructions.

  1. Run the command from the console.
  2. Copy the text to a plain text editor. Do not use Word or any fancy text editor as it will inject special characters that we cannot read.
  3. Review the file and look for non text characters like percent encoded text or wingdings like characters. These will break the parser.
  4. Save the output of each command in a separate file and name it after the device so that NP-View can properly attribute the files. For example: firewall1_config.txt, firewall1_arp.txt, firewall1_route.txt
  5. For Palo Alto files, there are specific naming requirements, please see the Palo Alto section for additional information.
  6. Some config files contain very long strings. Line wrapping due to the window size of the terminal will break the parser. If using a terminal like Putty, please ensure the terminal is set to maximum width.

config system console

set output standard

end

Finally, if you encounter a parsing error when loading the files and want to upload the files to Network Perception using the portal, please sanitize all files at the same time so that we can keep the data synchroized across the files.

Berkeley Software Distribution (BSD)

BSD has three firewalls built into the base system: PF, IPFW, and IPFILTER, also known as IPF FreeBSD
  • Packet Filtering (PF): Rules located in file /etc/pf.conf
  • IP Firewall (IPFW):  Default rules are found in /etc/rc.firewall. Custom firewall rules in any file provided through # sysrc firewall_script=”/etc/ipfw.rules”
  • IP Filter also known as IPF: cross-platform, open source firewall which has been ported to several operating systems, including FreeBSD, NetBSD, OpenBSD, and Solaris™. Name of the ruleset file given via command ipf -Fa -f /etc/ipf.rules
OpenBSD NetBSD BSD and similar systems (e.g., Linux) will use the same names for interfaces (eth1, eth2, em1, em2, carp1, carp2, etc.). The parser might be confused if the user imports interface files and packet filter configs from different systems at the same time resulting in a combined system instead of individual devices.  To prevent this, the user should group all files by host, making sure to name the ifconfig file after the hostname (i.e. host1_interfaces.txt). 

Free BSD Example

Below is an example of a 2 host FREE BSD system containing FW1, host1 and host2.  The user should import the files in each section as a separate import. 

fw1 – first data set import (all available files imported together)

  • pf.conf (required file) (note, can be named differently, e.g., FW1.txt’)
  • obsd_fw1_interfaces.txt (required file) (note that the parser keys on the “_interfaces” string”.  Text before “_interfaces” will be used to name the device. In tis example ‘obsd_fw1’)
  • hostname.carp1
  • hostname.carp2
  • hostname.hvm2
  • hostname.hvm3
  • hostname.hvm4
  • table1
  • table2

host1 – second data set import (all available files imported together)

  • pf.conf (required file) (note, can be named differently, e.g., host1.txt’)
  • host1_interfaces.txt (required file) (note that the parser keys on the “_interfaces” string”.  Text before “_interfaces” will be used to name the device. In this example ‘host1’)
  • hostname.em1
  • hostname.carp1

host2 – third data set import (all available files imported together)

  • pf.conf (required file) (note, can be named differently, e.g., Host2.txt’)
  • host2_interfaces.txt (required file) (note that the parser keys on the “_interfaces” string”.  Text before “_interfaces” will be used to name the device. In this example ‘host2’)
  • table1
  • table2
The only required files are the config file (can be named something other than pf.conf) and the ifconfig file. hostname files are optional (unless they contain description of interfaces not in the ifconfig file). Table files contain a list of IP addresses that can be manipulated without reloading the entire rule set. Table files are only needed if tables are used inside the config file. For example, table persist { 198.51.100.0/27, !198.51.100.5 }

Support for Fortinet through 6.2 ended September 2023. Please note that no upgrades to these parsers will be made.

Panorama

If Panorama is used to centrally manage policies, the access rules and object groups can be retrieved from these devices in XML format (we do not support the import of unstructured text files). If using the Panorama connector, the required files will automatically be downloaded:

The Panorama file will only contain centrally managed access rules and object groups.

Locally defined access rules and object groups cannot be retrieved from Panorama and must be retrieved from each NGFW. Please follow the instructions below to export directly from the Next Gen FireWall using API. 

Palo Alto Firewalls will ALWAYS have a V-sys even if one has not been configured it will default to vsys1.

The “mapping_config” file is required which can only be retrieved through the API using the “show devices connected” command.  The name of the file is “named_mapping_config.xml” where the named prefix needs to match the device name as shown in the UI when the running_config.xml is imported alone. All files should be imported at the same time. Please see instructions below:

The below links are to the Panorama documentation for the required commands with examples. The links provide you with commands to run directly in the Panorama CLI. The images we provided are for using Postman or web browser use.

Get API Key

Get Panorama and device bundle Configuration

Get device mapping config

Once both the “<panorama_server>_running_config.xml” and <panorama_server>_mapping_config.xml” are gathered, please import them together in NP-View. 

 

Next Gen Firewall (NGFW)

If using the PanOS connector is used to download files, the required files will automatically be downloaded:

The configuration information from the NGFW may be contained in several .xml files, <device-name>_merged_config.xml and <device-name>.vsys(n)_pushed_policy.xml.  There can be one vsys file per virtual interface. The naming of these files is important for the parser to merge them during import.  All files from a single firewall must be imported at the same time and in .xml format (we do not support the import of unstructured text files).  If any of the files are missing, improperly named or formatted, an error message will state that ‘File parsed but ruleset and topology were empty, aborting’ meaning they could not be linked to the other associated files.

An example of properly named files is below:

    • Chicago-IL-100-FW1_merged_config.xml
    • Chicago-IL-100-FW1.vsys1_pushed_policy.xml
    • Chicago-IL-100-FW1.vsys2_pushed_policy.xml

NOTE: If the NGFW is an unmanaged/standalone Palo Alto device it will not have a pushed_policy file. In this situation, the configuration .xml file can be downloaded directly from the firewall and loaded into NP-View.  The file name need not be changed when loading the file from a standalone firewall.

To manually export configuration files from an unmanaged firewall:

If the NGFW is managed by a Panorama, the API will be required to secure the necessary files:

Get API Key

Get PANos Firewall full configuration


Get Managed Firewall configuration

Virtual Routers (vrf) – Experimental Support

Virtual router (vrf) is a software-based routing framework in Palo Alto NGFW that allows the host machine to perform as a typical hardware router over a local area network. NP-View has added the experimental capability to detect Virtual Routers from Palo Alto devices (NGFW or Panorama) and present them in the Connector or Manual Import device selection screens. Virtual Routers will be treated the same as physical routers and will require a device license.

This feature is disabled by default and must be enabled prior to importing configurations containing virtual routers.

To enable the feature the NP-View Server admin will need to make a change to a system variable.

  • Stop the NP-View Server application.
  • in the docker-compose.yml file, change the enableVirtualRouters=False to enableVirtualRouters=True in three places within the file.
  • start the NP-View Server application.

For Desktop

  • Close the NP-View application.
  • In the file C:\Users\<username>\AppData\Roaming\NP-View\config.ini add enableVirtualRouters=True
  • Restart the NP-View application

Once enabled, the user will be presented with the option to select virtual routers from the connector in the device selection or upon manual import.

Support for Palo Alto PanOS prior to V9.1 are no longer supported.  Please note that no upgrades to parsers will be made for unsupported devices.

Support for Check Point R77.30 ended in May of 2019. Please note that no upgrades to this parser will be supported if it fails to operate as expected. Below are the instruction for manually exporting R77 files.

Check Point R7x version store configuration information in flat files on the management server’s filesystem. The file location is different when using a multi-domain environment.

When using Checkpoint R77 management server, the required files can be found here:

  • /etc/fw/conf/objects_5_0.C
  • /etc/fw/conf/rulebases_5_0.fws
  • /etc/fw/conf/identity_roles.C (optional)

Load all of the retrieved files at the same time into NP-View.

When using a Multi Domain environment, the required pairs of objects and rule base files are typically stored in: $MDSDIR/customers/

If you have trouble locating the files, you can use the command: find / -name “rulebases_5_0.fws” -ls to locate the files.

All configs in these 3 locations are required (not just one)

  • One Global Database, located in directory: /var/opt/CPmds-R77/conf
  • One Multi-domain Server (MDS) database, located in directory: /var/opt/CPmds-R77/conf/mdsdb
  • The contents of the Domain Management Server databases (DMS), located in directory: /var/opt/CPmds-R77//CPsuite-R77/fw1/conf/ which include:
    • object
    • rulebase
    • /object…

Load all of the retrieved files at the same time into NP-View.

Support for Check Point R80 through R80.40 ended April of 2024. Please note that no upgrades to these parsers will be made.

NP-View supports Cisco FTD through the output of “show running-config”command. However, it is important to note that Cisco FTD includes network filtering policies documented outside of the running configuration. This section explains where to find those policies.

As of version 6.1, Cisco FTD includes a Prefilter Policy feature that serves three main purposes:

  • Match traffic based on both inner and outer headers
  • Provide early Access Control which allows a flow to bypass Snort engine completely
  • Work as a placeholder for Access Control Entries (ACEs) that are migrated from Adaptive Security Appliance (ASA) migration tool.

The feature has 2 primary use cases:

  • For use with Tunnel Rule Types
  • For bypassing the Snort engine

These prefilter rules are part of the FTD configuration and are displayed via the “show running-config” command on the FTD. They manifest in the NP-View Access Rule table as a Permit IP with:

  • Source = any
  • Destination = any
  • Service = IP/any to any

As a result, the NP-View Rule Policy engine flags these rules as a high risk alert.

In the operation of the FTD, if a packet meets the prefilter policy, it is then evaluated by a secondary set of rules in the Snort engine or applied directly to the tunnel. The Snort rules are not part of the output of the of the “show running-config” output from the FTD. These rules are established, maintained and viewed on the FMC (management server), but are not readily available via the FTD CLI interface.

In the context of an audit during which evidence around these prefilter rules is requested, we recommend documenting that these rules are a default configuration for the system and we also recommend generating a FMC PDF Policy report to explain the flows of traffic within the FTD configuration. For more information, please refer to the Cisco FTD Prefilter Policies documentation.

We support .exp files as the default SonicWall file format for v5.9 and v6.X of the SonicOS.

The main UI allows for export of the encoded .exp file as such:

To extract the file via command line, then the command to export is

export current-config sonicos ftp ftp://[USERNAME]:[PASSWORD]@[FTP IP/URL]/sonicwall.exp

Where the username/password/FTP IP or URL must be changed. The file “sonicwall.exp” will then be saved at the FTP location. As this file is encoded, there’s no way to echo or cat the data.

Requesting Support for New Devices

The above list of supported hardware has been lab and field tested.  Newer versions generally work unless their is a major platform or API upgrade.  Please contact support@network-perception.com if you wish to get more information on parsers, request support for a particular device or are interested on co-developing a solution.

Table of Contents