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.

set zone name VPNZone
set zone VPNZone vrouter trust-vr
set interface "tunnel.1" zone "VPNZone"
set interface "tunnel.2" zone "VPNZone"
set interface "tunnel.3" zone "VPNZone"
set interface "tunnel.4" zone "VPNZone"
set interface tunnel.1 ip 172.16.1.1/30
set interface tunnel.2 ip 172.16.1.5/30
set interface tunnel.3 ip 172.16.1.9/30
set interface tunnel.4 ip 172.16.1.13/30

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

set ike gateway "Site-A_PRI-Site-B_PRI" address 192.0.2.18 Main outgoing-interface "ethernet0/0" preshare EnterYourPSKHere proposal "pre-g2-aes128-sha"
set ike gateway "Site-A_PRI-Site-B_SEC" address 192.0.2.34 Main outgoing-interface "ethernet0/0" preshare EnterYourPSKHere proposal "pre-g2-aes128-sha"
set ike gateway "Site-A_SEC-Site-B_PRI" address 192.0.2.18 Main outgoing-interface "ethernet0/1" preshare EnterYourPSKHere proposal "pre-g2-aes128-sha"
set ike gateway "Site-A_SEC-Site-B_SEC" address 192.0.2.34 Main outgoing-interface "ethernet0/1" preshare EnterYourPSKHere proposal "pre-g2-aes128-sha"
set vpn "Site-A_PRI-Site-B_PRI IKE" gateway "Site-A_PRI-Site-B_PRI" no-replay tunnel idletime 0 proposal "g2-esp-aes128-sha"
set vpn "Site-A_PRI-Site-B_PRI IKE" monitor optimized rekey
set vpn "Site-A_PRI-Site-B_PRI IKE" id 0x6 bind interface tunnel.1
set vpn "Site-A_SEC-Site-B_PRI IKE" gateway "Site-A_SEC-Site-B_PRI" no-replay tunnel idletime 0 proposal "g2-esp-aes128-sha"
set vpn "Site-A_SEC-Site-B_PRI IKE" monitor optimized rekey
set vpn "Site-A_SEC-Site-B_PRI IKE" id 0x3 bind interface tunnel.2
set vpn "Site-A_SEC-Site-B_PRI IKE" dscp-mark 0
set vpn "Site-A_PRI-Site-B_SEC IKE" gateway "Site-A_PRI-Site-B_SEC" no-replay tunnel idletime 0 proposal "g2-esp-aes128-sha"
set vpn "Site-A_PRI-Site-B_SEC IKE" monitor optimized rekey
set vpn "Site-A_PRI-Site-B_SEC IKE" id 0x4 bind interface tunnel.3
set vpn "Site-A_SEC-Site-B_SEC IKE" gateway "Site-A_SEC-Site-B_SEC" no-replay tunnel idletime 0 proposal "g2-esp-aes128-sha"
set vpn "Site-A_SEC-Site-B_SEC IKE" monitor optimized rekey
set vpn "Site-A_SEC-Site-B_SEC IKE" id 0x5 bind interface tunnel.4

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.

set vrouter trust-vr protocol ospf
set vrouter trust-vr protocol ospf enable
set vrouter trust-vr
  set interface tunnel.1 protocol ospf area 0.0.0.0
  set interface tunnel.1 protocol ospf enable
  set interface tunnel.1 protocol ospf priority 10
  set interface tunnel.1 protocol ospf cost 1
  set interface tunnel.1 protocol link-type p2p
  set interface tunnel.2 protocol ospf area 0.0.0.0
  set interface tunnel.2 protocol ospf enable
  set interface tunnel.2 protocol ospf priority 20
  set interface tunnel.2 protocol ospf cost 2
  set interface tunnel.2 protocol link-type p2p
  set interface tunnel.3 protocol ospf area 0.0.0.0
  set interface tunnel.3 protocol ospf enable
  set interface tunnel.3 protocol ospf priority 30
  set interface tunnel.3 protocol ospf cost 3
  set interface tunnel.3 protocol link-type p2p
  set interface tunnel.4 protocol ospf area 0.0.0.0
  set interface tunnel.4 protocol ospf enable
  set interface tunnel.4 protocol ospf priority 40
  set interface tunnel.4 protocol ospf cost 4
  set interface tunnel.4 protocol link-type p2p
  set interface bgroup0 protocol ospf area 0.0.0.0
  set interface bgroup0 ospf passive
  set interface bgroup0 ospf enable

You can check the OSPF status by running the following command

get vr trust-vr protocol ospf neighbor

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

set address Trust "Site A LAN (192.168.1.0/24)" 192.168.1.0/24
set address VPNZone "Site B LAN (192.168.1.0/24)" 192.168.1.0/24
set policy from Trust to VPNZone "Site A LAN (192.168.1.0/24)" "Site B LAN (192.168.1.0/24)" any permit
set policy from VPNZone to Trust "Site B LAN (192.168.1.0/24)" "Site A LAN (192.168.1.0/24)" any permit

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.

adminuser@switch01> edit
Entering configuration mode
Users currently editing the configuration:
adminuser terminal p0 (pid 28439) on since 2013-02-28 14:27:28 GMT, idle 01:41:42
[edit]

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:

request system logout pid 28439

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

edit
set chassis alarms management-interface link-down ignore
commit and-quit
request system configuration rescue save

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:

show | compare rollback 0

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

access-list firewall_bypass extended permit ip object Local_LAN object Remote_LAN_1
access-list firewall_bypass extended permit ip object Local_LAN object Remote_LAN_2
access-list firewall_bypass extended permit ip object Local_LAN object Remote_LAN_3

Now we create a class map to match the ACL

class-map class_firewall_bypass
match access-list firewall_bypass

Then apply this to a policy map

policy-map inside-policy
class class_firewall_bypass
set connection advanced-options tcp-state-bypass

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

service-policy inside-policy interface inside

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