Daryl Hunter – Hubby, Daddy, Mentor, Friend

Howdy!  Today I'd like to share with you one of our latest little projects.  We are always looking at the latest iterations of network design, and one of those proposed by my bossman was changing up how we handle our ISP situations at our campuses.

Our remote campus locations have been connected back to our Central location via several different methods – Cisco IPSec/VPN, IPCop VPN, and even some cool MetroE over HFC technology.  At the Central site, as I've blogged before, we use a Cisco ASA 5520 cluster. When using Cisco-based IPSec/VPN at the remote campuses, we have been using Cisco 17xx & 28xx series routers.

Why Is This Different?
We recently moved to a new building at our Hendersonville, TN location. We ran into some ISP & wiring challenges and were not able to get both Cable Modem & DSL as normal. Instead we got 2x DSL connections.  This doesn't sound bad, however, we're struggling to handle our video streaming, VoIP calls, and especially our weekly media download over a Bellsouth 3meg connection.  We even split our IPSec/VPN connection off from our normal "web surfing" connection.  The IPSec/VPN was terminating on a Cisco 1760 router with VPN module and was running at about 70% CPU (or more).  Things were s-l-o-w.

So, as I said, bossman suggested trying a Cisco ASA 5505.  Our idea was to migrate VPN & "web surfing" stuff to the ASA and let the 1760 handle voice only.  Great idea. He did the research and realized we needed the "Security Plus" licensing on the ASA 5505 to handle what we needed.  Also during discussions, we decided to go a step further and move all of our L3 routing to the ASA.  At our campuses, we use a /24 (Class C) supernet and VLAN/subnet that off for data, voice, out-of-band-management, tech gear (audio, video, lights) and such.

Old Setup
As mentioned, our OLD setup looked something like this:

 

The relevant VPN & routing config on the 1760 looked like this:

—
interface eth0/0
public IP
nat outside
crypto map here (for vpn)
!
interface fa0/0
no ip / no config
!
interface fa0/0.2
sub-interface for out of band mgmt
!
interface fa0/0.3
sub-interface for data
!
interface fa0/0.10
sub-interface for voice
!
interface fa0/0.44
sub-interface for tech stuff (audio, video, lights)
!

The 1760 Router is connected to the 35xx switch via a trunk port to handle the multi-vlan / multi-subnet setup
—

New Setup
And, we wanted our NEW setup to look something like this:

 

—
The 1760 config is "voice" only – no multi-subnets

The 1760 router is connected to the 35xx switch only using the voice vlan.

The Cisco ASA is connected to the 35xx switch using a trunk port to handle the multi-vlan / multi-subnet setup

The Cisco ASA handles all the L3 routing / multi-vlan stuff.  The Cisco ASA also handles the IPSec/VPN & the natted Internet surfing.

How We Did It
So – What exactly did we do?  We had to change the config(s) on the router, switch, and of course configure the ASA properly.  The Cisco 1760 router & the Cisco 35xx switch configs were easy.  We just adjusted trunk ports / and vlan choices.  Nothing special there.  Let's focus on the ASA.

The full (scrubbed) config for the ASA
can be downloaded here if you wanna grab it.

The basic premise is that we needed to do "Dual-ISP" – which to most people means "failover" or "bonded" config.  That's not what we wanted.  We basically needed to handle 2x ISPs at the same time – one for IPSec/VPN and one for web surfing.  We were looking to make the 1760 router JUST a voice router in hopes to alleviate some of the CPU % issues.  We also wanted to start putting a firewall (novel idea, huh?) at our campuses as an additional security effort.

Here's how we handed the multi-vlan… the Cisco ASA 5505 has 8 interfaces but you cannot assign IP addresses directly like you can with the 55×0 series.  You have to assign IPs to vlans, and then assign VLANs to interfaces.  The ASA 5505 ALSO does not handle sub interfaces.  So – no dot1q / vlan encapsulation.  Follow along.

—
interface Vlan2
 nameif mgmt
 security-level 100
 ip address 10.x.x.225 255.255.255.224
!
interface Vlan3
 nameif inside
 security-level 100
 ip address 10.x.x.1 255.255.255.128
!
interface Vlan10
 nameif voice
 security-level 100
 ip address 10.x.x.158 255.255.255.224
!
interface Vlan44
 nameif tech
 security-level 100
 ip address 10.x.x.161 255.255.255.224
!
interface Vlan50
 nameif outside
 security-level 0
 ip address 68.x 255.255.255.248
!
interface Vlan100
 nameif vpn
 security-level 0
 ip address 74.x 255.255.255.248
!
interface Vlan999
 nameif native
 security-level 100
 no ip address
!            
interface Ethernet0/0
 switchport access vlan 50
!
interface Ethernet0/1
 switchport trunk allowed vlan 2-3,10,44
 switchport trunk native vlan 999
 switchport mode trunk
!
interface Ethernet0/5
 switchport access vlan 100
—

Did you follow?  I created all my vlans – which of course matched the vlan configs on my switches – and then trunked those back to eth0/1.  Nothing super special here – but it's a little weird.

I also have my 2x ISPs on my "outside" and "vpn" interface respectively.

Here's how we handled the traffic routing… the "outside" interface is what we used for the general websurfing.  Nothing comes in – it's all "natted" traffic out.  That's handled with this config.

—
access-list Outside_in remark Allow ICMP to enable traceroutes from internal network
access-list Outside_in extended permit icmp any any time-exceeded
access-list Outside_in extended permit icmp any any echo-reply
access-list Outside_in extended permit icmp any any unreachable
access-list Outside_in extended permit icmp any any
!
access-list nonat extended permit ip 10.x.x.0 255.255.255.0 object-group GlobalNetworks
!
icmp permit any inside
!
global (outside) 1 interface
nat (inside) 0 access-list nonat
nat (inside) 1 0.0.0.0 0.0.0.0
!
access-group Outside_in in interface outside
!
route outside 0.0.0.0 0.0.0.0 68.x
—

That's what allows "ping / icmp" traffic and routes all of the natted inside (10.x.x.0) traffic go out of the "outside" interface.  Pretty simple / basic stuff right?

Now, what about the "vpn" interface?  That's the one that goes out another ISP and connects this campus to our central office and all of our other campuses.  That's handled with this config.

—
object-group network GlobalNetworks
 description All LC.tv Networks
 network-object 10.0.0.0 255.0.0.0
 network-object 172.16.0.0 255.255.0.0
 network-object 172.18.0.0 255.255.0.0
 network-object 192.168.0.0 255.255.0.0
!
access-list nonat extended permit ip 10.x.x.0 255.255.255.0 object-group GlobalNetworks
!
access-list hnv-cen extended permit ip 10.x.x 255.255.255.0 object-group GlobalNetworks
access-list hnv-cen extended permit ip object-group GlobalNetworks 10.x.x.0 255.255.255.0
!
nat (vpn) 0 access-list nonat
!
route vpn 12.x 255.255.255.255 74.x
!
crypto ipsec transform-set red esp-3des esp-sha-hmac
crypto map Outside_map 1 match address hnv-cen
crypto map Outside_map 1 set pfs
crypto map Outside_map 1 set peer 12.x
crypto map Outside_map 1 set transform-set red
crypto map Outside_map 1 set nat-t-disable
crypto map Outside_map 1 set reverse-route
crypto map Outside_map interface vpn
!
crypto isakmp enable vpn
crypto isakmp policy 5
 authentication pre-share
 encryption aes-256
 hash sha
 group 2
 lifetime 86400
crypto isakmp policy 10
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400
crypto isakmp policy 20
 authentication pre-share
 encryption 3des
 hash md5
 group 2
 lifetime 86400
crypto isakmp nat-traversal  33
!
group-policy LCSites internal
group-policy LCSites attributes
 vpn-tunnel-protocol IPSec
!
tunnel-group 12.x type ipsec-l2l
tunnel-group 12.x general-attributes
 default-group-policy LCSites
tunnel-group 12.x ipsec-attributes
 pre-shared-key *
—

That's basically the config to handle the IPSec/VPN tunnel and all the appropriate crypto stuff.  Notice there are only 2x routes on the ASA – the "default" route and then the route that points the IPSec/VPN tunnel destination out the "vpn" interface.

Prove It Works
Okay – let's first make sure the tunnel is active

That's fine.  How does the traffic know to route?  You've only got two routes?

Ahh…that's the fun part of the ASA and how it handles VPN tunnels…

HNV-ASA5505# show route

Codes: C – connected, S – static, I – IGRP, R – RIP, M – mobile, B – BGP
       D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
       N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
       E1 – OSPF external type 1, E2 – OSPF external type 2, E – EGP
       i – IS-IS, L1 – IS-IS level-1, L2 – IS-IS level-2, ia – IS-IS inter area
       * – candidate default, U – per-user static route, o – ODR
       P – periodic downloaded static route

Gateway of last resort is 68.x to network 0.0.0.0

C    68.x 255.255.255.248 is directly connected, outside
S    172.16.0.0 255.255.0.0 [1/0] via 74.x, vpn
S    172.18.0.0 255.255.0.0 [1/0] via 74.x, vpn
C    127.0.0.0 255.255.255.0 is directly connected, _internal_loopback
S    10.0.0.0 255.0.0.0 [1/0] via 74.x, vpn
S    10.x.0 255.255.255.0 [1/0] via 74.x, vpn
C    10.x.0 255.255.255.128 is directly connected, inside
C    10.x.128 255.255.255.224 is directly connected, voice
C    10.x.160 255.255.255.224 is directly connected, tech
C    10.x.224 255.255.255.224 is directly connected, mgmt
S    12.x 255.255.255.255 [1/0] via 74.x, vpn
C    74.x 255.255.255.248 is directly connected, vpn
S*   0.0.0.0 0.0.0.0 [1/0] via 68.x, outside
S    192.168.0.0 255.255.0.0 [1/0] via 74.x, vpn
HNV-ASA5505#

See that?  It builds the routes based on the nat configs and crypto map configs.

So – we're routing the "private" traffic out the VPN tunnel and routing the "public / surfing" traffic out the "outside" interface.  Brilliant.

Anyway – that's that.  I wouldn't call it a "revolutionary" concept – but – it's full of firsts for us – first ASA 5505 in production – first remote campus where we've made the "voice router" be voice only – etc.  I hope it's useful and helpful to someone else.