Using OSPF to maintain site-site VPN across multiple WAN links

Having a Single Point of Failure (SPoF) on your network is never a desirable situation and recently I implemented a multi-site set-up where each site had two internet connections and there was a requirement to enable the satellite office to connect to the head office at all times. Each site has a Juniper SSG5-SB firewall as well as a 10Mbit leased line primary Internet circuit and an ADSL backup.

With the Juniper SSG firewalls it is possible to use Policy Based VPNs to maintain multiple tunnels and have the firewalls switch between these as required however you end up with four policies on each firewall and you cannot tell from looking at a routing table where the traffic is flowing. In this instance I decided to make use of OSPF to dynamically route the traffic depending on the availability of the VPNs at each site.

The first thing we need to do in order to implement this is to put each Internet connection into its own Virtual Router so they can run independently of each other.I have covered this in a recent blog post which you can read here.

Once you have the two firewalls setup with each Internet connection in its own virtual router we need to setup the VPNs. This is done with a new Zone in the trust-vr and we will need four numbered tunnel interfaces on each firewall.

On the second site firewall you will need to repeat the commands but using the other IP address in the /30 in each case.

Now we need to setup the VPN tunnels. You may want to change these based upon your requirements however I have used these settings regularly and they work well. NB you will need to apply similar settings on the Site-B firewall with the various endpoint addresses for SiteA

From the GUI you should be able to check that these have come up by going to VPN -> Monitor Status.

We now need to enable OSPF on the trust-vr and configure the interfaces to communicate using OSPF. This should be completed on both the primary and secondary site firewalls.

You can check the OSPF status by running the following command

Finally we need to setup policies to allow traffic to flow across the VPN between the two sites.

To test this you need to take down the Internet connections one by one and watch the routing table update on each firewall.
You should now see all four IPSec VPN Tunnels show as active and the route between sites will be via the Layer-3 tunnel interface for the relevant tunnel.

JunOS: Logout stale edit sessions

I have been bitten enough times when my ssh session to my JunOS switch or router has been disconnected because it was idle and then when I reconnect get the warning to say that another user is editing the configuration.

The easiest thing to do is to log out the other session once you have reconnected to the device by using the PID of the stale session (in this case 28439) with the following command:

You should now no longer see that message when you log back into the switch.

Monitoring Alarm Status on Juniper EX Switches

I am in the process of installing a number of Juniper EX2200, EX3200 and EX4200 switches for a client and as part of the setup need to be able to monitor the switches for any alarmsĀ  (eg Switch Management interface down or Switch booted from Backup Partition) and have them dealt with accordingly.

Having a look at the SNMP OID tree for the EX switches I came across the following useful table

http://www.oidview.com/mibs/2636/JUNIPER-ALARM-MIB.html

Object Name Object Identifier
jnxAlarms jnxAlarms 1.3.6.1.4.1.2636.3.4
jnxCraftAlarms jnxCraftAlarms 1.3.6.1.4.1.2636.3.4.2
jnxAlarmRelayMode jnxAlarmRelayMode 1.3.6.1.4.1.2636.3.4.2.1
jnxYellowAlarms jnxYellowAlarms 1.3.6.1.4.1.2636.3.4.2.2
jnxYellowAlarmState jnxYellowAlarmState 1.3.6.1.4.1.2636.3.4.2.2.1
jnxYellowAlarmCount jnxYellowAlarmCount 1.3.6.1.4.1.2636.3.4.2.2.2
jnxYellowAlarmLastChange jnxYellowAlarmLastChange 1.3.6.1.4.1.2636.3.4.2.2.3
jnxRedAlarms jnxRedAlarms 1.3.6.1.4.1.2636.3.4.2.3
jnxRedAlarmState jnxRedAlarmState 1.3.6.1.4.1.2636.3.4.2.3.1
jnxRedAlarmCount jnxRedAlarmCount 1.3.6.1.4.1.2636.3.4.2.3.2
jnxRedAlarmLastChange jnxRedAlarmLastChange 1.3.6.1.4.1.2636.3.4.2.3.3

I have used the jnxRedAlarmCount and jnxYellowAlarmCount oid values as basic Opsview SNMP Service Checks to give me an initial overview but in the long term will be looking to combine this into a full service check script that can be used to check a number of different things.

The setup of the Service Check in Opsview is fairly simple and below are screenshots of the config that I have for each service check.

All you need to configure on your hosts is the SNMP community string and you can apply these checks individually or via a Host Template.

Once I performed a reload I could see the following in Opsview for one of my switches:

A bit of inspection showed that the Red Alarm was for the Management Interface being down (but wasnt being used on this switch) and the Yellow alarm was due to not setting a rescue configuration. I cleared the alarms by isuing the following commands

Now when I refresh the checks in Opsview I get an OK state for both checks

Juniper EX view pending changes

When making changes to Juniper EX switches yesterday I wanted to check the changes that I had made to my configuration before committing them. A quick look in the reference manual gave me the following command:

This will show the edited candidate config and pipe that into the compare function and look at the changes to the specified version (rollback 0). I could look at the changes compared to a previous config by replacing 0 with another number in the rollback sequence.

 

Asymmetric routing with Cisco ASA firewalls

Last month I installed a new Cisco ASA 5510 for a client and came across an issue where traffic was hitting the “inside” interface of the firewall before travelling back out the same interface and into another router on the internal LAN – an issue as reported in this article Cisco ASA Deny TCP (no connection)

The diagram below demonstrates the network setup with PC1 trying to communicate with PC2. When the traffic leaves the MPLS router (RED line) it does not traverse the ASA and the next packet will follow the original route (GREEN then ORANGE lines) to get to PC2

Representing the traffic flow

Long term the resolution is to place the extra routers into their own DMZ networks on the perimeter network but as this didn’t exist at the time I needed to disable the TCP SYN checking for the traffic being routed to the MPLS routers – a process described in this article by Cisco – Configuring TCP State Bypass

First thing we do is create an ACL for all the items we want to bypass the SYN check

Now we create a class map to match the ACL

Then apply this to a policy map

Finally we assign that policy to the inside interface on the firewall

Traffic that hits the inside interface of the firewall that matches the rules on the ACL will not be checked for their tcp state and traffic should now flow.

In the long term it is recommended that this isnt the adopted approach and the firewall is configured to have the traffic traverse through from the inside to a DMZ interface to prevent the issues with the TCP SYN issue