Showing posts with label Juniper. Show all posts
Showing posts with label Juniper. Show all posts

Friday, November 27, 2015

Custom Parsers in IBM QRadar & Juniper STRM

I had some trouble getting all this around my head first time around so I thought I'd put it all together in one place; make things a little bit easier for both myself and whoever else cares to take a look!

Create LSX
First thing is to create a custom parser, also known as a Log Source Extension. This will allow the QRadar to parse custom logs and map data from them to columns in an event.

Do this by looking at all possible logs that will be incoming and specify the data you want to extract, this can include IP addresses, ports, and events. The most important being the event, this is the main component that QRadar will use to identify the log and map it to a QID. 

If you're going to use your own QIDs (which I would recommend) then you're going to want your Event to be mapped to something unique. Meaning if I have the following log:

2015-05-20 00:02:07,518 ERROR [common.ESBLogger] A1217ProducerEmailHandler -- processA1217Resquest -- Mapping not found in lookup table for requirement type code = 1036900347

The actual Event is the fact that the mapping was not found in the lookup table - this is what I'm going to want to look for in my parser. Now when I do something as specific as this, it really limits the amount of regex I actually have to use. If I wanted to use "ERROR" as my event, but also pick up "INFO" and "WARN", then I could use something like: 

(?<=\d\s)([A-Za-z]*)(?=\s\[)

This would result in my events being parsed as either INFO, ERROR, or WARN.

If I knew multiple types of events were going to be produced with the same syntax (following a double hyphen and ending in an equal sign, where Mapping not found in lookup table for requirement type code is in the log) I could use regex to match that:

(?<=\-\s)([A-Za-z\s]*)(?=\s\=)

This would be a bit more useful that just the category of the log.

Example of an LSX
<?xml!version="1.0" encoding="UTFd8"?>
<!--
Device Type: ESBLogger
Protocol: Syslog
-->

<devicedextension!xmlns="event_parsing/device_extension">

<!-- Do not remove the "allEventNames" value -->
<pattern id="allEventNames" xmlns="">
<![CDATA[(.*)]]>
</pattern>
<!-- Everything below this line can be modified --> 

<!-- Match event of Mapping not found -->

<pattern id="EventName1" xmlns="">
<![CDATA[(?<=\-\s)([A-Za-z\s]*)(?=\s\=)]>
</pattern>

<match-group order="1" description="ESBLogger" xmlns="">

<matcher field="EventName" order="1" patterndid="EventName1" capturedgroup="1" enabledsubstitutions="false"/>
<eventdmatchdmultiple patterndid="allEventNames" capturedgroupdindex="1" devicedeventdcategory="unknown" senddidentity="OverrideAndAlwaysSend" />
</match-group>
</devicedextension>

Complete walkthrough:
https://www.sans.org/reading-room/whitepapers/logging/qradar-log-source-extension-walkthrough-35452

Create QID
Once you create a custom parser, you need to map the parsed log to an Event. There are built in events which you can apply, however for complete customization you can create your own. Unfortunately the only way to do this is through the CLI of the QRadar box.

You're going to want to locate the low-level category for the QID map entry you want to create; use the following command for this:
/opt/qradar/bin/qidmap_cli.sh -l

If you want to search for a particular low-level category, you can use the grep command to refine the results; since my example is an application log I'm going to start there
/opt/qradar/bin/qidmap_cli.sh -l | grep Application

Once you know the category you can use the following command to create your QID:
qidmap_cli.sh -c --qname --qdescription --severity --lowlevelcategoryid


The following table provides the utility options; use -h for more options:
OptionsDescription
-cCreates a new QID map entry.
--qnameType the name you want to associate with this QID map entry. The name can be up to 255 characters in length, with no spaces.
--qdescriptionType a description for this QID map entry. The description can be up to 2048 characters in length with no spaces.
--severityType the severity level you want to assign to this QID map entry. The valid range is 0 to 10.
--lowlevelcategoryidType the low-level category ID you want to assign to this QID map entry.

Complete walkthrough:
https://www.juniper.net/techpubs/software/management/strm/2012_1_R1/strm-managing-qid-map.pdf

Setup Log Source
The first step is to upload the log source extension. There is a log source extension management GUI available within the Admin tab of Qradar. If the log source extension has the proper syntax, it will be accepted when uploaded to the console following the steps under the “add” action.

The next step is to create a generic log source using the “Universal DSM”. The log source needs to match against the data received from the log source. 

If the regular expression used to match against event names is working then the events should start appearing in the Qradar log window. At this point, the event name will show the “unknown” on the Qradar log viewer. Correctly matched fields such as source IP and Destination IP indicate proper functioning of the LSX.

Map Events
Unlike a DSM, a log source extension does not have any built in logic to help with event mapping. Each event shows “unknown”, however, we identified a place within each log to search for some text that will give us information on how to map a particular event. As each unknown event is matched, it will start to show that new event name each time that type of event is seen.

A button titled “Map Event” is available from the menu while viewing an event detail. This will give a pop up box showing the event name we are searching for in the log. There is a search dialog for selecting an available event name or “Qradar Identifier” or QID.

This data will also begin to populate any rules that reference this particular Qradar identifier.

Tuesday, August 5, 2014

Site-to-Site VPNs - Part 1: The Basics

I've been getting a lot of questions lately about VPNs (virtual private networks); how they work, what are they, how to configure them. To most CCNA graduates it can be a bit confusing. Seeing as more than half the work in our NOC consists of VPN-related issues I thought it'd be good to get everything out in the open for those who aren't sure about them.

There are a couple different types of VPN connections (L2L, RAS, SSL, etc), however we're going to just with the basics and cover a site-to-site connection.

If you have your CCNA, you should be familiar with the concept of Frame-Relay. It allows two private networks to connect to one another as if there was nothing but a router in between. Nowadays we generally use MPLS or VPNs in place of a Frame-Relay PVC. What this allows you to do is more easily and dynamically connect multiple subnetworks together for very cheap (and in VPN cases, basically free - provided you have the equipment).

Speaking of equipment, we'll be covering three in these posts: a Cisco IOS-based router, a Cisco ASA, and a Juniper SSG - they all employ the same technology.

Core

Before we can configure our tunnels, we need to know how they operate. You'll hear terms like phases, SAs, "interesting traffic", route based vs policy based, encryption, and a million other terms thrown around by NOC-monkies; this is where we'll explain everything you need to know to keep up in the conversation and impress your friends.

Let's begin by breaking down the order of operations for establishing an IPSec VPN.

First we'll need some traffic that wants to connect to a remote host. This is called "interesting traffic"; it's interesting because it triggers an ACL (or policy). This ACL/policy is being monitored by the VPN on your firewall. ACL is hit, traffic is tunneled - simple. This is a policy based VPN. The alternative would be a route based VPN; I find these very popular on ScreenOS. They require you to create a virtual tunnel interface to route traffic towards as you would any other interface.

Your VPN can be configured in one of two modes, Aggressive or Main. Aggressive is used when your remote LAN is using a dynamic IP address or behind NAT; this will cause the tunnel peer or hub (where your VPNs terminate) to consider VPN requests from any peer IP address. However, all interesting traffic will have to be initiated from the remote firewall; the head doesn't know the IP of its peer until the tunnel is established.

Once your remote firewall has interesting traffic that needs to be tunneled, it reaches out to its peer's IP and initiates what's referred to as "Phase One negotiations".  In Phase One, the two peers negotiate an authentication method, encryption algorithm, hash algorithm, and Diffie Hellman group as well as a timeout - this is known as the proposal in Junipers and a Transform Set in Cisco-world. After both sides are in an agreement an IKE SA is created and a secure connection has been created between them so they can safety start with Phase Two. If a single setting in the Phase One proposal is mismatched between peers, the IKE SA will fail to be established.

In Phase Two, the keying material is generated, and the two peers agree upon the policy that will be used (known as a proxy ID in Juniper-land when using a route based tunnel). This mode, which is called quick mode, differs from Phase One in that it can't occur until after Phase One is successful and all of the Phase Two packets are encrypted. This makes troubleshooting a little more difficult as it is possible for Phase One to be successful but Phase Two to fail. If Phase Two is successful, it will result in a Phase 2 SA, also called an IPSec SA, and the tunnel will be fully established.

I'll be going into more detail about everything mentioned above in Part 2, when we go through deploying both route based and policy based IPSec VPNs on a Juniper SSG Firewall from start to finish.

Thursday, May 29, 2014

Enabling PPTP passthrough on ScreenOS

Enable vip multi-port command; this allows a VIP service to listen to multiple ports simultaneously
After entering set vip multi-port you'll be promptd with a warning that you must reboot.
set vip multi-port
save
reset
Define the service as usual
set service CustomPPTP group "other" 47 src 2048-2048 dst 2048-2048      
Append the TCP source ports to the service we just defined
set service CustomPPTP + tcp src 0-65535 dst 1723-1723
The source port for TCP 1723 must be 0-65535 to allow for any source port

Set up your VIP   
set int eth0/0 vip interface-ip 2048 CustomPPTP 192.168.1.2
And define your policy
set policy from untrust to trust any vip(ethernet0/0) CustomPPTP permit log

Tuesday, February 25, 2014

Policy-based NATing on ScreenOS

Source NATing

I recently had to deploy a firewall for a home user where the VPN address space was limited, and it would be best to not re-IP the LAN devices as only specific destinations would be accessed through the VPN. To accomplish this, I employed some simple static routing and source NATing.

When sending traffic from the LAN through the VPN, because we're using the same addressing space (for this example 10.10.0.0/16) source NATing allows us to have a neutral address for both the source and destination.

If you would like to have more than one host connecting with unique IP addresses, it's best to utilize a DIP pool to use with your NATing; this acts much like a DHCP pool. You can additionally enable PAT (Port Address Translation) which supports up to 64,500 hosts simultaneously. However, a DIP pool is best used (with PAT disabled) when the source port number must remain fixed. When done in this fashion, the SSG will issue one address for the same host for all of it's sessions. Whereas with PAT enabled, each session might receive a unique source address.

If you do not specify a DIP pool, the SSG will translate the source address to the egress (outgoing) interface. When you do this, PAT is automatically enabled. I find this way much easier for our purpose.

So first thing's first, lets define our hosts; because we're connecting from a handful of possible devices who are utilizing DHCP, we're going to just define the entire subnet:
set address "Trust" "192.168.1.0/24" 192.168.1.0 255.255.255.0
set address "DMZ" "10.10.0.0/16" 10.10.0.0 255.255.0.0
The DMZ address here is our remote network.

Now for the routing:
set route 10.10.0.0/16 interface tunnel.1
So anything destined for 10.10.0.0/16 will be routed through the tunnel interface; which just so happens to have an address in that scheme.

Now for the policy and NAT:
set policy from "Trust" to "DMZ" "192.168.1.0/24" "10.10.0.0/16" "ANY" nat src permit log
Any traffic from our local subnet of 192.168.1.0/24 destined for 10.10.0.0/16 will be routed through the tunnel interface after being NATed to the egress interface's IP address; our tunnel interface, which as stated earlier holds an IP in the 10.10.0.0/16 scheme!

For those of you who wish to use a DIP pool, I've got you covered!
set interface ethernet0/1 dip 1 10.10.1.1 10.10.1.254 fix-port
set policy from "Trust" to "DMZ" "192.168.1.0/24" "10.10.0.0/16" "ANY" nat src dip-id 1 permit log
 
For this to work, because the 10.10.0.0/16 network lives on both ends of the tunnel, a route on the head will have to be set to route anything destined for the 10.10.1.0/24 range through the tunnel to our LAN.

The fix-port option in the DIP denotes that PAT will not be used.; remove this option to enable PAT.


To be continued with destination NATs, MIPs and VIPs...


Thursday, November 28, 2013

Blocking Skype on ScreenOS

Unfortunately, ScreenOS doesn't have the same deep packet inspection and application control that Fortinet or even Cisco has. Skype is built around P2P networking and uses dynamic incoming ports and can even fall back on to 80/443 for it's communication. It's design this way for ease-of-use, so that a layer 3 firewall will never stand in the way from you having free VoIP phone calls. However, this can cause some frustration when trying traditionally block it on a firewall using a port-range.

On a Cisco you can utilize NBAR because they've implemented a Skype application classification, and with Fortinet you can use their application control function. But on an old fashioned ScreenOS-based Juniper, you're shit-out-of-luck. There is however a very McGuyver-way to do it.

When a Skype client is connected it must authenticate the username and password with the Skype login server. There are many different Skype login servers using different ports. An obfuscated list of servers is hardcoded in the Skype executable. With this list we can deny outbound traffic.

Can't login, can't use Skype. Simple.

Now there is a list of servers published on Wikipedia, however after some research this appears to be an outdated and pre-Microsoft server list. This is a tested and working list of authentication servers:
64.4.23.0/24
65.55.223.0/24
111.221.74.0/24
111.221.77.0/24
157.55.56.0/24
157.55.130.0/24
157.55.235.0/24
157.56.52.0/24
213.199.179.0/24

Defining your remotes

set address "Untrust" "Skype_64.4.23.0/24" 64.4.23.0 255.255.255.0
set address "Untrust" "Skype_65.55.223.0/24" 65.55.223.0 255.255.255.0
set address "Untrust" "Skype_111.221.74.0/24" 111.221.74.0 255.255.255.0
set address "Untrust" "Skype_111.221.77.0/24" 111.221.77.0 255.255.255.0
set address "Untrust" "Skype_157.55.56.0/24" 157.55.56.0 255.255.255.0
set address "Untrust" "Skype_157.55.130.0/24" 157.55.130.0 255.255.255.0
set address "Untrust" "Skype_157.55.235.0/24" 157.55.235.0 255.255.255.0
set address "Untrust" "Skype_157.56.52.0/24" 157.56.52.0 255.255.255.0
set address "Untrust" "Skype_213.199.179.0/24" 213.199.179.0 255.255.255.0

Blocking your hosts

 The following ACL will deny all hosts in the Trust zone from accessing the Skype servers. If you want to block specific hosts then change/add the source addresses/zones in the policy. For multiple specific hosts you will need to add a line similar to set src-address "192.168.1.1/32".
set policy top from "Trust" to "Untrust" "Any" "Skype_64.4.23.0/24" "ANY" deny log
set dst-address "Skype_65.55.223.0/24"
set dst-address "Skype_111.221.74.0/24"
set dst-address "Skype_111.221.77.0/24"
set dst-address "Skype_157.55.56.0/24"
set dst-address "Skype_157.55.130.0/24"
set dst-address "Skype_157.55.235.0/24"
set dst-address "Skype_157.56.52.0/24"
set dst-address "Skype_213.199.179.0/24"

Friday, November 22, 2013

Packet Profiling on ScreenOS

Occasionally I've had clients report high latency or slowness. I've gone over bandwidth reports and can see long peaks of high usage and their pings come back well over 200ms. Now on a Cisco device you can turn on NetFlow and see who the top talkers are. Unfortunately a lot of people don't know how to do this on a Juniper (ScreenOS).

Recon

The first thing you'll want to do is log into the device, if there is a lot of traffic response times in the terminal may be slow so bare with it. You'll need to enable packet profile then start it up. If packet profiling has been run on the device before it'd be a good idea to clear the existing information as well.
set fprofile packet enable
clear fprofile
set fprofile packet start
By defualt, the profiling buffer is set to nowrap so that the packet profiling will automatically halt when the buffer is full. If you wish to disable this use the command set fprofile packet wrap; this will cause the profiling to continually run until it's manually stopped. Be advised that it will overriding the existing buffer with new information (I believe NetFlow on Cisco operates in a similar fashion)

Now that you have it running, give it some time to gather traffic information.

Analysis

If you decided to turn on wrapping, issue the command set fprofile packet stop. Otherwise you should be good to go. To display the gathered information issue the command get fprofile packet. This will give you the default output, as seen below.
ssg5-> get fprofile packet
packet buffer size(in kilo-packets): 4
total ip packet: 4090
total ip packet time(us): 349668
total none-ip packet: 6
total none-ip packet time(us): 206
    Id  Type    Protocol    Source                Destination        Sport    Dport    Time    Percentage
    1  ip        0x06        192.168.0.1            192.168.1.254    80        2917    71099    20.32%
    2  ip        0x06        4.2.2.2                192.168.1.254    80        2237    52399    14.97%  
    3  ip        0x06        192.168.1.2            192.168.1.254    80        2800    51627    14.75%  
    4  ip        0x06        192.168.1.1            192.168.0.1        49966    80        42703    12.20%  
    5  ip        0x06        4.2.2.1                192.168.1.254    80        1224    34008    9.72%  
    6  ip        0x06        192.168.1.1            4.2.2.2            49949    80        26675    7.62%  
    7  ip        0x06        192.168.1.1            4.2.2.2            49900    80        26235    7.49%  
    8  ip        0x06        192.168.1.1            4.2.2.1            49935    80        17235    4.92%  
    9  ip        0x01        192.168.1.2            192.168.1.254    8        0        3467    0.00%  
    10 ip        0x32        192.168.1.2            192.168.1.254    44562    48388    2527    0.00%  
Blogger isn`t wide enough to display this properly. I should find a new theme...I`ve also changed the IPs to meaningless one for the sake of this post. Don`t want anyone`s networks getting ID`d ;)

So take a look at the top users and see if you can see any patterns, in the example below we can see that 192.168.1.1 has a session open to 192.168.0.1. At the same time there is a session open from 192.168.0.1 to 192.168.1.254(which happens to be our modem).

Now we'll want to look at the ARP for our suspected culprit ( 192.168.1.1) and do a look up on both the MAC and the remote IP (192.168.0.1). I use Wireshark`s OUI Lookup Tool.

From here we can trace the MAC and IP through the our MAC and ARP tables to find which switch (or AP, usually) it`s hanging off of.

Once stopped the packet profiling settings will still be in the configuration (much like NetFlow), however if you wish to remove it completely use the unset fprofile packet enable command.

Reference

clear fprofile

get fprofile packet ip proto top <NUMBER>
get fprofile packet ip proto all
get fprofile packet ip proto
get fprofile packet ip src-ip top <NUMBER>
get fprofile packet ip src-ip all
get fprofile packet ip src-ip
get fprofile packet ip dst-ip top <NUMBER>
get fprofile packet ip dst-ip all
get fprofile packet ip dst-ip
get fprofile packet ip sport top <NUMBER>
get fprofile packet ip sport all
get fprofile packet ip sport
get fprofile packet ip dport top <NUMBER>
get fprofile packet ip dport all
get fprofile packet ip dport
get fprofile packet ip top <NUMBER>
get fprofile packet ip all
get fprofile packet ip
get fprofile packet none-ip proto top <NUMBER>
get fprofile packet none-ip proto all
get fprofile packet none-ip proto
get fprofile packet none-ip src-mac top <NUMBER>
get fprofile packet none-ip src-mac all
get fprofile packet none-ip src-mac
get fprofile packet none-ip dst-mac top <NUMBER>
get fprofile packet none-ip dst-mac all
get fprofile packet none-ip dst-mac
get fprofile packet none-ip top <NUMBER>
get fprofile packet none-ip all
get fprofile packet none-ip
get fprofile packet top <NUMBER>
get fprofile packet all
get fprofile packet
get fprofile

set fprofile packet enable

Friday, May 31, 2013

Installing and configuring Rancid

If you have more than a couple devices in your network, you might find backing up conifig files to be a tedious task. If you have more than a handful (which most network admins will); it can become a quest..

This is where Rancid comes in, it's a small application for Linux which lets you automate the process You can also make it execute commands on the same remote devices automatically (good for clearing tunnels or other resets). It's also good because it supports Fortinet FortiGates (which for their all-in-one nature and cheapness are on the rise). But the most difficult thing I found was trying to get it installed and configured properly.

First you'll want to install your favourite flavour of linux; I'll be using Ubuntu simply due to it's popularity and available repositories.

Open up a terminal window and get to installin'
sudo apt-get install rancid
This will install Rancid onto your machine into /var/lib/rancid. It will also create a new user called rancid to be used with the application. I couldn't find any documentation on what the default password is for this user (however at least one person suggested it was rancid, that didn't work for me) so we'll want to go ahead and change it.
sudo passwd rancid
You'll be prompted to input a new password and confirm it, for simplicity's sake I just stuck with rancid.

Now we can start to configure Rancid itself. It nests devices in groups, you can execute commands to a group as a whole which makes management a lot easier. To add a group you'll have to edit the rancid.conf file, you can find this in /etc/rancid/

You'll see a bunch of commented lines in there already; we need to add one to the bottom. If you're not familiar with VI, use the arrow keys to get down to the line you want to input on, press i to enter INSERT mode and begin typing. Once you're finished, hit ESC and type :wq to write to the file and quit VI and return to the terminal.
vi /etc/rancid/rancid.conf    LIST_OF_GROUPS="toronto montreal vancouver"   :wq
Each group name is seperated by blank space, you can put in as many as you like; we'll be adding our devices to these groups afterwards.

Now that we have our groups in order, we need to generate the CVS files for them. We'll want to run this command as our rancid user.
sudo su -c /var/lib/rancid/bin/rancid-cvs -s /bin/bash -l rancid
This will generate a directory for each of the groups you defined earlier in /var/lib/rancid/
Each directory will contain a router.db file, this is where we'll be storing our device information
So back into VI we go!
sudo vi /var/lib/rancid/toronto/router.db
The router.db files have a specific syntax and if you mess it up, it won't work; so be careful!
For a basic entry you'll need to input the following
#toronto-c1811
192.168.2.1:cisco:up
This will point at a Cisco device with the IP of 192.168.2.1 and tell Rancid that the device is up. Each variable is separated by a colon. If the status is set to down the script will ignore that device. Rancid supports the use of FQDNs in place of IP addresses, however I do not use them. Lines beginning with # are comments, it would be good habit to comment each device you add (even if you're using an FQDN). For the entire list of options refer to the man page from Shrubbery Networks

So Rancid knows where to find our devices, but like hell it'll be able to login; so we need to define that as well. Rancid keeps all it's login information in .cloginrc located in /var/lib/rancid/. When I installed Rancid, this file wasn't auto-generated (apparently there's a sample-cloginrc but I wasn't able to find it on my machine) so I had to create it with VI:
sudo vi /var/lib/rancid/.cloginrc
Quick linux note: anything starting with a period is a "hidden" file and will not show up with ls

We should have a blank VI file open right now, get into INSERT mode and put in your box's login creds.
add method 192.168.2.1 ssh
add user 192.168.2.1 cisco
add password 192.168.2.1 cisco cisco
The first line will define what protocol to connect with, in the case you have SSH and Telnet enabled (which I would advise against but whatever)
You can put in:
add method 192.168.2.1 ssh telnet
Rancid will first attempt to connect on SSH, then fall back to Telnet in the event of a failure. The second line is the username, and the third is both the password and the enable password. Now there is a lot of other options you can put here which I don't personally use, but feel free to browse them on the man page.

I found that for Rancid to run we'll have to give our rancid user ownership of rancid install directory and turn our new login file into read/writeble (but not exedcuteable) only by it's owner (which we're about to make rancid)
sudo chmod 600 /var/lib/rancid/.cloginrcsudo 
chown -R rancid:rancid /var/lib/rancid
Now we're ready to run Rancid!
sudo su -c /var/lib/rancid/bin/rancid-run -s /bin/bash -l rancid
It should take a little bit to run (depending on how many devices you have an how big their config files are)
Once it's finished you can check the log in /var/log/rancid and check your config file in /var/lib/rancid/toronto/configs/192.168.2.1

And thats it! Put it on a cron job and you'll never have to do it manually again.

Observium Integration

This was a very annoying task to get to work, but once it's work its bloody brilliant.
You'll have to do things a little differently because Observium uses hostnames opposed to IP addresses for adding devices. So I went and edited my /etc/hosts file to reflect the devices I was adding.

Open your config file for Observium and point towards your Rancid configs:
vi /opt/observium/config.php 
$config['rancid_configs'][]              = '/var/lib/rancid/toronto/configs/';
$config['rancid_ignorecomments']        = 0;
Now provided your config files are showing up with hostnames opposed to IP addresses. Everything should  work. However this is where I got stuck, and it's the most linux of problems; user groups. Observium will be accessing the Rancid config  using the apache's www-data user, which isn't in our rancid user group.
usermod -a -G rancid www-data
Now once you restart your apache service (service apache2 restart) you should be good to go! You'll know its working because Observium will add a config tab to the device page.

NOTE: I had installed Rancid on top of Turnkey's Observium distro and found that telnet was not installed by default; apt-get install telnet to fix.

 

Monday, May 27, 2013

Implementing NSRP

NetScreen Redundancy Protocol (NSRP) is a proprietary protocol that provides configuration, run time object (RTO) redundancy, and device failover for NetScreen devices in a high availability (HA) cluster.

Connection

Juniper has pre-configured their more powerful devices with an HA zone. This zone allows the devices in the cluster to transfer and receive NSRP data and information from one another.

The SSG140 and above have this zone pre-installed. For devices that do not natively support it, a license from Juniper and manual configuration is required.

On some NetScreen devices, there are multiple dedicated (physical) HA interfaces. Each interface handles different kinds of HA communication as well as act as a back-up interface should one fail. By default, HA1 handles control messages and H2 handles data messages.

On NetScreen devices that do not have dedicated HA interfaces, you must bind one or two physical ethernet interfaces to the HA zone. For this demonstration we'll be using ethernet1/4.
set int eth1/4 zone "HA"

The devices will now know which interface to listen for NSRP messages. Input the NSRP commands to set up the cluster; the cluster ID must be identical on both devices. An NSRP cluster acts similar to a cluster in any other technology; it simply groups devices together.
set nsrp cluster id <#>
set nsrp cluster name <name>

Priority

A VSD group is a set of physical devices that make up a single virtual security device (VSD). One physical device acts as the primary of the VSD group. The virtual security interface (VSI) of the VSD is bound to the physical interface of the primary device. The other physical device acts as the backup. A VSD acts similar to a RAID array; a single virtual device made up of a cluster of physical devices.

We need to tell the firewalls which one is the master, and which one is the backup. The priority of the preferred backup should be a higher value, as the lower priority takes precedence. We want the device we're configuring to be the master but because we don't want it to take over until we're ready, we'll go ahead and set the priority to 200.
set nsrp vsd-group id 0 priority 200

Ctrl-S

At this point we'll want to save the configurations we've made so they don't conflict when loading the mirror configuration over.
save

Ctrl-C

Because we're configuring a brand new ISG, no extensive config exists. But we've set up NSRP already, and our backup has a configuration, so lets just copy that over.
exec nsrp sync global-config save
NOTE: Because this is an exec command, it has to be issued via a console connection

After this command is input, the device needs to be reset by simply issuing the reset command. Upon reboot, we should go through the configuration to make sure everything is correct. After POST it will tell you which commands (if any) failed, but it never hurts to be thorough.

Sync

Defining a NetScreen device as a member of a cluster and specifying RTO synchronization automatically enables the local device to send and receive RTOs. By default, NSRP cluster members do not synchronize RTOs. Before enabling RTO synchronization, you must first synchronize the configurations between the cluster members. Unless the configurations on both members in the cluster are identical, RTO synchronization might fail.
set nsrp rto-mirror sync
Run-time objects (RTOs) are code objects created dynamically in memory during normal operation. Some examples of RTOs are session table entries, ARP cache entries, DHCP leases, and IPSec security associations (SAs). In the event of a failover, it is critical that the current RTOs be maintained by the new master to avoid service interruptions. To accomplish this, RTOs are backed up by the members of an NSRP cluster. Working together, each member backs up the RTOs from the other, which allows RTOs to be maintained should the master of either VSD group in an active/active HA scheme step down.

Taking Control

Enable the preempt option for a device that you want to be master of the VSD group (which is the one we're configuring). Normally, that device also has the better priority number (closer to 1). In the event of a failover resulting in the new master having a lower priority than the previous master, when the previous master—with the preempt option set—becomes operable and eligible again, it automatically regains mastership of the VSD group. So basically, if our master fails and the backup takes over, but the master recovers it will regain control of the cluster. Because we are configuring a NEW master, once connected and configured it will automatically take over. We'll also want to lower the priority back down to 1.

WARNING: Before making this device the master we'll have to recable
set nsrp vsd-group id 0 priority 1
set nsrp vsd-group id 0 preempt 

Monitor

Now what we have configured the device for NSRP, we need to tell it which connection to monitor. The interface we choose will typically be the WAN interface, if this interface goes down the fail-over initiates and the back-up device takes over control of the VSD.
set nsrp monitor int eth1/3

Restoring Order

Everything is configured as it should be. Now we'll just want to make some tweaks.
First we would want to change the hostname of the device, so we can distinguish between the two.
set hostname <hostname>
If we want to have remote access to the device we'll need to setup management IP interfaces for us to use.
set interface ethernet1/1 manage-ip 192.168.1.2
set interface ethernet1/3 manage-ip 192.168.2.1
Now we'll be able to remote in through 192.168.1.2 and 192.168.2.1

We'll also need to change the speed and duplex settings on the interfaces as these do not get copied over
set int ethernet1/1 phy full 100mb
set int ethernet1/3 phy full 100mb
This will set eth1/1 and eth1/3 to full/100.

And that's it! We're finished and your device should be up and running as before.

Creating a VIP in ScreenOS

Port-forwarding in the Juniper world is done by creating MIPs, VIPs and DIPs. A virtual IP (VIP) address maps traffic received at one IP address to another address based on the destination port number in the TCP or UDP segment header. Mapped IP (MIP) is a direct one-to-one mapping of one IP address to another(public ip to private ip ) that means hiding some resources (server) from the public. A dynamic IP (DIP) address pool is a range of IP addresses from which the device can dynamically take addresses to use when performing NAT on the source IP address of outgoing or incoming IP packets.

You can link three types of interfaces to Dynamic IP (DIP) pools: physical interfaces and sub-interfaces for network and VPN traffic, and tunnel interfaces for VPN tunnels only

The most common use for a VIP is to map several DMZ intranet servers to a single public ip address on very small firewalls.

Setup

NOTE: a VIP must be created in the same network as the interface. If you want to forward from another subnet, you need to use NAT-DST

You can create a VIP under two conditions:
1. Your client's Public IP address is on the same network as the Firewall's Untrust interface IP address
2. Your client's Public IP address is the same IP address as the Firewall's Untrust interface IP address

You can assign the IP for the VIP in three ways.
1. Interface IP
2. Zone IP (Untrust)
3. Statically assign it

The address you assign your VIP must be on the same subnet as your Untrust (or the same address entirely), this only comes in to play when using option 3

interface-ip is your best bet for a dynamic address but will only work on ver 6.1 and up
untrust-ip is your next best alternative for use with a dynamic address, but if you have multiple interfaces in the untrust zone, it will choose the default (usually e0/0)
static is if you have the privledge of having a static IP adddress on the interface

For every port you wish you forward, you have to create a unqiue VIP
For example, if you want IMAP and SMTP traffic forwarded to your server at 192.168.1.101 you'll need to set up two VIPs on your outside interface:
set int e0/0 vip interface-ip 143 "IMAP" 192.168.1.101
set int e0/0 vip interface-ip 25 "SMTP" 192.168.1.101

Switcharoo

Sometimes you will need to forward unconventional ports; usually it's either to hide which ports you have open, or simply to accommodate software.
To do this you will need to explicitly define the service.

Say I want to use port 15011 for my BitTorrent traffic because the standard 69xx ports are being blocked; well Juniper doesn't know what operates on port 15011 because it's a non-standard port, therefore I'll have to define it. Because I know BitTorrent operates on 6881-6999, I can narrow down what traffic is forwarded.
set service "BitTorrent_15011" protocol tcp src-port 6881-6999 dst-port 15011-15011

Execution

Now we'll be able to apply this service to a policy (ACL on Cisco appliances)
set policy id 100 from "Untrust" to "Trust" "Any" "VIP(ethernet0/0)" "HTTP" permit log
set policy id 100
set service "BitTorrent_15011"
This will allow all traffic inbound to port 6881-6999 to be forwarded to my 192.168.1.101 client on port 15011.

Mind you, whatever your destination client is, has to be configured to be listening on the port the traffic is being forwarded to. In this case 15011.

Bouncing a tunnel on ScreenOS

So the tunnels down and the head resides on an SSG520 and you have no idea how to bounce it. Well you're in luck, this'll show you how to do it!

First! Connect to the SSG520. Make sure you don't muck around in this box because you can break many many things if you're not careful.

You'll need to connect via telnet or SSH depending on what's configured

Information Gathering

You'll need three commands to find VPN Tunnel information.

The first is:
get ike gateway
You'll be shown the IKE gateway configurations and the Phase 1 proposals as seen below.
SSG520-1(M)-> get ike gateway
 Id  Name            Gateway Address Gateway ID      Mode Proposals
---- --------------- --------------- --------------- ---- ---------
   2 foobardevice    192.168.1.2                     Main pre-g2-3des-sha
The second is:
get vpn
To see the VPN association with the IKE gateway and the Phase 2 proposals
SSG520-1(M)-> get vpn
Name            Gateway                  Mode RPlay 1st Proposal         Monitor Use Cnt Interface 
--------------- ----------------------- ---- ----- -------------------- ------- ------- ----------
foobardevice    foobardevice-isr        tunl No    g2-esp-3des-sha      on            0 eth3/0    
And lastly;
get sa
To examine the security association information.
SSG520-1(M)-> get sa | i 192.168.1.2

00000007<    192.168.1.2   500 esp:3des/sha1 7b0f24a1  2668 unlim A/U    -1 0
00000007>    192.168.1.2   500 esp:3des/sha1 4d512b11  2668 unlim A/U    -1 0

Insight

Now we have a plethora of information, but we still haven't bounced the tunnel. Lets use the information we've gathered to do that.

There's two things you'll need to clear, Phase 1 and Phase 2.

Since the editors at Wikipedia can explain this better than I can, I've provided a snippet below detailing Phase 1 and 2 for those who are unfamiliar with the process:

IKE consists of two phases: phase 1 and phase 2. IKE phase 1's purpose is to establish a secure authenticated communication channel by using the Diffie–Hellman key exchange algorithm to generate a shared secret key to encrypt further IKE communications. This negotiation results in one single bi-directional ISAKMP Security Association (SA). The authentication can be performed using either pre-shared key (shared secret), signatures, or public key encryption. Phase 1 operates in either Main Mode or Aggressive Mode. Main Mode protects the identity of the peers; Aggressive Mode does not. During IKE phase 2, the IKE peers use the secure channel established in Phase 1 to negotiate Security Associations on behalf of other services like IPsec. The negotiation results in a minimum of two unidirectional security associations (one inbound and one outbound). Phase 2 operates only in Quick Mode.

Tear Down

So you're a little bit smarter, and know what we'll be clearing. Let us proceed!

Phase 1 comes first.

The first command we issued provided us with an "IKE Gateway". This is just the public address of the peer (a peer is the other end of the tunnel).

Phase 1 is stored in an IKE cookie (not chocolate chip, think a browser cookie and you'll have a better understanding of how it works). We'll have to get rid of this cookie to wipe out Phase 1 information for the specific peer.
clear ike-cookie 192.168.1.2 
Sometimes just clearing Phase 1 will cause the tunnel to rebuild. If it does not we'll have to clear Phase 2 information (it's usually safer to tear the entire tunnel down anyway).
Onward to Phase 2!

We need to clear the security association for the tunnel.

If you remember when we input get sa, on the left-hand column we saw a bunch of numbers. These are hexidecimal labels used to identify a specific association.
SSG520-1(M)-> get sa | i 192.168.1.2 
00000007<    192.168.1.2   500 esp:3des/sha1 7b0f24a1  2668 unlim A/U    -1 0
00000007>    192.168.1.2   500 esp:3des/sha1 4d512b11  2668 unlim A/U    -1 0
No we won't be doing hex conversions, don't worry. But you will notice that there are two associations for one peer. One is for inbound, and the other for outbound. You can see which is which by looking at the arrow next to the hex ID.

We'll be using that hex ID to clear that specific association.
clear sa 0x07
If you've never used hex codes before, the preceeding 0x just identifies what proceeds as hexidecimal. We don't need to provide the entire ID as it's all zeros.

And that's it! You've successfully bounced the tunnel from an SSG520.

Rebuild

We tore down the tunnel but it's not coming back up. Probably because the user thinks it's down and isn't trying to use it. A tunnel won't be established until we flood it with interesting traffic. And what could be more interesting than pings!
ping 192.168.1.10 from e3/0
Where the IP address is the VPN address at the remote site, and the interface is the one used with the tunnel.

You can find the tunnel's interface in the output from get vpn command we input earlier.

SSG520-1(M)-> get vpn
Name            Gateway                  Mode RPlay 1st Proposal         Monitor Use Cnt Interface 
--------------- ----------------------- ---- ----- -------------------- ------- ------- ----------
foobardevice    foobardevice-isr         tunl No    g2-esp-3des-sha      on            0 eth3/0