fbpx

Network-Engineering | 18 min read

Juniper Netscreen to SRX Migration

ngworx Team
July 2021
written by Nigel Wensley
Senior Network & Security Engineer

Introduction

There are many Juniper NetScreen ISG and SSG firewalls still in productive use and Juniper support officially ends on the last day of 2022.

For some, the End of Support milestone is not a problem because there is already a plan to decommission the Netscreens in time. For others, operating the Netscreen without support is an acceptable risk perhaps because the configuration is very simple, changes are not required, or the functions unimportant. In some cases, NetScreen firewalls are part of entirely forgotten and unmaintained environments!

If you need to plan to replace a Juniper Netscreen firewall, in this article, I will give an overview on how to translate ScreenOS configuration to Junos and plan a maintenance to replace the Juniper NetScreen with Juniper SRX firewall. However, the following information should also be generally useful to replace a Juniper NetScreen firewall with any other vendors firewall such as FortiGate or Palo Alto.

Any Juniper ISG or SSG firewall can be replaced with a Juniper SRX firewall, either the physical or virtual version. The configuration translation from ScreenOS to Junos is not difficult, only a little time consuming! There is equal time required to plan and conduct a maintenance to swap out the old firewall.

Years ago, there was a Juniper configuration migration tool at https://migrationtools.juniper.net/s2j/index.jsp, but it is gone now. I never used this tool, so I do not know how well it worked. If your replacement firewall is a FortiGate there is a migration tool called FortiConverter. There is also a PaloAlto migration tool called Expedition which may translate at least part of the ScreenOS configuration. While the tool is free, the PaloAlto website notes it is community developed and not supported.

You can engage Juniper Professional Services to do the task for you. ngworx.ag is an elite Juniper Partner and we have migrated Juniper Netscreen firewalls to Juniper SRX and FortiGate already several times. If you want advice, please get in touch or read on to tackle the task yourself using the these guidelines and time saving tips.

Netscreen replacement options

What are the options to replace NetScreen firewalls?

  • Replace the NetScreen firewall with another from any vendor, physical or virtual.
  • Migrate the security functions to other existing firewalls.
  • Re-design and implement the security functions differently instead of replacing the firewall.

There are surely even many more options, but this article focuses on replacing a Juniper Netscreen firewall with a Juniper SRX firewall.

You should be able to replace a NetScreen with an SRX firewall with complete feature parity. All functions configured in ScreenOS on the old Netscreen firewall should be able to be recreated “like for like” in Junos on an SRX firewall.

With that said, since ScreenOS stopped development in 2014, some things have changed such as how to license a device or implement UTM. Any differences should mainly reflect security improvements and not block your plan to replace a Netscreen firewall.

Planning a new configuration

Translating ScreenOS configuration to Junos requires only common tools that you already have. You may use any combination of a text editor like Notepad++ or Sublime, a spreadsheet like Microsoft Excel, a UNIX command line, and your development environment for scripting some tasks.

If your replacement firewall is a Juniper SRX, it is essential to have access to a lab device running Junos to check configuration syntax as you create it. You can access a virtual Junos device at Juniper vLabs https://jlabs.juniper.net/vlabs.

First, you must obtain a copy of the ScreenOS configuration. You may get this from the Netscreen device web-GUI, or SSH to the Netscreen device and issuing the “get config” command, or the configuration may be archived by regular a configuration backup script or network management platform.

Next, review the ScreenOS configuration to see what is configured and how complex it is. Note the number of interfaces, security zones, address book entries, policies, and custom defined services. If the Netscreen device setup is quite minimal you might not even need to translate the old ScreenOS configuration but instead proceed directly to configuring a replacement firewall, perhaps using the web-GUI.

The next step is deciding whether the ScreenOS configuration must be replicated partially or completely, and whether any “clean up” of the ScreenOS configuration is required before translation. This requires health checking the Netscreen firewall (see later section). For example, you might avoid duplicating policies that are inactive, unreferenced objects, perhaps the Netscreen interface status shows the source or destination interface matching a configured policy has been down for a long time. From this, you conclude the policy cannot have been used and therefore policies using the down interface are no longer required and do not need translating.

Finally, decide whether the ScreenOS configuration should be replicated identically, or simplified, or optimized. For example, consider whether it is required to replicate policies exactly between 2 zones that specify many source & destination IP address pairs and TCP/IP ports, or whether these policies can be replaced with one simpler policy which allows all traffic between the 2 zones and their source and destination IP subnets. You may also wish to implement routing slightly differently on a replacement device, for example using VRFs.

Configuration sections

I personally find it easiest to translate ScreenOS to the Junos single-line “set” syntax rather than the default JSON configuration style. ScreenOS syntax is mostly also single-line syntax except notably the ScreenOS policy configuration is a little problematic.

For example, note how the first line identifies the policy by ID #3 but the last two lines do not!

set policy id 3 name Policy-3 from LAN-1 to LAN-2 10.0.0.1/32 Any HTTP 
set policy id 3
set service HTTPS
set log session-init

In other cases, ScreenOS commands only need a few words changed to become Junos syntax.

Both ScreenOS and Junos configuration is clearly divided into sections whose names identify the sections purpose. Many sections have the same name in both ScreenOS and Junos

ScreenOS

set interface
set zone
set service
set address 
set policy

Junos

set interfaces
set security zones
set applications 
set security zones security-zone WAN address-book address 
set security policies

As you translate configuration sections, use a Junos device to check the syntax is correct. Use the Junos “commit check” function and save as you go!

Pre-requisites

Install the desired Junos software version on your new Juniper SRX firewall, or another new device you use.

Install and activate any licenses.

If the firewall will operate in a cluster for device redundancy, you should configure and get this working next. The new configuration created is applied to one device elected as the cluster master or primary, which synchronizes the configuration to the redundant partner device.

Map out the interfaces of the old and new device. List the old ScreenOS device interface names in one column, then the VLAN, IP network, IP address, security zone, and any ScreenOS services activated on the interface such as DHCP relay or DNS proxy. This will be a helpful reference as you work through translating configuration sections. Here is an example table:

Security Zone Netscreen Port SRX Port VLAN Network IP address DHCP-Relay DNS-Proxy
LAN eth0/0 ge-0/0/0 10 10.0.10.0/24 10.0.10.1 10.0.10.254 Y
WAN eth0/1 ge-0/0/1 11 10.0.11.0/24 10.0.11.1 N Y

If there are local accounts that must be replicated to a new device, you must know the password for each account or set a new password.

If RADIUS or TACACS is used to authenticate device users, you must know the RADIUS OR TACACS server secret to make this work on a new device.

Check if there are public keys that must be copied onto the new device for authentication.

Check if there are SSL certificates that must be copied onto the new device for management.

If there are VPNs that must be replicated to a new device, you must know the IKE pre-shared-key or set a new one during the maintenance to replace the firewall.

Netscreen health check

As explained earlier, there is no point exactly translating ScreenOS configuration for something that is not working, such as an interface that is “link down” or an NTP server that no longer exists.

Saving and reviewing health check output is also an essential step before attempting a maintenance to replace the Netscreen firewall. You can save yourself time troubleshooting something that is not working on a new firewall after the Netscreen is replaced, by reviewing the old Netscreen firewall health check information. Maybe you will find what is not working on the new firewall was not working on the old firewall either!

Example ScreenOS CLI commands are given to capture the operating state of the Netscreen firewall. You may be able to obtain the information from the web-GUI also.

These are examples and you may other information. For example, you may not have any VPN’s configured.

The “get tech” command is the most useful, it includes the configuration and a large amount of useful output about the Netscreen operating and network state.

get tech
get alarm
get event

get interface
get arp
get route
get mac

get nsrp
get failover

get log
get syslog
get flow

get ntp
get snmp

get ike 
get sa
get vpn

The other main sources of information about the firewall operating state are device logs and network monitoring platforms you may have.

If the old Netscreen firewall was configured to log to a remote SYSLOG server you can review logs to see what policies were active with traffic. Keep in mind however there will only be logs of this kind if the security policy is configured with the logging option! Check your policies to see.

You may be able to analyze the logs and create reports showing which policies were active using a network monitoring platform like Juniper Network & Security Manager or the free & open source Kibana.

You can also see what traffic is transiting the Netscreen firewall and which policy is used in flow logs. Use the “get flow” CLI command.

Screenos to Junos configuration translation

I recommend translating configuration in the following topic order:

  • cluster (nsrp, redundancy group)
  • system (hostname, clock)
  • interfaces (IP addressing, VLAN)
  • security zones (zones, interfaces, screens)
  • routing (static routes, routing protocols)
  • management (SSH, NTP, SNMP, SYSLOG)
  • services (DNS proxy, DHCP relay)
  • applications (custom TCP/IP port groups)
  • address book
  • policies
  • NAT
  • VPNs

Cluster

As explained in the earlier pre-requisites section, if the firewalls will operate in a cluster you should configure and get this working first. The ScreenOS cluster configuration section is “nsrp” and in Junos it’s the “chassis cluster” section.

The old ScreenOS “nsrp” configuration may include interface monitoring to make the cluster primary device fail over if a monitored interface state changes to link down.

ScreenOS

set nsrp vsd-group id 0 priority 255
set nsrp monitor interface ethernet0/0

Junos

set chassis cluster redundancy-group 0 node 1 priority 255
set chassis cluster redundancy-group 0 interface-monitor ge-0/0/0 weight 255

Juniper Cluster Guide
https://www.juniper.net/documentation/en_US/junos/topics/task/operational/chassis-cluster-srx-series-creating.html

System

Configure next the most basic settings on your new device; the hostname and time-zone.

ScreenOS

set clock
set hostname

Junos

set system host-name
set system time-zone

Interfaces & IP addressing

As explained earlier, you should have already mapped out the interfaces of the old and new devices.

Search your old ScreenOS configuration for all “set interface” commands to find the information needed for your new interfaces.

ScreenOS

set interface ethernet0/0.10 tag 10
set interface ethernet0/0.10 ip 10.0.10.1/24

Junos

set interfaces ge-0/0/0 vlan-tagging 
set interfaces ge-0/0/0.10 vlan-id 10
set interfaces ge-0/0/0.0 family inet address 10.0.10.1/24

You will find in ScreenOS the “set interface” section is also where the security zone is specified and system services like PING or SSH are allowed on an interface. These will be dealt with in the next section.

For now, the most important thing is carefully mapping the major information from old to new interfaces which is port number, VLAN, IP address, and security zone.

If using a Juniper SRX cluster, your new interfaces will be Redundant Ethernet (RETH) interfaces like “reth0.0”.

Security zones & interfaces

Now associate interfaces with security zones.

ScreenOS

set zone LAN
set interface ethernet0/0 zone LAN

Junos

set security zones security-zone LAN interfaces ge-0/0/0

Allow required services and protocols on the interfaces in the zones.

ScreenOS

set interface ethernet0/1 manage ping
set interface ethernet0/1 manage ssh

Junos

set security zones security-zone Local-LAN host-inbound-traffic system-services ping
set security zones security-zone Local-LAN host-inbound-traffic system-services ssh
set security zones security-zone Local-LAN host-inbound-traffic system-services ike
set security zones security-zone Local-LAN host-inbound-traffic protocols bgp

If you have custom screens, you need to migrate you can do that now but the default Junos screen settings should be fine regardless of how the old Netscreen was configured.

ScreenOS

set zone Internet tcp-rst

Junos

set security zones security-zone Internet tcp-rst

IPsec VPN

ScreenOS and Junos IPsec VPN configuration are similar but handling this topic is not simply a matter of configuration translation.

The first and most important task is deciding if:

  1. You want to recreate the VPN on a new firewall exactly and avoid re-configuring the remote peer, which may be a external party.
  2. Update and improve the VPN configuration.

Since ScreenOS is years old, it may be more sensible to update the VPN configuration using newer and more secure methods available in Junos. For example there are more secure encryption and authentication algorithms available since ScreenOS development stopped. The VPN configuration might be further imrpoved by using automatic IKE exchange instead of creating a manual key both peers must know to create the configuration.

The second task is understanding the type of VPN the existing configuration represents and deciding if you wish to recreate that exactly.

  • Does the VPN connect 2 sites or a dynamic subscriber to a LAN?
  • Is the VPN route or policy based?
  • Does the VPN operate in transport or tunnel mode?

It may not be desirable to recreate the old VPN configuration exactly, for example using now superceeded authentication or encryption algorithms. The answer may depend on whether the remote peer is under your control or an external party with whom you must negotiate the new configuration.

Once the new VPN configuration is decided, you can follow Junos documentation or perhaps simply use a web-GUI setup wizard to create the new VPN.

Some key elements of the existing VPN configuration to identify are:

  • the gateway (egress) interface towards the remote peer.
  • if custom or predefined IKE proposals are used in Phase 1 or 2.
  • if main or aggressive mode is used in IKE Phase 1.
  • if autokey IKE is used, whereby keys are automatically generated in Phase 1 & 2, or manual keys, or certificates.
  • if proxy IDs are configured for Phase 2 when using route based VPNs.

See Junos IPsec VPN Configuration

https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/topic-map/security-ipsec-vpn-configuration-overview.html

Routing

By default, ScreenOS has 2 routing tables:

  • trust-vr
  • untrust-vr

Only trust-vr is used by default. Check the configuration to see if untrust-vr or other virtual routers have been created.

By default, Junos has 2 routing tables:

  • inet.0 (IPv4)
  • inet6.0 (IPv6)

You must decide what routing tables are required on your new firewall; whether you will use only the default inet.0 and inet6.0 or if you will create new routing instances to map virtual routers from the old Netscreen firewall.

Here is a ScreenOS example where only trust-vr is used so only Junos inet.0 is needed on a new SRX firewall.

ScreenOS

set vrouter untrust-vr
exit
set vrouter trust-vr
set route 10.0.1.0/24 interface ethernet0/0 gateway 10.0.2.1
set route 0.0.0.0/0 interface ethernet0/1 gateway 198.51.100.1
exit

Junos

set routing-options static route 10.0.1.0/24 next-hop 10.0.2.1
set routing-options static route 0.0.0.0/0 next-hop 198.51.100.1

Management

I recommend configuring device management correctly before continuing to security policies. Here, you will configure for example SSH, NTP, SNMP and SYSLOG as required.

These topics do not map neatly from ScreenOS to Junos. Generally, there is more Junos configuration required than the old ScreenOS configuration. Just deal with each section one at a time.

Here is a simple example for SSH.

SSH
ScreenOS

set ssh enable
set interface loopback.1 zone LAN
set interface loopback.1 manage ssh

Junos

set system services ssh 
set security zones security-zone LAN interfaces lo0.0
set security zones security-zone LAN host-inbound-traffic system-services ssh

Services

Here are simple examples contrasting ScreenOS and Junos of DNS Proxy and DHCP Relay configuration:

DNS
ScreenOS

set dns host dns1 8.8.8.8
set dns proxy enable
set dns server-select domain * primary-server 8.8.8.8

Junos

set system name-server 8.8.8.8
set system services dns dns-proxy interface ge-0/0/0.0
set system services dns dns-proxy view DNS-VIEW match-clients 10.0.0.0/24
set security zones security-zone LAN host-inbound-traffic system-services dns

DHCP
ScreenOS

set interface ethernet0/8.35 dhcp relay server-name 10.0.0.1
set interface ethernet0/8.35 dhcp relay service

Junos

set forwarding-options dhcp-relay server-group DHCP-SERVERS-1 10.0.0.1
set forwarding-options dhcp-relay group DHCP-GROUP-1 active-server-group DHCP-SERVERS-1
set forwarding-options dhcp-relay group DHCP-GROUP-1 interface ge-0/0/0.0

Applications

The ScreenOS service section is called applications in Junos.

ScreenOS

set service ESP protocol 50 src-port 0-65535 dst-port 0-65535
set service DNS protocol udp src-port 0-65535 dst-port 53-53

Junos

set applications application ESP protocol 50
set applications application DNS application-protocol dns

Address book

Translating the ScreenOS address book to Junos is a simple matter of transforming the text and adding a few words.

ScreenOS

set address LAN-1 HOST-1 10.0.0.1 255.255.255.255

Junos

set security zones security-zone LAN-1 address-book address HOST-1 10.0.0.1/32

If you want to re-use the same address book entries in policies and NAT you must use the global address book and not the zone address book. Juniper recommends using the global address book.

Policies

ScreenOS policy configuration is the most difficult to translate to Junos and perhaps requires scripting. Microsoft Excel could also be used.

As you can see below, the ScreenOS configuration resembles the Junos JSON format where configuration is grouped into stanzas.

I recommend as a starting point to transform the ScreenOS configuration so all lines begin with “set policy id”.

ScreenOS

set policy id 33 name POL-1 from LAN to Internet HOST-1 HOST-2 HTTP nat src permit
set policy id 33 
exit
set policy id 33
set dst-address HOST-3
set service HTTPS
set log session-init
exit

Junos

set security policies from-zone LAN to-zone Internet policy POL-1 match source-address 10.0.0.1/32
set security policies from-zone LAN to-zone Internet policy POL-1 match destination-address HOST-2
set security policies from-zone LAN to-zone Internet policy POL-1 match destination-address HOST-3
set security policies from-zone LAN to-zone Internet policy POL-1 match application junos-http
set security policies from-zone LAN to-zone Internet policy POL-1 match application junos-https
set security policies from-zone LAN to-zone Internet policy POL-1 then permit
set security policies from-zone LAN to-zone Internet policy POL-1 then log session-init

NAT

The ScreenOS NAT configuration is very simple, “nat” is a policy key-word in the CLI or tick-box using the web-GUI. Junos NAT requires more configuration.

ScreenOS

set policy name POL-1 from LAN to Internet HOST-1 Any HTTPS nat src permit

In Junos, NAT is not referenced in the policy at all but configured in its own section.

Junos

set security nat source rule-set LAN-to-Internet from zone LAN
set security nat source rule-set LAN-to-Internet to zone Internet
set security nat source rule-set LAN-to-Internet rule RULE-1 match source-address 10.0.0.1/32
set security nat source rule-set LAN-to-Internet rule RULE-1 match destination-address 198.51.100.1/32
set security nat source rule-set LAN-to-Internet rule RULE-1 match application junos-https
set security nat source rule-set LAN-to-Internet rule RULE-1 then source-nat interface

If you want to re-use the same address book entries in policies and NAT, you must use the global address book and not the zone address book.

Junos

set security address-book global address HOST-1 10.0.0.1/32

Maintenance

Here are some pre-requisite tasks before conducting a maintenance to replace a Netscreen firewall:

Old firewall

  • health check and log information saved and reviewed.

New firewall

  • configured and with correct software version and licenses.
  • rack mounted if it’s a physical device.
  • powered on and basic health checks done to confirm it is operating correctly e.g. show chassis alarms, show system alarms, show chassis cluster status, show interfaces terse, show security monitoring

For the maintenance consider these points:

  • Will you use new cabling or move existing cables from the old firewall?
  • Can you integrate the new firewall into existing network management systems as a new device with a new management IP address before the maintenance, or must the new firewall use the same management IP address as the old firewall?
  • How will you confirm the new firewall is operating as expected? Know in advance what things you must health check to confirm the maintenance is successful. At minimum before the maintenance know how to review firewall logs of traffic that is denied (dropped).

I hope this article helps you plan to replace your old Netscreen firewall!

You are welcome to get in touch with ngworx.ag for more advice. We are an elite Juniper Partner and are already experienced with sucessfully migrating Juniper Netscreen to Juniper SRX and other firewall platforms like Fortigate.

References

Juniper NetScreen Security Products Hardware Dates & Milestones

https://support.juniper.net/support/eol/product/netscreen_hw

ScreenOS software was last released in 2014 as version 6.3.0 with only occasional patches since
https://support.juniper.net/support/downloads/?f=isg
https://support.juniper.net/support/downloads/?f=ssg

ScreenOS Documentation
https://www.juniper.net/documentation/product/us/en/screenos

Junos Documentation
https://www.juniper.net/documentation/product/us/en/junos-os

ngworx Team
July 2021
written by Nigel Wensley
Senior Network & Security Engineer

Most Popular

Network-Engineering | 8 min read

Junos upgrade – filesystem is full

Not enough storage during Junos upgrade (EX2300 and EX3400). An extension of Juniper's article…

Read more

Juniper Networks

Want to learn more about Juniper Networks? Discover their solutions, products, awards, team leaders, partners, training programs, and the latest events by clicking the button below.