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.

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!

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!

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

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:

• Bi-directional Forwarding Detection
• Real-time Network Performance with IP Monitoring
• VPN Monitoring

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!

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>

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.

Upgrading a Juniper SRX Cluster

Upgrading branch SRX's is a quite simple process. However, the steps get a little more convoluted when you need to upgrade a cluster. The steps below have been tested on an SRX 240 cluster running Junos 11.4R5.5. Node 0 is the primary node, and Node 1 is the secondary node.

1. Ensure that the system time is synchronized, as this has been known to cause issues:
1. node0> show system uptime
2. If time is off you can configure time for both nodes via one of the following methods:
1. node0> set date 201210172200.00
2. node0> set date ntp 0.north-america.pool.ntp.org 
3. From configuration mode on the primary node, issue the following commands:
1. node0# set system services ftp
2. node0# set system login user ftp-user class super-user uid 2001 authentication plain-text-password
1. enter a password twice as prompted
3. node0# commit
4. Using your favorite FTP program, connect to the IP of your trust interface, and login using the credentials of the user you created above.
5. Copy the Junos software package you downloaded from the Juniper site to /var/tmp
6. From the primary node, issue the following commands:
1. node0# request routing-engine login node 1
2. node1# file copy file copy /var/tmp/junos-srxsme-11.4R5.5-domestic.tgz node1:/var/tmp/
3. Check to make sure the copy completed successfully:
1. node1> show file /var/tmp/?
2. You should be able to see the file in the directory
4. node1# request system software add /var/tmp/junos-srxsme-11.4R5.5-domestic.tgz no-copy no-validate unlink
7. Open a separate terminal window and SSH once again to the primary node and issue the same command we issued on node 1:
1. node0# request system software add /var/tmp/junos-srxsme-11.4R5.5-domestic.tgz no-copy no-validate unlink
8. You should have two terminal windows open, one that is monitoring the node0 package installation, and the other that is monitoring the node1 package installation. Once complete, you will see that each SRX is showing that a reboot is required. 
9. Issue a reboot from node1:
1. node1> request system software reboot
10. Issue a reboot from node0:
1. node0> request system software reboot

Juniper recommends to do it simultaneously. I just enter the command in each window and then hit enter in node1, then alt-tab to node0 and do the same. I always disable FTP after I'm done using it, but you can do what you want. Enjoy!

Complete Aruba Networks Access Point Configuration

In my experience, configuring some parameters via the Aruba Networks GUI is a bit of a pain. I have found that doing certain parts of the deployment via the CLI is a lot faster. Below is an example of such a deployment. The example below was for a multi-site, retail-type of environment. Rather than deploying wireless controllers at each site, I deployed all APs as remote APs in bridge mode behind Juniper Networks SRX Series Firewalls. This deployment method leverages the benefits of Aruba Networks' Remote AP technology. Basically, the configuration is stored in the flash of the AP so that there is no need to deploy a wireless controller at each site, keeping hardware costs as low as possible. This also makes it so that there is no need for the APs to remain connected to the wireless controller in order to provide wireless access for end users. They are essentially leveraging local switching rather than tunneling back to the controller and then out to the Internet.

NOTE: I am not going to review configuration details for the SRX side of the deployment. You can find that information here. Please also note that these steps have been validated on ArubaOS 5. I imagine it will work for newer builds, but don't quote me on that.

When working with ArubaOS, it is important to go from most granular to least granular. Here is the general method I follow (which varies based on use case):

1. Define services
2. Apply services to access lists
3. Apply access lists to user roles
4. Define ap system profile, aaa profiles, wlan ssid profiles
5. Apply user roles to aaa profiles
6. Define wlan virtual ap and apply aaa profiles, wlan ssid profiles
7. Define ap groups and apply wlan virtual ap and ap system profile

I know it seems confusing, but after doing it a couple of times and following this method you will save a ton of time. Here it is explained:

Define the services that you would like to use.

netservice svc-http-acl tcp 80
netservice svc-dhcp udp 67 68 alg dhcp
netservice svc-dns udp 53 alg dns
netservice svc-mgcp-5004 udp 5004
netservice svc-rtp-udp udp 3000 3005
netservice svc-mgcp-2427 udp 2427
netservice svc-mgcp-2727 udp 2727
netservice svc-sip-udp udp 5060
netservice svc-mgcp-5440-5446 udp 5440 5446
netservice svc-ftp tcp 21 alg ftp
netservice svc-ntp udp 123

Define the access control lists that you would like to use.

ip access-list session dns-acl                  
  any any svc-dns permit
!
ip access-list session http-acl
  any any svc-http permit
!
ip access-list session dhcp-acl
  any any svc-dhcp permit
!

These ACLs are basically stating that from any network to any network, allow DNS/DHCP/HTTP traffic. The same format applies to the rest of the ACLs below.

ip access-list session allowall
  any any any permit 
!
ip access-list session srcnat
  any any any route src-nat
  user any any src-nat
!

The srcnat ACL is important when deploying APs as Remote APs in Bridge Mode. You will see why shortly.

Create user roles and apply access control lists to them.

user-role test-corporate-role
 session-acl allowall
 session-acl srcnat
!
user-role test-guest-role
 session-acl dhcp-acl
 session-acl srcnat
!

One role applies to guest users, and the other applies to corporate users. It is important to note that although we are leveraging local switching and firewall rules on the Juniper SRX Series Firewall, ACLs applied to user roles can still allow/deny traffic. This is due to the fact that the AP configuration is stored in the flash of the AP itself in this type of deployment. By applying the allowall ACL at the beginning of the user role, we are essentially telling the AP to follow the rules applied on the SRX. The srcnat rule tells the AP that if traffic does not match rules on the SRX, then dump all traffic out the local untrust interface. There is always an implicit deny at the end of every Aruba Networks firewall policy.

Create aaa profiles and apply roles to them.

aaa profile "test-corporate-profile"
   initial-role "test-corporate-role"
   authentication-dot1x "default"
   dot1x-default-role "test-corporate-role"
!
aaa profile "test-guest-profile"
   initial-role "test-guest-role"
   authentication-dot1x "default"
   dot1x-default-role "test-guest-role"
!

Create an ap system profile.

ap system-profile "test-ap-profile"
   native-vlan-id 6
!

Based on this example and our integration with the Juniper SRX Series Firewall, the native VLAN ID is the same VLAN that the AP and the corporate wireless users with reside on (192.168.6.0/24). You have to use this command when the AP is plugged into a trunked interface. You can find additional information on the SRX configuration here.

Create WLAN SSID Profiles.

wlan ssid-profile "test-coporate-ssid"
   essid "corporate"
   wpa-passphrase test123
   opmode wpa2-psk-aes
!
wlan ssid-profile "test-guest-ssid"
   essid "guest"
   wpa-passphrase test123
   opmode wpa2-psk-aes
!

In this example, both SSIDs are configured for AES-CCMP encryption with a pre-shared key.

Create WLAN Virtual AP Profiles, and apply the AAA and SSID Profiles.

wlan virtual-ap "test-corporate-vap"
   aaa-profile "test-corporate-profile"
   ssid-profile "test-corporate-ssid"
   vlan 6
   forward-mode bridge
   rap-operation always
!
wlan virtual-ap "test-guest-vap"
   aaa-profile "test-guest-profile"
   ssid-profile "test-guest-ssid"
   vlan 7
   forward-mode bridge
   rap-operation always
!

The wlan virtual-ap profile is exactly what it describes, a "virtual" access point. By creating multiple virtual APs, you can have multiple SSIDs exist on one physical access point. Please also note that these VLANs only reside at the branch network and not where the controller lives, thus it is not necessary to add these VLANs to the controller itself.

Create an AP Group, and apply the Virtual AP Profiles.

ap-group "test-ap-group"
   virtual-ap "test-corporate-vap"
   virtual-ap "test-guest-vap"
   ap-system-profile "test-ap-profile"
!

Provision the AP.

provision-ap copy-provisioning-params ap-name 00:00:00:00:00:00
provision-ap installation default
provision-ap dns-server-ip 1.1.1.1
provision-ap domain-name test.local
provision-ap no external-antenna
provision-ap server-name aruba-master
provision-ap ap-group "test-ap-group"
provision-ap ap-name "Test_AP"
provision-ap no syslocation
provision-ap mesh-role none
provision-ap no fqln
provision-ap reprovision ap-name 00:00:00:00:00:00

ShoreTel Reverse Proxy for Mobile Communicator

I recently ran into an issue when attempting to create a reverse proxy between the ShoreTel HQ server and the outside world. I thought I would share the steps I took to get this working.

Scenario: You have purchased the Mobile Access License which allows the utilization of the ShoreTel Mobile Communicator via a smart phone from the 3G/4G network. Now, in order for mobile access to work, ports 80, 5447, and 5449 need to be opened to allow authentication and traffic. Giving access to your ShoreTel server over port 80 from the outside world is never recommended, so building a proxy server to translate one random port to the three ports mentioned above is best practice.

Before you continue reading, download and read through the official ShoreTel Application Note#10370 found here.

Please use the steps in the application note to get everything set up. I followed this guide myself, but due to the document being outdated I had to make certain changes in order to get this working. These changes are as follows.

• Do not use port 5500 as specified in the application note. As of ShoreTel 12, port 5500 is in use by DTAS. Not sure why this would affect this scenario, but it did. Use any other random port, like 5505 for example.
• Change the web.config file to the following (additions in red):

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

<system.webServer>

<rewrite>

<rules>

<rule name="ShoreTel Authenticate Redirect" stopProcessing="true">

<match url="^authenticate(.*)" />

<action type="Rewrite" url="http://shoretelhq.internal.name:80{R:1}" logRewrittenUrl="true" />

</rule>

<rule name="ShoreTel CAS Redirect" stopProcessing="true">

<match url="^cas(.*)" />

<action type="Rewrite" url="http://shoretelhq.internal.name:5447{R:1}" logRewrittenUrl="true" />

</rule>

<rule name="ShoreTel Director2 Redirect" stopProcessing="true">

<match url="^director2(.*)" />

<action type="Rewrite" url="http://shoretelhq.internal.name:5449{R:1}" logRewrittenUrl="true" />

</rule>

</rules>

<outboundRules>

<preConditions>

<preCondition name="IsHTML">

<add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />

</preCondition>

</preConditions>

</outboundRules>

</rewrite>

<urlCompression doStaticCompression="false" doDynamicCompression="false" />

</system.webServer>

</configuration>

• Restart IIS

This is all I did to get it working. All it took was a little google fu and a packet capture.

Adding SIP Extensions to ShoreTel

Recently I had an installation in which we needed to add multiple Polycom SoundPoint 501 phones to the ShoreTel Phone System. Since the guides that explain how to add SIP extensions are outdated and the process is completely manual, I thought I would share how we automated the process of adding these phones, making it almost as easy as adding ShorePhones to the system.

It is important to note that you need to ensure that you have the proper licensing. Also, please download and read the manual process of adding SIP extensions prior to attempting this automated process. Your partner of record will be able to provide you with multiple documents if you do not have access to the ShoreTel Knowledge Base.

1. The first thing you need to do is download and run some type of TFTP server program. We did it on the ShoreWare Server just to keep things simple.
2. Go to Polycom's site and download the version of SIP that it specifies to use in the ShoreTel KB for your phone model.
3. Place the downloaded files into the root directory of your TFTP server.
4. You don't really need to worry about anything that's in there other than the file titled, "000000000000.cfg." This file is the first file that the phone looks to in order to pull configuration information.
5. Edit the "000000000000.cfg" and add "[MACADDRESS]-user.cfg, CUSTOM_phone1.cfg, CUSTOM_sip.cfg" to the config files string for your specific SoundPoint model. You will see I added it to all models in the attached template.
6. Create two files called, "CUSTOM_phone1.cfg" and "CUSTOM_sip.cfg", and add the information as specified in the attached template files. These files essentially tells the phones how to connect to ShoreTel so you don't have to log into the GUI of each phone and enter parameters by hand.
7. Create one file for each of your SIP phones with each phone's MAC address in the title of each file name. So, if your phone's MAC address is AB:CD:EF:GH:IJ:KL, then create a file called "abcdefghijkl-user.cfg" and add the information as shown below in the "enterphonemac-user.cfg" file example. This file specifies extension number and SIP password information as specified in the Users->Individual Users page of the ShoreWare Director.
8. Optional step: Factory default the phone (Format File System, Reset Device Settings, and Reset Local Config).
9. Enter the IP address of the TFTP server and any other necessary information (i.e. VLAN ID) on the phone. These can also be achieved via custom DHCP options. I am not going to go over this process because it is different depending on what you are using for your DHCP server.
10. Reboot the phone and that’s that.

Here is a look at the files with information we added in red:

000000000000.cfg with Custom String:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<!-- Default Master SIP Configuration File-->

<!-- For information on configuring Polycom VoIP phones please refer to the -->

<!-- Configuration File Management white paper available from: -->

<!-- http://www.polycom.com/common/documents/whitepapers/configuration_file_management_on_soundpoint_ip_phones.pdf -->

<!-- $RCSfile$  $Revision: 125118 $ -->

<APPLICATION APP_FILE_PATH="sip.ld" CONFIG_FILES="phone1.cfg, sip.cfg" MISC_FILES="" LOG_FILE_DIRECTORY="logs" OVERRIDES_DIRECTORY="" CONTACTS_DIRECTORY="" LICENSE_DIRECTORY="">

  <APPLICATION_SPIP300 APP_FILE_PATH_SPIP300="sip_212.ld" CONFIG_FILES_SPIP300="[MACADDRESS]-user.cfg, CUSTOM_phone1.cfg, CUSTOM_sip.cfg, phone1_212.cfg, sip_212.cfg" />

  <APPLICATION_SPIP301 APP_FILE_PATH_SPIP301="sip_318.ld" CONFIG_FILES_SPIP301="[MACADDRESS]-user.cfg, CUSTOM_phone1.cfg, CUSTOM_sip.cfg, phone1_318.cfg, sip_318.cfg" />

  <APPLICATION_SPIP430 APP_FILE_PATH_SPIP430="sip_318.ld" CONFIG_FILES_SPIP430="[MACADDRESS]-user.cfg, CUSTOM_phone1.cfg, CUSTOM_sip.cfg, phone1_318.cfg, sip_318.cfg" />

  <APPLICATION_SPIP500 APP_FILE_PATH_SPIP500="sip_212.ld" CONFIG_FILES_SPIP500="[MACADDRESS]-user.cfg, CUSTOM_phone1.cfg, CUSTOM_sip.cfg, phone1_318.cfg, sip_212.cfg" />

  <APPLICATION_SPIP501 APP_FILE_PATH_SPIP501="sip_318.ld" CONFIG_FILES_SPIP501="[MACADDRESS]-user.cfg, CUSTOM_phone1.cfg, CUSTOM_sip.cfg, phone1_318.cfg, sip_318.cfg" />

  <APPLICATION_SPIP600 APP_FILE_PATH_SPIP600="sip_318.ld" CONFIG_FILES_SPIP600="[MACADDRESS]-user.cfg, CUSTOM_phone1.cfg, CUSTOM_sip.cfg, phone1_318.cfg, sip_318.cfg" />

  <APPLICATION_SPIP601 APP_FILE_PATH_SPIP601="sip_318.ld" CONFIG_FILES_SPIP601="[MACADDRESS]-user.cfg, CUSTOM_phone1.cfg, CUSTOM_sip.cfg, phone1_318.cfg, sip_318.cfg" />

  <APPLICATION_SSIP4000 APP_FILE_PATH_SSIP4000="sip_318.ld" CONFIG_FILES_SSIP4000="[MACADDRESS]-user.cfg, CUSTOM_phone1.cfg, CUSTOM_sip.cfg, phone1_318.cfg, sip_318.cfg" />

</APPLICATION>

CUSTOM_phone1.cfg:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<phone1>

   <reg reg.1.server.2.transport="DNSnaptr" reg.1.server.1.transport="DNSnaptr" reg.1.type="private" reg.1.server.1.address="Virtual_IP_of_SIP_Proxy" reg.1.server.1.port="5060"  reg.1.server.1.expires="3600" reg.1.server.1.register="1" reg.1.server.1.retryTimeOut="0" reg.1.server.1.retryMaxCount="3" />

  <msg msg.bypassInstantMessage="0">

    <mwi msg.mwi.1.callBack="1102" msg.mwi.1.callBackMode="contact" msg.mwi.1.subscribe="1102" divert.dnd.1.contact="1101" divert.dnd.1.enabled="1" />

  </msg>

</phone1>

CUSTOM_sip.cfg:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<!-- SIP Application Configuration File -->

<!-- $RCSfile$  $Revision: 100041 $ -->

<sip>

  <voIpProt>

    <server voIpProt.server.1.address="Virtual_IP_of_SIP_Proxy" voIpProt.server.1.port="5060" voIpProt.server.1.transport="DNSnaptr" voIpProt.server.1.expires="3600" voIpProt.server.1.register="1" voIpProt.server.1.retryTimeOut="0" voIpProt.server.1.retryMaxCount="3" voIpProt.server.1.expires.lineSeize="30" />

  </voIpProt>

  <TCP_IP>

    <SNTP tcpIpApp.sntp.resyncPeriod="86400" tcpIpApp.sntp.address="SNTP_Server" tcpIpApp.sntp.address.overrideDHCP="1" tcpIpApp.sntp.gmtOffset="-28800" tcpIpApp.sntp.gmtOffset.overrideDHCP="1" />

  </TCP_IP>

 </sip>

enterphonemac_user.cfg:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<phone1>

   <reg reg.1.label="enterextension" reg.1.auth.userId="enterextension" reg.1.auth.password="sip_password" reg.1.address="enterextension" reg.1.displayName="EnterUserName" />

</phone1>