Monday, October 14, 2013

SonicWALL - Forward Packets to Remote VPNs

Older versions of the SonicWALL operating system used to include a feature called, "Forward packets to remote VPNs." This feature, when enabled in a hub and spoke VPN topology, allowed for spoke sites to communicate with each other via a hub site. This is advantageous for a few reasons:
  1. SonicWALL does not support Group VPN (GDOI) or other mesh VPN technologies, leaving manual configuration as the only option.
  2. Configuring site to site VPNs for each and every site in your organization is time consuming, and depending on your SonicWALL model you may be limited by the number of IPSec tunnels allowed on your device (i.e. The TZ-105 only allows 5 IPSec tunnels).
I recently ran into this very situation. I was deploying a phone system at multiple sites for a customer, which required LAN-like communication between all sites. Rather than building tunnels at each site to every other site, I remembered the 'Forward packets to remote VPNs," feature. It would be great because it would save me time, as all traffic would just route through the hub site. However, in newer versions of the software this option is no longer present, so I had to do some research on how to make it work. I thought I would share what I did, since there is really no information out there (none that I could find anyway...) that walks you through the process.

For simplicity's sake, let's assume that we have 3 sites:
  • Los Angeles - This is our main office (AKA the hub site). The LAN subnet for this site is 10.0.0.0/24.
  • Austin - This is a branch office (AKA our first spoke site). The LAN subnet for this site is 192.168.0.0/24.
  • Atlanta - This is a branch office (AKA our second spoke site). The LAN subnet for this site is 172.16.0.0/24.
Here are the general configuration steps:
  1. On Los Angeles (the hub site):
    1. Define address objects for each site under Network -> Address Objects:
      1. Los Angeles:
        1. Name: Los Angeles LAN
        2. Zone Assignment: VPN
        3. Type: Network
        4. Network: 10.0.0.0
        5. Netmask: 255.255.255.0
      2. Austin:
        1. Name: Austin LAN
        2. Zone Assignment: VPN
        3. Type: Network
        4. Network: 192.168.0.0
        5. Netmask: 255.255.255.0
      3. Atlanta:
        1. Name: Atlanta LAN
        2. Zone Assignment: VPN
        3. Type: Network
        4. Network: 172.16.0.0
        5. Netmask: 255.255.255.0
    2. Create an address group for each site under Network -> Address Objects:
      1. Create a group called Austin:
        1. Add Atlanta LAN
        2. Add Los Angeles LAN
          1. Note that we are calling this group "Austin" even though we are not adding Austin LAN to the group. This group will be referenced in a VPN policy that will allow both the Los Angeles LAN and Atlanta LAN subnets to communicate with Austin. More information to follow...
      2. Create a group called Atlanta:
        1. Add Austin LAN
        2. Add Los Angeles LAN
          1. Same thing applicable here as above. We are calling the group Atlanta because it will be applied to the Atlanta VPN, but these address objects we are referencing do not include the Atlanta LAN address object.
    3. Create VPNs to each remote site under VPN -> Settings:
      1. Create a VPN called Austin:
        1. Under the General tab:
          1. Policy Type: Site to Site
          2. Authentication Method: IKE using Preshared Secret
          3. Name: Austin
          4. IPSec Primary Gateway Name or Address: (public IP of Austin site)
          5. Shared Secret: (enter whatever password you want here, just remember that it has to match on both ends)
        2. Under the Network tab:
          1. Local Networks: (choose Austin from the list)
          2. Remote Networks: (choose Ausitn LAN from the list)
        3. Under the Proposals tab:
          1. This varies, but I usually choose IKEv2 mode, and AES-256 for encryption at the very least.
        4. Under the Advanced tab:
          1. Check the Enable Keep Alive check box
      2. Create a VPN called Atlanta:
        1. Under the General tab:
          1. Policy Type: Site to Site
          2. Authentication Method: IKE using Preshared Secret
          3. Name: Atlanta
          4. IPSec Primary Gateway Name or Address: (public IP of Atlanta site)
          5. Shared Secret: (enter whatever password you want here, just remember that it has to match on both ends)
        2. Under the Network tab:
          1. Local Networks: (choose Atlanta from the list)
          2. Remote Networks: (choose Atlanta LAN from the list)
        3. Under the Proposals tab:
          1. This varies, but I usually choose IKEv2 mode, and AES-256 for encryption at the very least.
        4. Under the Advanced tab:
          1. Check the Enable Keep Alive check box
  2. On Austin (the spoke site):
    1. Define address objects for each site under Network -> Address Objects:
      1. Los Angeles:
        1. Name: Los Angeles LAN
        2. Zone Assignment: VPN
        3. Type: Network
        4. Network: 10.0.0.0
        5. Netmask: 255.255.255.0
      2. Austin:
        1. Name: Austin LAN
        2. Zone Assignment: VPN
        3. Type: Network
        4. Network: 192.168.0.0
        5. Netmask: 255.255.255.0
      3. Atlanta:
        1. Name: Atlanta LAN
        2. Zone Assignment: VPN
        3. Type: Network
        4. Network: 172.16.0.0
        5. Netmask: 255.255.255.0
    2. Create an address group for the other sites under Network -> Address Objects:
      1. Create a group called Other Sites:
        1. Add Atlanta LAN
        2. Add Los Angeles LAN
    3. Create a VPN to the Los Angeles site under VPN -> Settings:
      1. Under the General tab:
        1. Policy Type: Site to Site
        2. Authentication Method: IKE using Preshared Secret
        3. Name: Los Angeles
        4. IPSec Primary Gateway Name or Address: (public IP of Los Angeles site)
        5. Shared Secret: (enter the same password you entered when you created the Austin VPN on the Los Angeles SonicWALL)
      2. Under the Network tab:
        1. Local Networks: (choose Austin LAN from the list)
        2. Remote Networks: (choose Other Sites from the list)
      3. Under the Proposals tab:
        1. Enter the same information you entered on the Los Angeles SonicWALL
      4. Under the Advanced tab:
        1. Leave everything as is
  3. On Atlanta (the other spoke site):
    1. Define address objects for each site under Network -> Address Objects:
      1. Los Angeles:
        1. Name: Los Angeles LAN
        2. Zone Assignment: VPN
        3. Type: Network
        4. Network: 10.0.0.0
        5. Netmask: 255.255.255.0
      2. Austin:
        1. Name: Austin LAN
        2. Zone Assignment: VPN
        3. Type: Network
        4. Network: 192.168.0.0
        5. Netmask: 255.255.255.0
      3. Atlanta:
        1. Name: Atlanta LAN
        2. Zone Assignment: VPN
        3. Type: Network
        4. Network: 172.16.0.0
        5. Netmask: 255.255.255.0
    2. Create an address group for the other sites under Network -> Address Objects:
      1. Create a group called Other Sites:
        1. Add Austin LAN
        2. Add Los Angeles LAN
    3. Create a VPN to the Los Angeles site under VPN -> Settings:
      1. Under the General tab:
        1. Policy Type: Site to Site
        2. Authentication Method: IKE using Preshared Secret
        3. Name: Los Angeles
        4. IPSec Primary Gateway Name or Address: (public IP of Los Angeles site)
        5. Shared Secret: (enter the same password you entered when you created the Atlanta VPN on the Los Angeles SonicWALL)
      2. Under the Network tab:
        1. Local Networks: (choose Atlanta LAN from the list)
        2. Remote Networks: (choose Other Sites from the list)
      3. Under the Proposals tab:
        1. Enter the same information you entered on the Los Angeles SonicWALL
      4. Under the Advanced tab:
        1. Leave everything as is
Upon completion, you will see a green light on the VPN -> Settings page, which indicates that the VPN is up. On the remote sites, you will see 2 green lights, indicating connectivity to both the hub and spoke sites.

Wednesday, August 14, 2013

Asterisk, Google Voice, and Amazon EC2

I've been running Asterisk on my DD-WRT router for some time now. However, Juniper was awesome enough to give me a WLA and a virtual controller when I was invited to their tech summit this year, so I've decided to change things up with my home setup (for like the 80th time haha). I've been thinking of different ways to setup a home phone for free, utilizing Asterisk and Google Voice. One way would be by repurposing an Android Mini PC as shown to me by a buddy I do business with, but since I'm a cheap bastard and this is really more just for fun than anything else, I decided to look into setting up a micro instance in Amazon Web Services. One advantage to this is the fact that if you have a new account you can have a micro instance for a year for free. Anyway, I found a forum post here that does a great job of taking you through the process. I am going to copy the process here so that in the event that something happens to that site there will be a copy. I also made a few edits as there were a few steps missing from the original tutorial.

This guide assumes that you've already setup your AWS account and figured out how to set the security group. You will need to open some ports (TCP: 22, 1723, 5060. UDP: 5060, 10000-20000). On a side note, I understand that opening up these ports is a security risk, so you may want to look at using an AWS VPC or some other form of security to lock things down a little better. In my case, I don't really care about security since I'm using a throw away email and my endpoint is on a completely separate network.

Step 1. Goto: http://uec-images.ubuntu.com/releases/10.04/release/ and pick the t1.micro instance (ebs 64 bit) for the region that you setup in AWS. Launch this instance (there is a button) and get it working with the security group that you configured. After it's launched you need to setup an Elastic IP and associate it with the instance. After that go ahead and log into your new micro instance server. Once you get to this point, then you can continue with the guide. There are TONS of resources (including youtube videos) on how to get to this point. It's not rocket science.

Step 2. Setup firewall settings for asterisk. Lucid also has firewall settings that need to be adjusted.

#Uncomplicated Firewall
sudo ufw enable
sudo ufw allow 22/tcp
sudo ufw allow 1723/tcp
sudo ufw allow 5060/tcp
sudo ufw allow 5060/udp
sudo ufw allow 10000:20000/udp

#check status
sudo ufw status

#edit /etc/default/ufw and enable forward policy
DEFAULT_FORWARD_POLICY="ACCEPT"

#edit /etc/ufw/sysctl.conf and uncomment
net/ipv4/ip_forward=1

#edit /etc/ufw/before.rules and add this after the header comments

---<BEGIN>--- (DON'T COPY THIS LINE)
# nat Table rules
*nat
:POSTROUTING ACCEPT [0:0]

# Forward traffic through eth0.
-A POSTROUTING -o eth0 -j MASQUERADE

# don't delete the 'COMMIT' line or these nat table rules won't be processed
COMMIT
---<END>--- (DON'T COPY THIS LINE)

#disable and enable to apply changes
sudo ufw disable && sudo ufw enable

Step 3. Recompile Kernel. The default kernel is set at 100HZ timing, this will give you HORRIBLE VOIP quality. The kernel needs to be recompiled to 1000HZ timing.

# Make yourself root
sudo su

# Update source list:
aptitude update

# Upgrade everything:
aptitude upgrade 

# Install dependencies:
apt-get build-dep linux-image-$(uname -r)
apt-get build-dep linux
apt-get install fakeroot build-essential
apt-get install crash kexec-tools makedumpfile kernel-wedge
apt-get install libncurses5 libncurses5-dev
apt-get install libelf-dev asciidoc binutils-dev kernel-package
apt-get install git-core

cd /usr/src
git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git 
cd ubuntu*
git checkout --track -b ec2 origin/ec2
fakeroot debian/rules clean
fakeroot debian/rules editconfigs

# Configuration window should now appear, do the following:

Select YES

# Navigate to:
Processor type and features -> Timer frequency
# Select the 1000HZ frequency
Exit
Exit
Yes (Save)

#After saving and returning to prompt it may ask you to do it again for i386, select yes and repeat!

Step 4. This next command will take about 7 hours to recompile the kernel. But, there is a shortcut. Amazon charges by the minute for each instance type that you use. I recommend shutting down your instance at this point and changing it to a m1 extra large instance type (this will cost you about 70 cents). This will increase your micro instance from:

613 MiB memory
Up to 2 EC2 Compute Units (for short periodic bursts)
EBS storage only
32-bit or 64-bit platform
I/O Performance: Low
EBS-Optimized Available: No
API name: t1.micro

to:

15 GiB memory
8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each)
1,690 GB instance storage
64-bit platform
I/O Performance: High
EBS-Optimized Available: 1000 Mbps
API name: m1.xlarge

The compiling time will be reduced to about 25 minutes. Once you got the instance backup with the m1.xlarge instance, continue like so:

sudo su
cd /usr/src/ubuntu*
fakeroot debian/rules binary

#Check if your deb files were created
cd ..
ls *.deb

#install new kernel
#IF A GRUB MENU POPS UP PICK PACKAGE VERSION
sudo dpkg -i linux-*.deb

Then shutdown your system again and change it back to a micro instance. Then boot it back up.

#Check your new Kernel version
uname -r

#Check if Kernel HZ value change persisted:
cat /boot/config-`uname -r` | grep HZ

#If value 1000HZ=yes then you did it right!

Step 4a. Add missing dependencies. I ran into an issue with RTP not working following the guide provided, so I had to run the following command, which adds res_rtp_asterisk to the list of supported modules that you need to ensure is checked when you get to the Asterisk menu below.

apt-get install uuid-dev

Step 5. Install Asterisk 11

#get source. note: dahdi needs to be installed to compile and install libpri -- we don't really need it for any other reason

cd /usr/src/
wget http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/dahdi-linux-complete-current.tar.gz
wget http://downloads.asterisk.org/pub/telephony/libpri/libpri-1.4-current.tar.gz
wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-11-current.tar.gz

#extract source

tar zxvf dahdi-*
tar zxvf libpri-*
tar zxvf asterisk-11*

#resolve error for compiling dahdi

ln -nsf /usr/src/linux-headers-`uname -r`/include/asm-x86 /usr/src/linux-headers-`uname -r`/include/asm

#install dahdi

cd /usr/src/dahdi*
make && make install && make config

#install libpri

cd /usr/src/libpri-1.4*
make && make install

#install asterisk. note: once the menu pops up check and make sure you have chan_motif and xmpp (should have a * next to them)

cd /usr/src/asterisk*
./configure && make menuselect && make && make install && make config && make samples

Step 6. Configure Google Voice

#Backup original conf files (you should still be root)

cd /etc/asterisk
cp extensions.conf extensions.conf.orig
cp motif.conf motif.conf.orig
cp sip.conf sip.conf.orig
cp xmpp.conf xmpp.conf.orig

Now you will want to replace the following files with these (change USERNAME to whatever you want and make sure you google account info is correct):

#extensions.conf - Don't forget the USERNAME on the last line

[general]
autofallthrough=yes

; If an unauthenticated request some how gets through, send them to free 411.
[default]
exten => 411,1,Answer()
same => n,Dial(Motif/google/1800...@voice.google.com)

[local]
exten => _1XXXXXXXXXX,1,Dial(Motif/google/${EXTEN}@voice.google.com,,r)
exten => _XXXXXXXXXX,1,Dial(Motif/google/${EXTEN}@voice.google.com,,r)
exten => _+1XXXXXXXXXX,1,Dial(Motif/google/${EXTEN}@voice.google.com,,r)

[incoming-motif]
exten => s,1,NoOp()
 same => n,Set(crazygooglecid=${CALLERID(name)})
 same => n,Set(stripcrazysuffix=${CUT(crazygooglecid,@,1)})
 same => n,Set(CALLERID(all)=${stripcrazysuffix})
 same => n,Dial(SIP/USERNAME,20,D(:1))

#motif.conf

[google]
context=incoming-motif
disallow=all
allow=ulaw
connection=google

#sip.conf - Pay attention to externhost, secret, and USERNAME

[general]
allow=all
allowguest=no
nat=force_rport,comedia
tcpbindaddr=0.0.0.0
tcpenable=yes

externhost=ELASTICIP
localnet=10.0.0.0/8

[USERNAME]
type=peer
secret=PASSWORDYOUGENERATE
host=dynamic
context=local
transport=udp,tcp

#xmpp.conf

[general]
[google]
type=client
serverhost=talk.google.com
username=YOUREMAIL@GMAIL.COM
secret=GMAILPASSWORD
priority=100
port=5222
usetls=yes
usesasl=yes
status=available
statusmessage="VOIP"
timeout=5

# Stop/Start asterisk

sudo /etc/init.d/asterisk stop
sudo /etc/init.d/asterisk start

If everything went at planned your Asterisk Server with Google voice should be working, you can now login with your SIP client utilizing the extension username and password that you chose in sip.conf. In my case I used a SNOM 300 from our office. So far, I have been on business calls with it and have yet to have any call quality issues. Enjoy!

Thursday, June 13, 2013

How to De-brick a Buffalo WZR-600DHP

I use DD-WRT at my house because it offers a lot of advanced features on a cheap device. I purchased the Buffalo WZR-600DHP and originally loaded the Buffalo-branded DD-WRT version on it to keep things simple. One night I decided to move to a community build because Buffalo has not updated their version for over 6 months and I wanted to take advantage of new features. So, rather than flashing the device first and doing things the right way, I was lazy and just tried to upgrade via the GUI using one of builds found here:

ftp://ftp.dd-wrt.com/others/eko/BrainSlayer-V24-preSP2/2013/05-27-2013-r21676/buffalo_wzr-600dhp/

Of course the upgrade failed and bricked my unit. You should always follow the proper upgrade method. There are couple different modes that a Buffalo defaults to when it is bricked. In my case, the red diag light was blinking twice every few seconds. This means that either the flash failed or the image that was uploaded was corrupt.

Now, there are a ton of different posts on how to do this, but the reason that I am posting one myself is because none of them worked for me directly. I had to piece together multiple posts. Here are the steps that I followed (I did all these steps from OSX):

  1. Download the latest Buffalo firmware from the Buffalo website (not the DD-WRT flavor).
  2. In the FTP link above, you will find two different firmware flavors. Download the one that reads "buffalo_to_dd-wrt."
  3. Unplug the Buffalo router.
  4. Change the IP of your wired interface on your computer to 192.168.11.2, with a subnet mask of 255.255.255.0. You can leave the gateway blank. I always typically do this because it allows access to the Internet via the wireless interface while still allowing wired access to the device you need to configure.
    1. NOTE: Regardless of what subnet you had configured for your router previously, 192.168.11.1 is the bootloader TFTP server address. You must set your computer to 192.168.11.2, as that is the required TFTP client IP address.
  5. Get any 10/100 or 10/100/1000 capable switch and turn it on.
  6. Plug you computer into any port on the switch.
  7. Plug the router into any other port on the switch, but don't power it on just yet.
  8. Open your terminal and type sudo arp -s 192.168.11.1 02:AA:BB:CC:DD:20
    1. NOTE: On many other posts it specifies to use the MAC address of the router (its the OUI followed by the characters listed on the SSIDs that are on the sticker on the router). However, I was only able to recover mine by using the bootloader MAC address as shown above. This is the special MAC address used during the booting process.
  9. While still in the terminal, navigate to the directory where the firmware you downloaded in step 1 resides.
  10. Type tftp 192.168.11.1 put wzr600dhp-191 and DO NOT hit enter.
  11. Power on the router, then hit enter to send the command shown above in step 9.
  12. In about 10 seconds, the red diag light will start to blink rapidly which means that the router is receiving the new image. You should also see a response in your terminal specifying whether or not the upgrade was successful.
  13. Let it install the image for about 10 minutes.
  14. Once completed, you will be able to access the GUI via the 192.168.11.1 address.
  15. Perform a 30/30/30 reset (if you need assistance on how to do this, see the DD-WRT wiki on their website).
  16. From the GUI, install the firmware you just downloaded and allowed the device to reboot.
  17. Perform another 30/30/30/ reset and enjoy!

Saturday, April 27, 2013

VPN Between a SonicWALL TZ210 and a Juniper SRX100

I have seen multiple people in forums asking how to setup a site to site VPN between a Juniper SRX firewall and a SonicWALL firewall. Below are the steps that I took to get it working, and is based on the following topology:



First we will configure the SRX:

Configure Interfaces:

set interfaces fe-0/0/0 unit 0 family inet address 10.10.10.2/30
set interfaces fe-0/0/1 unit 0 family inet address 192.168.1.1/24

Configure Routing:

set routing-options static route 0.0.0.0/0 next-hop 10.10.10.1/30

Configure VPN Parameters:

NOTE: For this specific instance, one of the firewalls is using a dynamic public IP address for its WAN interface, thus the aggressive mode.

set security ike proposal SRX-TO-SW authentication-method pre-shared-keys
set security ike proposal SRX-TO-SW dh-group group2
set security ike proposal SRX-TO-SW authentication-algorithm sha1
set security ike proposal SRX-TO-SW encryption-algorithm aes-256-cbc
set security ike proposal SRX-TO-SW lifetime-seconds 28800

set security ike policy SRX-TO-SW mode aggressive
set security ike policy SRX-TO-SW proposals SRX-TO-SW
set security ike policy SRX-TO-SW pre-shared-key ascii-text thisismypsk

set security ike gateway SRX-TO-SW ike-policy SRX-TO-SW
set security ike gateway SRX-TO-SW address 11.11.11.2
set security ike gateway SRX-TO-SW external-interface fe-0/0/0.0

set security ipsec proposal SRX-TO-SW protocol esp
set security ipsec proposal SRX-TO-SW authentication-algorithm hmac-sha1-96
set security ipsec proposal SRX-TO-SW encryption-algorithm aes-256-cbc
set security ipsec proposal SRX-TO-SW lifetime-seconds 28800

set security ipsec policy SRX-TO-SW proposals SRX-TO-SW

set security ipsec vpn SRX-TO-SW ike gateway SRX-TO-SW
set security ipsec vpn SRX-TO-SW ike ipsec-policy SRX-TO-SW

set security flow tcp-mss ipsec-vpn mss 1350

Configure Security Zones:

set security zones security-zone UNTRUST interfaces fe-0/0/0.0
set security zones security-zone UNTRUST host-inbound-traffic system-services ike
set security zones security-zone UNTRUST address-book address SW-NET 172.16.1.0/24
set security zones security-zone TRUST interfaces fe-0/0/1.0
set security zones security-zone TRUST host-inbound-traffic system-services all
set security zones security-zone TRUST address-book address SRX-NET 192.168.1.0/24

Configure Security Policies:

set security policies from-zone TRUST to-zone UNTRUST policy SRX-TO-SW match source-address SRX-NET
set security policies from-zone TRUST to-zone UNTRUST policy SRX-TO-SW match destination-address SW-NET
set security policies from-zone TRUST to-zone UNTRUST policy SRX-TO-SW match application any
set security policies from-zone TRUST to-zone UNTRUST policy SRX-TO-SW then permit tunnel ipsec-vpn SRX-TO-SW
set security policies from-zone TRUST to-zone UNTRUST policy SRX-TO-SW then permit tunnel pair-policy SW-TO-SRX

set security policies from-zone TRUST to-zone UNTRUST policy TRUST-TO-UNTRUST match source-address any
set security policies from-zone TRUST to-zone UNTRUST policy TRUST-TO-UNTRUST match destination-address any
set security policies from-zone TRUST to-zone UNTRUST policy TRUST-TO-UNTRUST match application any
set security policies from-zone TRUST to-zone UNTRUST policy TRUST-TO-UNTRUST then permit

set security policies from-zone UNTRUST to-zone TRUST policy SW-TO-SRX match source-address SW-NET
set security policies from-zone UNTRUST to-zone TRUST policy SW-TO-SRX match destination-address SRX-NET
set security policies from-zone UNTRUST to-zone TRUST policy SW-TO-SRX match application any
set security policies from-zone UNTRUST to-zone TRUST policy SW-TO-SRX then permit tunnel ipsec-vpn SW-TO-SRX
set security policies from-zone UNTRUST to-zone TRUST policy SW-TO-SRX then permit tunnel pair-policy SRX-TO-SW

Configure NAT:

set security nat source rule-set TRUST-TO-UNTRUST from zone TRUST
set security nat source rule-set TRUST-TO-UNTRUST to zone UNTRUST
set security nat source rule-set TRUST-TO-UNTRUST rule SRC-NAT match source-address 192.168.1.0/24
set security nat source rule-set TRUST-TO-UNTRUST rule SRC-NAT then source-nat interface

Next we will configure the TZ:

Enable and add a VPN:

Navigate to VPN->Settings, and then check the box to enable VPN and then click Accept.















Add a new VPN by selecting Add... under VPN Policies on the same page. Enter parameters as shown in the subsequent screenshots for each tab, and then click OK.





































That's really it. You can then enable or disable the VPN on the SonicWALL at any time via a checkbox next to the newly created VPN on the VPN->Settings page. 

Monitoring the Tunnel:

On the TZ:

You can verify tunnel status by going to VPN->Settings, and looking under Currently Active VPN Tunnels

On the SRX:

To verify Phase1 is complete, from operational mode issue the following command:

show security ike security-associations

To verify Phase 2 is complete, from operational mode issue the following command:

show security ipsec security-associations






Thursday, February 14, 2013

Juniper SRX VPN Monitor and Route Failover

Recently I ran into a scenario where I was presented with the following network topology:


As you can see (from left to right), there is 1 SRX 240 acting as the core firewall, 1 core EX4200 switch, 2 SRX 240's acting as next hops, both of which have VPN connections terminated to them from another SRX 240 at a remote site. The VPN connections are traversing an MPLS backbone which does not consist of Juniper gear, nor will it be discussed in this post. Our concern is regarding the fact that there are two possible paths (dual VPNs) between the core and the remote SRX.

In this scenario, lets assume we want to use static routing, but also allow for route failover in the event of a VPN outage.

There are multiple options that we can utilize to provide route failover in this type of scenario. Some of these options include:
I went with VPN Monitoring due to the fact that we are using VPNs. If this scenario didn't include VPNs, then I would've went with BFD or RPM and IP Monitoring. Here is what our configurations will look like:

Core SRX Configuration (10.0.0.1):

Configure the interface that will connect to the core switch:
set interfaces ge-0/0/0 unit 0 description "*** CORE ***"
set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/24

Configure a route for the remote site:
set routing-options static route 10.0.99.0/24 next-hop 10.0.0.2

Core EX Configuration (10.0.0.5):

Configure the Routed VLAN Interface:
set interfaces vlan unit 0 description "*** CORE ***"
set interfaces vlan unit 0 family inet address 10.0.0.5/24
set vlans CORE vlan-id 3
set vlans CORE l3-interface vlan.0

Configure the interfaces on the switch:
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members CORE
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members CORE
set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members CORE
etc...

VPN1 SRX Configuration (10.0.0.2):

Configure the Routed VLAN Interface:
set interfaces vlan unit 0 description "*** CORE ***"
set interfaces vlan unit 0 family inet address 10.0.0.2/24
set vlans CORE vlan-id 3
set vlans CORE l3-interface vlan.0

Configure the interfaces that will connect to the core switch:
set interfaces ge-0/0/13 unit 0 family ethernet-switching vlan members CORE
set interfaces ge-0/0/14 unit 0 family ethernet-switching vlan members CORE

Configure the interface that will act as the WAN interface for our MPLS connection:
set interfaces ge-0/0/15 unit 0 description "*** MPLS CONNECTION TO REMOTE SITE ***"
set interfaces ge-0/0/15 unit 0 family inet address 1.1.1.1/30

Configure the interface that will be used for the VPN:
set interfaces st0 unit 1 description "*** CONNECTION TO REMOTE SITE ***"
set interfaces st0 unit 1 family inet address 100.100.100.1/30

Configure a default route:
set routing-options static route 0.0.0.0/0 next-hop 10.0.0.1

Configure a preferred route to the remote site via 10.0.0.2, and then a backup route via 10.0.0.3:
set routing-options static route 10.0.99.0/24 next-hop st0.1
set routing-options static route 10.0.99.0/24 qualified-next-hop 10.0.0.3 preference 6

Configure the route-based VPN:
set security ike policy IKE-POLICY-REMOTE-SITE mode main
set security ike policy IKE-POLICY-REMOTE-SITE proposal-set standard
set security ike policy IKE-POLICY-REMOTE-SITE pre-shared-key ascii-text testing123
set security ike gateway GW-REMOTE-SITE ike-policy IKE-POLICY-REMOTE-SITE
set security ike gateway GW-REMOTE-SITE address 1.1.1.2
set security ike gateway GW-REMOTE-SITE external-interface ge-0/0/15.0
set security ipsec policy IPSEC-POLICY-REMOTE-SITE perfect-forward-secrecy keys group2
set security ipsec policy IPSEC-POLICY-REMOTE-SITE proposal-set standard
set security ipsec vpn VPN-REMOTE-SITE bind-interface st0.1
set security ipsec vpn VPN-REMOTE-SITE ike gateway GW-REMOTE-SITE
set security ipsec vpn VPN-REMOTE-SITE ike ipsec-policy 

VPN-REMOTE-SITE
set security ipsec vpn VPN-REMOTE-SITE establish-tunnels immediately
set security flow tcp-mss ipsec-vpn mss 1350

Configure VPN monitoring:
set security ipsec vpn-monitor-options interval 2
set security ipsec vpn-monitor-options threshold 10
set security ipsec vpn VPN-REMOTE-SITE vpn-monitor optimized
set security ipsec vpn VPN-REMOTE-SITE vpn-monitor source-interface ge-0/0/15.0
set security ipsec vpn VPN-REMOTE-SITE vpn-monitor destination-ip 1.1.1.2

Create security zones and policies:

NOTE: For testing purposes, I opened up everything to my zones and policies. I always start this way so as to make things easier on myself. It is more effective to get what you want working first and then go back and secure things as needed (granted this is in a lab environment).

set security zones security-zone CORE host-inbound-traffic system-services all
set security zones security-zone CORE host-inbound-traffic protocols all
set security zones security-zone CORE interfaces vlan.0
set security zones security-zone MPLS host-inbound-traffic system-services all
set security zones security-zone MPLS host-inbound-traffic protocols all
set security zones security-zone MPLS interfaces ge-0/0/15.0
set security zones security-zone VPN host-inbound-traffic system-services all
set security zones security-zone VPN host-inbound-traffic protocols all
set security zones security-zone VPN interfaces st0.1

[edit security policies]
set  from-zone CORE to-zone VPN policy CORE-TO-VPN match source-address any
set  from-zone CORE to-zone VPN policy CORE-TO-VPN match destination-address any
set  from-zone CORE to-zone VPN policy CORE-TO-VPN match application any
set  from-zone CORE to-zone VPN policy CORE-TO-VPN then permit
set  from-zone VPN to-zone CORE policy VPN-TO-CORE match source-address any
set  from-zone VPN to-zone CORE policy VPN-TO-CORE match destination-address any
set  from-zone VPN to-zone CORE policy VPN-TO-CORE match application any
set  from-zone VPN to-zone CORE policy VPN-TO-CORE then permit
set  from-zone VPN to-zone VPN policy VPN-TO-VPN match source-address any
set  from-zone VPN to-zone VPN policy VPN-TO-VPN match destination-address any
set  from-zone VPN to-zone VPN policy VPN-TO-VPN match application any
set  from-zone VPN to-zone VPN policy VPN-TO-VPN then permit
set  from-zone CORE to-zone MPLS policy CORE-TO-MPLS match source-address any
set  from-zone CORE to-zone MPLS policy CORE-TO-MPLS match destination-address any
set  from-zone CORE to-zone MPLS policy CORE-TO-MPLS match application any
set  from-zone CORE to-zone MPLS policy CORE-TO-MPLS then permit
set  from-zone MPLS to-zone CORE policy MPLS-TO-CORE match source-address any
set  from-zone MPLS to-zone CORE policy MPLS-TO-CORE match destination-address any
set  from-zone MPLS to-zone CORE policy MPLS-TO-CORE match application any
set  from-zone MPLS to-zone CORE policy MPLS-TO-CORE then permit
set  from-zone VPN to-zone MPLS policy VPN-TO-MPLS match source-address any
set  from-zone VPN to-zone MPLS policy VPN-TO-MPLS match destination-address any
set  from-zone VPN to-zone MPLS policy VPN-TO-MPLS match application any
set  from-zone VPN to-zone MPLS policy VPN-TO-MPLS then permit
set  from-zone MPLS to-zone VPN policy MPLS-TO-VPN match source-address any
set  from-zone MPLS to-zone VPN policy MPLS-TO-VPN match destination-address any
set  from-zone MPLS to-zone VPN policy MPLS-TO-VPN match application any
set  from-zone MPLS to-zone VPN policy MPLS-TO-VPN then permit
set  from-zone CORE to-zone CORE policy CORE-TO-CORE match source-address any
set  from-zone CORE to-zone CORE policy CORE-TO-CORE match destination-address any
set  from-zone CORE to-zone CORE policy CORE-TO-CORE match application any
set  from-zone CORE to-zone CORE policy CORE-TO-CORE then permit

Configure a firewall filter so that VPN1 SRX only accepts IKE packets from specific devices:

NOTE: This can also be done with policy. When I was testing failover and simulating a down tunnel, I noticed that my VPN connection would attempt to renegotiate over my second VPN at the remote site. I simply set a firewall filter to ensure that this SRX only accepts IKE packets from the MPLS zone IP of the remote site.

set firewall family inet filter REJECT-IKE term T1 from source-address 0.0.0.0/0
set firewall family inet filter REJECT-IKE term T1 from source-address 1.1.1.2/32 except
set firewall family inet filter REJECT-IKE term T1 from protocol udp
set firewall family inet filter REJECT-IKE term T1 from destination-port 500
set firewall family inet filter REJECT-IKE term T1 then reject
set firewall family inet filter REJECT-IKE term T2 then accept
set interfaces lo0 unit 0 family inet filter input REJECT-IKE

VPN2 SRX Configuration (10.0.0.3):

Configure the Routed VLAN Interface:
set interfaces vlan unit 0 description "*** CORE ***"
set interfaces vlan unit 0 family inet address 10.0.0.3/24
set vlans CORE vlan-id 3
set vlans CORE l3-interface vlan.0


Configure the interfaces that will connect to the core switch:
set interfaces ge-0/0/13 unit 0 family ethernet-switching vlan members CORE
set interfaces ge-0/0/14 unit 0 family ethernet-switching vlan members CORE

Configure the interface that will act as the WAN interface for our MPLS connection:
set interfaces ge-0/0/15 unit 0 description "*** MPLS CONNECTION TO REMOTE SRX ***"
set interfaces ge-0/0/15 unit 0 family inet address 2.2.2.1/30


Configure the interface that will be used for the VPN:
set interfaces st0 unit 1 description "*** CONNECTION TO REMOTE SITE ***"
set interfaces st0 unit 1 family inet address 200.200.200.1/30


Configure a default route:
set routing-options static route 0.0.0.0/0 next-hop 10.0.0.1

Configure a route to the remote site:
set routing-options static route 10.0.99.0/24 next-hop 200.200.200.2


Configure the route-based VPN:
set security ike policy IKE-POLICY-REMOTE-SITE mode main
set security ike policy IKE-POLICY-REMOTE-SITE proposal-set standard
set security ike policy IKE-POLICY-REMOTE-SITE pre-shared-key ascii-text testing123
set security ike gateway GW-REMOTE-SITE ike-policy IKE-POLICY-REMOTE-SITE
set security ike gateway GW-REMOTE-SITE address 2.2.2.2
set security ike gateway GW-REMOTE-SITE external-interface ge-0/0/15.0
set security ipsec policy IPSEC-POLICY-REMOTE-SITE perfect-forward-secrecy keys group2
set security ipsec policy IPSEC-POLICY-REMOTE-SITE proposal-set standard
set security ipsec vpn VPN-REMOTE-SITE bind-interface st0.1
set security ipsec vpn VPN-REMOTE-SITE ike gateway GW-REMOTE-SITE
set security ipsec vpn VPN-REMOTE-SITE ike ipsec-policy VPN-REMOTE-SITE
set security ipsec vpn VPN-REMOTE-SITE establish-tunnels immediately
set security flow tcp-mss ipsec-vpn mss 1350

NOTE: There is no need to enable VPN monitoring on this device, as we only need to be monitoring our primary path to/from the remote site. Also, I configured the security zones and policies exactly like VPN1 SRX.

Configure a firewall filter so that VPN1 SRX only accepts IKE packets from specific devices:
set firewall family inet filter REJECT-IKE term T1 from source-address 0.0.0.0/0
set firewall family inet filter REJECT-IKE term T1 from source-address 2.2.2.2/32 except
set firewall family inet filter REJECT-IKE term T1 from protocol udp
set firewall family inet filter REJECT-IKE term T1 from destination-port 500
set firewall family inet filter REJECT-IKE term T1 then reject
set firewall family inet filter REJECT-IKE term T2 then accept
set interfaces lo0 unit 0 family inet filter input REJECT-IKE

Remote SRX Configuration (10.0.99.1):

Configure the Routed VLAN Interface:
set interfaces vlan unit 0 description "*** TRUST ***"
set interfaces vlan unit 0 family inet address 10.0.99.1/24
set vlans TRUST vlan-id 3
set vlans TRUST l3-interface vlan.0


Configure the interface that will act as the WAN interface for our MPLS connections:
set interfaces ge-0/0/0 unit 10 description "*** MPLS CONNECTION TO VPN1 SRX ***"
set interfaces ge-0/0/0 unit 10 family inet address 1.1.1.2/30
set interfaces ge-0/0/0 unit 20 description "*** MPLS CONNECTION TO VPN2 SRX ***"
set interfaces ge-0/0/0 unit 20 family inet address 2.2.2.2/30

Configure the interfaces that will be used for the VPN:
set interfaces st0 unit 1 description "*** CONNECTION TO VPN1 SRX ***"
set interfaces st0 unit 1 family inet address 100.100.100.2/30
set interfaces st0 unit 2 description "*** CONNECTION TO VPN2 SRX ***"
set interfaces st0 unit 2 family inet address 200.200.200.2/30

Configure a preferred route to the core via 10.0.0.2, and then a backup route via 10.0.0.3:
set routing-options static route 0.0.0.0/0 next-hop st0.1
set routing-options static route 0.0.0.0/0 qualified-next-hop st0.2 preference 6

Configure the route-based VPNs:
set security ike policy IKE-POLICY-TO-VPN1 mode main
set security ike policy IKE-POLICY-TO-VPN1 proposal-set standard
set security ike policy IKE-POLICY-TO-VPN1 pre-shared-key ascii-text testing123
set security ike policy IKE-POLICY-TO-VPN2 mode main
set security ike policy IKE-POLICY-TO-VPN2 proposal-set standard
set security ike policy IKE-POLICY-TO-VPN2 pre-shared-key ascii-text testing123
set security ike gateway GW-TO-VPN1 ike-policy IKE-POLICY-TO-VPN1
set security ike gateway GW-TO-VPN1 address 1.1.1.1
set security ike gateway GW-TO-VPN1 external-interface ge-0/0/0.10
set security ike gateway GW-TO-VPN2 ike-policy IKE-POLICY-TO-VPN2
set security ike gateway GW-TO-VPN2 address 2.2.2.1
set security ike gateway GW-TO-VPN2 external-interface ge-0/0/0.20
set security ipsec policy IPSEC-POLICY-TO-VPN1 perfect-forward-secrecy keys group2
set security ipsec policy IPSEC-POLICY-TO-VPN1 proposal-set standard
set security ipsec policy IPSEC-POLICY-TO-VPN2 perfect-forward-secrecy keys group2
set security ipsec policy IPSEC-POLICY-TO-VPN2 proposal-set standard
set security ipsec vpn VPN-TO-VPN1 bind-interface st0.1
set security ipsec vpn VPN-TO-VPN1 ike gateway GW-TO-VPN1
set security ipsec vpn VPN-TO-VPN1 ike ipsec-policy IPSEC-POLICY-TO-VPN1
set security ipsec vpn VPN-TO-VPN1 establish-tunnels immediately
set security ipsec vpn VPN-TO-VPN2 bind-interface st0.2
set security ipsec vpn VPN-TO-VPN2 ike gateway GW-TO-VPN2
set security ipsec vpn VPN-TO-VPN2 ike ipsec-policy IPSEC-POLICY-TO-VPN2
set security ipsec vpn VPN-TO-VPN2 establish-tunnels immediately
set security flow tcp-mss ipsec-vpn mss 1350

Configure VPN monitoring for the VPN to VPN1 SRX:
set security ipsec vpn-monitor-options interval 2
set security ipsec vpn-monitor-options threshold 10
set security ipsec vpn VPN-TO-VPN1 vpn-monitor optimized
set security ipsec vpn VPN-TO-VPN1 vpn-monitor source-interface ge-0/0/0.10
set security ipsec vpn VPN-TO-VPN1 vpn-monitor destination-ip 1.1.1.1

Create security zones and policies:
set security zones security-zone TRUST host-inbound-traffic system-services all
set security zones security-zone TRUST host-inbound-traffic protocols all
set security zones security-zone TRUST interfaces vlan.0
set security zones security-zone MPLS host-inbound-traffic system-services all
set security zones security-zone MPLS host-inbound-traffic protocols all
set security zones security-zone MPLS interfaces ge-0/0/0.10
set security zones security-zone MPLS interfaces ge-0/0/0.20
set security zones security-zone VPN host-inbound-traffic system-services all
set security zones security-zone VPN host-inbound-traffic protocols all
set security zones security-zone VPN interfaces st0.1
set security zones security-zone VPN interfaces st0.2

[edit security policies]
set  from-zone TRUST to-zone VPN policy TRUST-TO-VPN match destination-address any
set  from-zone TRUST to-zone VPN policy TRUST-TO-VPN match application any
set  from-zone TRUST to-zone VPN policy TRUST-TO-VPN then permit
set  from-zone VPN to-zone TRUST policy VPN-TO-TRUST match source-address any
set  from-zone VPN to-zone TRUST policy VPN-TO-TRUST match destination-address any
set  from-zone VPN to-zone TRUST policy VPN-TO-TRUST match application any
set  from-zone VPN to-zone TRUST policy VPN-TO-TRUST then permit
set  from-zone VPN to-zone VPN policy VPN-TO-VPN match source-address any
set  from-zone VPN to-zone VPN policy VPN-TO-VPN match destination-address any
set  from-zone VPN to-zone VPN policy VPN-TO-VPN match application any
set  from-zone VPN to-zone VPN policy VPN-TO-VPN then permit
set  from-zone TRUST to-zone MPLS policy TRUST-TO-MPLS match source-address any
set  from-zone TRUST to-zone MPLS policy TRUST-TO-MPLS match destination-address any
set  from-zone TRUST to-zone MPLS policy TRUST-TO-MPLS match application any
set  from-zone TRUST to-zone MPLS policy TRUST-TO-MPLS then permit
set  from-zone MPLS to-zone TRUST policy MPLS-TO-TRUST match source-address any
set  from-zone MPLS to-zone TRUST policy MPLS-TO-TRUST match destination-address any
set  from-zone MPLS to-zone TRUST policy MPLS-TO-TRUST match application any
set  from-zone MPLS to-zone TRUST policy MPLS-TO-TRUST then permit
set  from-zone VPN to-zone MPLS policy VPN-TO-MPLS match source-address any
set  from-zone VPN to-zone MPLS policy VPN-TO-MPLS match destination-address any
set  from-zone VPN to-zone MPLS policy VPN-TO-MPLS match application any
set  from-zone VPN to-zone MPLS policy VPN-TO-MPLS then permit
set  from-zone MPLS to-zone VPN policy MPLS-TO-VPN match source-address any
set  from-zone MPLS to-zone VPN policy MPLS-TO-VPN match destination-address any
set  from-zone MPLS to-zone VPN policy MPLS-TO-VPN match application any
set  from-zone MPLS to-zone VPN policy MPLS-TO-VPN then permit
set  from-zone TRUST to-zone TRUST policy TRUST-TO-TRUST match source-address any
set  from-zone TRUST to-zone TRUST policy TRUST-TO-TRUST match destination-address any
set  from-zone TRUST to-zone TRUST policy TRUST-TO-TRUST match application any
set  from-zone TRUST to-zone TRUST policy TRUST-TO-TRUST then permit

Testing and Validation:

We can test and validate our design by issuing the following command at the remote site:
set interfaces ge-0/0/0.10 disable
commit confirmed 5

By issuing commit confirmed 5, we are committing the configuration for a total of 5 minutes, and then allowing it to roll back to how it was before we disabled the interface. Make sure to disable the interface and NOT deactivate the interface. Deactivating is the equivalent of removing it from the configuration and should not be used to test failover.

Traceroute prior to disabling the interface:
traceroute to 10.0.99.1 (10.0.99.1), 64 hops max, 52 byte packets
 1  10.0.0.1 (10.0.0.1)  4.093 ms  4.044 ms  5.812 ms
 2  10.0.0.2 (10.0.0.2)  4.219 ms  4.543 ms  4.456 ms
 3  10.0.99.1 (10.0.99.1)  7.260 ms  6.652 ms  6.949 ms

Continuous ping during failover:
PING 10.0.99.1 (10.0.99.1): 56 data bytes
64 bytes from 10.0.99.1: icmp_seq=0 ttl=61 time=9.161 ms
64 bytes from 10.0.99.1: icmp_seq=1 ttl=61 time=8.943 ms
64 bytes from 10.0.99.1: icmp_seq=2 ttl=61 time=8.779 ms
64 bytes from 10.0.99.1: icmp_seq=3 ttl=61 time=8.885 ms
64 bytes from 10.0.99.1: icmp_seq=4 ttl=61 time=8.730 ms
64 bytes from 10.0.99.1: icmp_seq=5 ttl=61 time=8.648 ms
64 bytes from 10.0.99.1: icmp_seq=6 ttl=61 time=6.584 ms
64 bytes from 10.0.99.1: icmp_seq=7 ttl=61 time=9.076 ms
64 bytes from 10.0.99.1: icmp_seq=8 ttl=61 time=6.396 ms
64 bytes from 10.0.99.1: icmp_seq=9 ttl=61 time=8.971 ms
64 bytes from 10.0.99.1: icmp_seq=10 ttl=61 time=9.061 ms
64 bytes from 10.0.99.1: icmp_seq=11 ttl=61 time=9.226 ms
64 bytes from 10.0.99.1: icmp_seq=12 ttl=61 time=9.581 ms
64 bytes from 10.0.99.1: icmp_seq=13 ttl=61 time=8.922 ms
64 bytes from 10.0.99.1: icmp_seq=14 ttl=61 time=8.447 ms
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
Request timeout for icmp_seq 23
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
Request timeout for icmp_seq 26
Request timeout for icmp_seq 27
Request timeout for icmp_seq 28
Request timeout for icmp_seq 29
Request timeout for icmp_seq 30
Request timeout for icmp_seq 31
Request timeout for icmp_seq 32
Request timeout for icmp_seq 33
Request timeout for icmp_seq 34
Request timeout for icmp_seq 35
Request timeout for icmp_seq 36
64 bytes from 10.0.99.1: icmp_seq=37 ttl=61 time=7.194 ms
64 bytes from 10.0.99.1: icmp_seq=38 ttl=61 time=9.577 ms
64 bytes from 10.0.99.1: icmp_seq=39 ttl=61 time=9.314 ms
64 bytes from 10.0.99.1: icmp_seq=40 ttl=61 time=9.300 ms
64 bytes from 10.0.99.1: icmp_seq=41 ttl=61 time=9.399 ms
64 bytes from 10.0.99.1: icmp_seq=42 ttl=61 time=9.414 ms
64 bytes from 10.0.99.1: icmp_seq=43 ttl=61 time=11.261 ms
64 bytes from 10.0.99.1: icmp_seq=44 ttl=61 time=9.284 ms
64 bytes from 10.0.99.1: icmp_seq=45 ttl=61 time=6.125 ms

Traceroute after failover:
traceroute to 10.0.99.1 (10.0.99.1), 64 hops max, 52 byte packets
 1  10.0.0.1 (10.0.0.1)  4.055 ms  4.495 ms  4.185 ms
 2  10.0.0.2 (10.0.0.2)  4.466 ms  4.745 ms  4.257 ms
 3  10.0.0.3 (10.0.0.3)  4.732 ms  4.510 ms  4.490 ms
 4  10.0.99.1 (10.0.99.1)  13.306 ms  6.384 ms  5.940 ms

As you can see, with failover in effect, the new route traverses our backup route to the remote site. Enjoy!

Juniper Static Route Failover

In this scenario, we are doing static routing, but we want the capability to provide fast failover in the event of an outage. We can use Bi-directional Forwarding Detection, but this requires it to be set up on both ends. Let's assume for this exercise that BFD is not an option for our neighbor routers.


As you can see (from left to right), we have one core Juniper router (10.0.0.1) and 2 next hops. Lets pretend that these next hops are both ISPs that we want in place for business continuity in the event that one ISP should experience an outage.

Core Juniper Router Configuration:

Configure a static route:
set routing-options static route 0.0.0.0/0 next-hop 10.0.0.2

Configure Real-time Performance Monitoring:
set services rpm probe ROUTE1 test ROUTE1 target address 10.0.0.2
set services rpm probe ROUTE1 test ROUTE1 probe-count 3
set services rpm probe ROUTE1 test ROUTE1 probe-interval 15
set services rpm probe ROUTE1 test ROUTE1 test-interval 10
set services rpm probe ROUTE1 test ROUTE1 thresholds successive-loss 3
set services rpm probe ROUTE1 test ROUTE1 thresholds total-loss 3
set services rpm probe ROUTE1 test ROUTE1 next-hop 10.0.0.2

Configure IP Monitoring:
set services ip-monitoring policy ROUTE1 match rpm-probe ROUTE1
set services ip-monitoring policy ROUTE1 then preferred-route route 0.0.0.0/0 next-hop 10.0.0.3

With the above configuration, we are telling our router to monitor the connection to our next hop. Should our performance monitoring metrics fail, then our policy that we create under the services ip-monitoring hierarchy will be applied.

We can verify that RPM is running properly by issuing the following command from operational mode:
show services rpm history-results


Owner, Test                 Probe received                          Round trip time
ROUTE1, ROUTE1    Wed Feb  6 01:26:34 2013       1461 usec
ROUTE1, ROUTE1    Wed Feb  6 01:26:49 2013       1477 usec

ROUTE1, ROUTE1    Wed Feb  6 01:27:04 2013       7215 usec

ROUTE1, ROUTE1    Wed Feb  6 01:27:14 2013       1420 usec


We can verify whether or not our IP monitoring policy has been applied by issuing the following command from operational mode:
show services ip-monitoring status


Policy - ROUTE1
  RPM Probes:
    Probe name             Address          Status   
    ---------------------- ---------------- ---------
    ROUTE1                 10.0.0.2       PASS     
  Route-Action:
    route-instance    route             next-hop         State
    ----------------- ----------------- ---------------- ------------- 
    inet.0               0.0.0.0           10.0.0.3     NOT-APPLIED

Enjoy!

How to Verify TCP Traffic on EX Switches

On EX Series switches, you can configure firewall filters to monitor traffic between 2 devices. Let's pretend there are 2 devices (1 server and 1 PC) connected to our EX4200 switch, and we want to verify that traffic is passing from the PC to Server.

Configure a firewall filter for the server and apply it to the port that the server is plugged into:

set firewall family ethernet-switching filter F1 term T1 from source-address 1.1.1.1/32
set firewall family ethernet-switching filter F1 term T1 from destination-address 2.2.2.2/32
set firewall family ethernet-switching filter F1 term T1 from protocol tcp
set firewall family ethernet-switching filter F1 term T1 from tcp-flags "syn&ack"
set firewall family ethernet-switching filter F1 term T1 then count ack-count
set firewall family ethernet-switching filter F1 term T2 then accept
set interfaces ge-0/0/5 unit 0 family ethernet-switching filter input F1

Configure a firewall filter for the server and apply it to the port that the PC is plugged into:

set firewall family ethernet-switching filter F2 term T1 from source-address 1.1.1.1/32
set firewall family ethernet-switching filter F2 term T1 from destination-address 2.2.2.2/32
set firewall family ethernet-switching filter F2 term T1 from protocol tcp
set firewall family ethernet-switching filter F2 term T1 from tcp-flags "syn&ack"
set firewall family ethernet-switching filter F2 term T1 then count ack-count
set firewall family ethernet-switching filter F2 term T2 then accept
set interfaces ge-0/0/22 unit 0 family ethernet-switching filter output F2

We can then run a ping from the PC to the server and verify whether or not traffic is traversing the ports we are monitoring.

show firewall:

Filter: F1                                                  
Counters:
Name                                                Bytes              Packets
ack-count                                            2310                   33

Filter: egress                                              
Counters:
Name                                                Bytes              Packets
ack-count                                            2310                   33

Enjoy!

Wednesday, February 6, 2013

Fun Juniper Command

Next time you are on a Junos device, run the command show version and haiku from operational mode for a funny output. Here's an example:


root@TEST-SRX> show version and haiku 
Hostname: TEST-SRX
Model: srx100h
JUNOS Software Release [11.4R5.5]


        IS-IS sleeps.
        BGP peers are quiet.
        Something must be wrong.

root@TEST-SRX>

Wednesday, January 30, 2013

ShoreTel and Third-Party Paging

I recently ran into an issue when I was installing a new ShoreTel Phone System. The customer failed to mention that they were expecting the ShoreTel System to be tied into their existing Valcom paging system (that's always awesome...). Here is what we did to get it working:
  1. Log into ShoreWare Director in "Support Mode"
    1. Hold down ctrl+shift and click on User Name. You will see "Support Entry" in red underneath the login area.
  2. Create an Analog Loop-start Trunk and name it Paging. Although no fields are actually needed, it will require you to enter an access code and local area code in order to save it.
    1. In my case, the Valcom Paging System was assigned an extension of 451 (unfortunately, getting this to work will require you to get some information from the customer. In other words, the extension number used by the paging system). We need to duplicate this extension number as an Off System Extension (451-451) at the bottom of the page.
    2. Add the string ;1G;1I to the custom string field. The first three characters tell the system to wait 1 second after going off hook and presume a connection even if a dial tone is not heard. The second three characters tell the system not to outpulse the off system extension after the trunk is seized.
  3. In director, navigate to the switch that has an open analog port on it that you will connect to the paging system. Set the type as trunk, and then add the Paging trunk that you created.
That's really it. For each user, I created a custom speed dial button that calls 451. Once they hit the custom button, they can then hit any number to send DTMF and it will beep, allowing the page to be made.