Look before your leap!

Cloud

[kloud]

Noun
  1. a dim or obscure area in something otherwise clear or transparent.
  2. anything that obscures or darkens something, or causes gloom, trouble, suspicion, disgrace, etc.
  3. to make gloomy

Hmmm… Is the dictionary tying to tell us something here?

Cloud Computing is all the rage.  Read anything remotely pertaining to the world of IT at the moment and, for the unwary, you will be convinced that if you are not “Embracing the Cloud” or otherwise Moving your Business and all its valuable data, onto “the Cloud” then you’re just not cool.  But is this “Cloud Computing” all it’s cracked up to be?  Well of course, that depends on what you mean by “Cloud Computing”.  There are elements of “the Cloud” that make perfect sense and are a tremendous benefit to even small, small businesses (eg. Hosted Exchange).  There are other elements  that are must haves for reducing the costs (and functionality) of large enterprises (gmail Business and Google apps etc).  But essentially, “the cloud” is a generic term meaning services that are available over the internet as opposed to from within your local network (LAN).

Whether you want to cut costs, increase security, leverage Data Centres, Roll out Virtual Desktops to your mobile staff and telecommuters, or simply dip you toe in the Cloud(ed) waters, I would strongly urge you to, Stop.  Take time to fully understand what you are doing.  Make sure you are well aware of, and fully understand the implications of what your IT department, IT Consultants, or simply what you have read if you are flying solo, are saying.  Don’t just listen to the current media mantra of “if it’s Cloud, it’s good”.  I have seen too many organisations rush head long in with out considering the real costs to their business.  In several cases, this has cost them dearly, in others, it is just a disaster.

Now having started this post sounding like the prophet of doom, please don’t get me wrong.  There are a lot of success stories and good products out there on the cloud that are brilliant.  Many perfectly suited to running small businesses more effectively.  If you want a good example, check out Microsoft 365, or Xero accounting software.  If you want to supercharge your business fiscal management check out the team at FathomHQ.  There are some good pieces of software out there in the cloud.  But these products aren’t good because they are cloud based.  They’re good!  They also happen to be Cloud based.

Of course there’s excellent IaaS (Infrastructure as a Service) out there too. Azure, and Amazon AWS being the pick of them of course.

We have similarly, moved many clients on to Private Cloud based environments.  Some as CoLo, some in hosted environments, Some just hosted Exchange/SharePoint, others in Virtual Desktops that can be created on the fly.  But, All carefully planned and considered as to what the business impact would be for that client.  A frequent issue we have to contend with being out here in the “regional areas” and not in the middle of a capital city, is one of connectivity.  If “the internet” goes down, what happens for the client if they have “Moved to the Cloud”?  How do we build sufficient redundancy into their network infrastructure to withstand outages and limited bandwidth issues.  Sometimes it takes some creative thinking with products like RiverBed, other times it can be as simple as, added redundancy like with 3G/4G/LTE connectivity.  Always it is by planning.

Disaster Recovery is a very important issue to consider when contemplating Cloud services, What happens with your data.  Can it be recovered in a usable manner quickly for you.  Are you just moving your “Single Point of Failure” system further away from you, and hence, more difficult to recover in the event of disaster.  All these things, and many many others need to be carefully considered when contemplating Cloud Computing.

Management and support is probably the biggest thing to consider.  Many of the Apps, like the ones mentioned above, come complete with a great support model included.  But what about more integral services like mail and cloud hosting?  I don’t believe Cloud hosted services, however large or small, are any place for the “Break / Fix” model of IT Support.  A good Managed Service Provider (MSP) is essential to guide a business through the murkiness that can be the Cloud.  Think of us as your Navigation system.  Relying on a Break/Fix Paradigm in the Cloud would be akin to setting off in an unfamiliar aircraft, on a long journey, in inclement weather, with no navigation system, no maps or planned route, and no idea where you are going.  Not a good idea.

My Dad (a Tradie) used to always say, “measure twice, cut once”.  This same paradigm holds true for “the Cloud”.  Look into what you are doing thoroughly.  Is this right for your business?  What are the hidden costs?  What are the security implications? Then, when your satisfied, execute it precisely.

The point of this cautionary tale is, none of this happens by chance, and despite the plethora of bleatings in the media, you need to plan first, and proceed with caution more than ever before.  The Brave new world can be a treacherous place for the unwary.

Feel Free to contact us here at Ramtech if you would like to speak further about how we may be able to help guide you through the cloudy skies of modern business.

Powershell Updating Lists

Sometimes I need to update a list in powershell or the EMS and invariably I forget how to go about it precisely.

Let’s use the example of needing to update the BypassedSenders in the ContentFilterConfig settings.  So for example say that

Get-ContentFilterConfig reveals that we have 3 email addresses in the BypassedSenders.  [email protected], [email protected], [email protected].  We can either write these down, copy from the screen to notepad or some other clumsy form of recording this info, and then paste it back into our list for the Set-ContentFilterConfig -BypassedSenders [email protected], [email protected], [email protected], [email protected].

But you have to admit.  That sucks a a way to do this fairly common task.  What if you had 30 in there and want ed to add another 4.  Ugly!

The neatest way is probably to use GSEXDEV’s excellent Whitelist GUI script.  This is a great yet simple but of code (script) that for those of you that don’t like playing with a shell, is brilliant.  But I am an old fashioned kind of guy and I like doing this kind of thing  myself (long hand) as it keeps my hand in using the powershell (EMS) and it’s fun, so…

  • Open the EMS (Exchange Management Shell)
  • and assign the entire ContentFilterConfig to a variable
  • check that it has done as expected and look at what is in your BypassedSenders already
  • Typing $BPS.BypassedSenders should show you all email addresses their already.
  • you can now use the .add method to add additional addresses
  • Type $BPS.BypassedSenders again will confirm the added address.
  • Now simply use Set-ContentFilterConfig to write your configuration and you are done.
[PS] C:Ramtech> $BPS = Get-ContentFilterConfig
[PS] C:Ramtech> $BPS.BypassedSenders.Add("[email protected]")
[PS] C:Ramtech> $BPS.BypassedSenderDomains.Add("NewDomain.com")
[PS] C:Ramtech> Set-ContentFilterConfig -BypassedSenders $BPS.BypassedSenders
[PS] C:Ramtech> Set-ContentFilterConfig -BypassedSenderDomains $BPS.BypassedSenderDomains

This will work for any list of course and saves an awful lot of typing.  Particularly if you are using <Tab> completion.  So for example if you type $get-con and hit tab a couple of times you will get the Get-ContentFilterConfig command up with no typos:)  It works with the variables and methods too if you forget the exact syntax.

You can also use the

$BPS=(Get-ContentFilterConfig).BypassedSenders

, as Microsoft suggests, to just store the list you are dealing with but this is a lot more typing as there is no <Tab> word completion due to the necessity to enclose the cmdlet in brackets.  So for geese like me who type at the speed of a thousand startled snails, this is tedious.  The other benefit of dealing with the whole config is, if you want to change other settings at the same time, say BypassedSenderDomains, it’s all there for you already with the benefit of <Tab> completion.  So you could do a

$BPS.BypassedSenders.add("<Bypassed Email Address list>")

and also

$BPS.BypassedSenderDomains.add("<Bypassed Domian list>")

and anything else you wanted updated then just use

Set-ContentFilterConfig $BPS

and update the whole lot if you wanted.

It really is easy once you get the hang of it but if you like neat, use Glen’s GUI.

Decrypt Cisco type 7 Passwords

From time to time you may need to decrypt type 7 passwords in the IOS on a Cisco device.

There are a few site that let you do it from a page but what if you don’t have easy access to the Web? Well, help is at hand. Here’s how to do it from right there in the IOS…

Let’s assume it’s something basic like your ISP password, but any password stored insecurely on the router with type 7 encryption is a candidate

interface Dialer3
 ppp chap password 7 094D4D1B1815070B1B0D17393C2B3A37
  1. Create a temporary Key Chain
  2. Add a Key to the chain
  3. Add a type 7 key-string to the key
  4. Show the chain to reveal the un-encrypted string
  5. Remove the Key Chain so as not to clutter your config with rubbish.
Router1(config)#key chain temp

Router1(config-keychain)#key 1

Router1(config-keychain-key)#key-string 7 094D4D1B1815070B1B0D17393C2B3A37
Router1(config)#do sh key chain temp
Key-chain temp:
    key 1 -- text "acrappypassword"
        accept lifetime (always valid) - (always valid) [valid now]
        send lifetime (always valid) - (always valid) [valid now]
Router1(config)#no key chain temp
Router1(config)#

And there you have it! Proof that passwords stored with type 7 encryption in the config really are crappy. 

Cisco 867w / 887w Wireless Config

The Product

Many moons ago I purchased a nice new Cisco 867w as I needed another branch router, and it didn’t really warrant the expense of a larger router for the task at hand. I am reasonably familiar with configuring Cisco switches, security devices (ASA, Catalyst etc) and routers, and can find my way around the IOS fairly well, or so I thought. I haven’t really had much to do with Cisco Wireless APs and general AiroNet products.

But the 867w (and 887w) has a full Cisco AP embedded in to the router. The AP has it’s own IOS and needs a full configuration, and even more alarmingly, I could not find any sample wireless configurations anywhere on the net, including on the Cisco.com site. There is a good configuration guide on the Cisco site but it falls way short of the mark to configure the router from scratch. It is much better as a reference guide. I couldn’t find any reference in it to how the 867w’s AP actually integrated, and hence, communicated with the router itself.

Another major issue for me was that the router shipped with an old IOS and apart from that absolutely nothing in the flash. (Pretty sloppy Cisco!)

The Problem

My problem, in a nutshell, was how to bridge the AP to the router’s vlan. Sounds simple enough doesn’t it. But I couldn’t see an obvious solution and couldn’t find any relevant documentation. I posted on a couple of quality forums to see if anyone else had had a similar issue, and yes lots of people had. What was the solution? None given. Grrr… There are loads of posts pointing to the concept of bridging VLANs and the concept of configuring a router but no wireless sample configs. Personally I find it beneficial when faced with a new device to see a working Config, pull it apart and figure out why it works. I learn the most that way.

To cut a very long story short, there is a Wlan-GigabitEthernet 0 interface visible in both the Router and the AP configuration and this is the glue that binds the Router to the AP. So, below I have included the running config for each of my relevant interfaces on both the Router and the embedded AP.

Don’t forget that, until you configure a management ip on the AP’s BVI1 the only way to configure the AP is by logging on to the router and the using

Router# service-module wlan-ap 0 session

to get into the AP config. Once in there the only way to get back is to use

AP# <Shift>+<Ctrl>+6 X

to get back to the Router’s Configuration mode. This leaves the AP config session open. If you subsequently want to close that session you also need to type

Router# disconnect

to close it completely.

The Solution

On the Router…
interface Vlan1
 ip address 192.168.xx.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
end
!
interface Wlan-GigabitEthernet0
 description Internal switch interface connecting to the embedded AP
end
!
interface wlan-ap0
 description Service module interface to manage the embedded AP
 ip unnumbered Vlan1
 arp timeout 0
end
!
interface Dialer0
 description PPPoA Dialer for Int ATM0
 ip address negotiated
 ip access-group aclInternetInbound in
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip mtu 1492
 ip flow ingress
 ip nat outside
 ip virtual-reassembly
 encapsulation ppp
 dialer pool 1
 ppp authentication chap callin
 ppp chap hostname
 ppp chap password
 ppp ipcp dns request accept
 ppp ipcp route default
 ppp ipcp address accept
 no cdp enable
 crypto map
end

Of course there is no necessity for the

ip route 0.0.0.0 0.0.0.0

due to the ip ipcp route default on the dialer interface.

On the AP
interface Dot11Radio0
 no ip address
 no ip route-cache
 encryption mode ciphers aes-ccm tkip
 broadcast-key change 3600
 ssid
 antenna gain 0
 speed  basic-6.0 basic-9.0 basic-12.0 basic-18.0 basic-24.0 basic-36.0 basic-48.0 basic-54.0 m0. m1. m2. m3. m4. m5. m6. m7. m8. m9. m10. m11. m12. m13. m14. m15.
 station-role root ap-only
 bridge-group 1
 bridge-group 1 subscriber-loop-control
 bridge-group 1 block-unknown-source
 no bridge-group 1 source-learning
 no bridge-group 1 unicast-flooding
 bridge-group 1 spanning-disabled
end
!
interface GigabitEthernet0
 description the embedded AP GigabitEthernet 0 is an internal interface connecting AP with the host router
 no ip address
 no ip route-cache
 bridge-group 1
 no bridge-group 1 source-learning
 bridge-group 1 spanning-disabled
end
!
interface BVI1
 ip address 192.168.xx.2 255.255.255.0
 no ip route-cache
end

And on the AP you will need a default route, so you will need a

AP(config)# ip default-gateway 192.168.xx.1

to tell the outside bound traffic how to get out to the world at large through the Router’s VLAN interface.

Edit:  A few people have asked for a full AP config to get started with so here is a “Bare Bone” one to get you started…

no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime localtime
service timestamps log datetime localtime
service password-encryption
hostname AP
logging buffered 132000 notifications
enable secret 0 <PutAGoodPasswordHere>
no aaa new-model
clock timezone AEST 10
clock save interval 8
dot11 syslog
dot11 ssid SSID
   authentication open 
   authentication key-management wpa version 2
   guest-mode
   wpa-psk ascii 0 <PutAGoodPasswordHere>
username me privilege 15 secret 0 <PutAGoodPasswordHere>
bridge irb
interface Dot11Radio0
 no ip address
 no ip route-cache
 encryption mode ciphers aes-ccm tkip 
 broadcast-key change 3600
 ssid SSID
 antenna gain 0
 speed  basic-6.0 basic-9.0 basic-12.0 basic-18.0 basic-24.0 basic-36.0 basic-48.0 basic-54.0 m0. m1. m2. m3. m4. m5. m6. m7. m8. m9. m10. m11. m12. m13. m14. m15.
 station-role root ap-only
 bridge-group 1
 bridge-group 1 subscriber-loop-control
 bridge-group 1 block-unknown-source
 no bridge-group 1 source-learning
 no bridge-group 1 unicast-flooding
 bridge-group 1 spanning-disabled
interface GigabitEthernet0
 description the embedded AP GigabitEthernet 0 is an internal interface connecting AP with the host router
 no ip address
 no ip route-cache
 bridge-group 1
 no bridge-group 1 source-learning
 bridge-group 1 spanning-disabled
interface BVI1
 ip address 192.168.xx.2 255.255.255.0
 no ip route-cache
ip default-gateway 192.168.xx.1
no ip http server
no ip http secure-server
bridge 1 route ip
line con 0
 no activation-character
line vty 0 2
 exec-timeout 20 0
 login local
 transport preferred none
 transport input telnet
line vty 3 4
 exec-timeout 20 0
 login local
 transport preferred none
 transport input ssh
 transport output all
sntp server <IPofSntpServer>

I hope that helps.

Edit Cisco ACLs Live

There are a number of different type of Cisco ACLs available on their various IOS powered devices.  Of these the numbered, and named types are the most prevalent.  For my money I always use named where possible as I find them a lot neater and easier to edit live.  With a numbered ACL, if you need to change the order of the ACL (remember they are processed sequentially so the order is very important)  you need to do something like

  • copy the whole ACL into vi (or your favourite editor)
  • edit it to suit your new requirements
  • delete the old one from the config using something like no ip access-list 158
  • paste the edited one in to the config.

The problem with this is that this quite often isn’t possible if your ACL controls your ability to access the router/switch.  The same situation can exist if you don’t know how to edit named ACLs while they are live.  This method should really only be done on routers you are connected to by the console and aren’t live.

An easier solution is simply to edit named ACLs live. Now this isn’t necessarily for the faint of heart, and can easily end in a router/switch boot if you aren’t careful, but it is the “best” method in my opinion.

So how to do it…

First, you need to understand that named ACLs actually have line numbers.  I will also stress again that the ACL is assessed sequentially, so the order is imperative. Also remember, the ACL stops processing as soon as it gets a positive match.

Now if you show the ACL you will get something like this…

Router1(config)# do sh access-l aclInternetInbound
Extended IP access list aclInternetInbound
 10 permit tcp any any established (3579 matches)
 20 permit udp any any eq domain (13 matches)
 30 deny ip 12.0.0.0 1.255.255.255 any
 40 deny ip 24.200.0.0 0.3.255.255 any
 50 deny ip 24.248.0.0 0.7.255.255 any
 60 deny ip 38.0.0.0 0.255.255.255 any
 70 deny ip 41.177.0.0 0.0.255.255 any
 80 deny ip 41.208.192.0 0.0.63.255 any
 90 deny ip 58.192.0.0 0.31.255.255 any (22 matches)
 100 deny ip 59.32.0.0 0.31.255.255 any
 110 deny ip 59.151.0.0 0.0.127.255 any
 120 deny ip 60.0.0.0 0.31.255.255 any
 130 deny ip 61.12.0.0 0.0.127.255 any
 140 deny ip 61.32.0.0 0.7.255.255 any
 ...
 2050 permit tcp any any eq smtp  (4006 matches)

As you can see this is part of a mail server router ACL (that blocks a lot of our international friends from bothering us) and we can see the line numbers shown. So to edit it while live we simple enter the ACL configuration and edit the line numbers directly. The other lines remain unaffected and in their original order. We can just as easily remove offending Line Numbers if necessary…
Edit: Please note the “Safety Switch” of   reload in 10   (minutes). This reloads the router config to the current startup config if we stuff up our editing and lose connection.

Router1(config)# do reload in 10
Router1(config)# ip access ext aclInternetInbound
Router1(config-ext-nacl)# no 50                                  <--- Deletes line number 50
Router1(config-ext-nacl)# 65 deny ip 41.0.0.0 0.0.255.255 any    <--- Adds a line number 65 between 60 and 70
Router1(config-ext-nacl)# exit
Router1(config)# do sh access-l aclInternetInbound
Extended IP access list aclInternetInbound
 10 permit tcp any any established (3579 matches)
 20 permit udp any any eq domain (13 matches)
 30 deny ip 12.0.0.0 1.255.255.255 any
 40 deny ip 24.200.0.0 0.3.255.255 any
 60 deny ip 38.0.0.0 0.255.255.255 any
 65 deny ip 41.0.0.0 0.0.255.255 any
 70 deny ip 41.177.0.0 0.0.255.255 any
 80 deny ip 41.208.192.0 0.0.63.255 any
 90 deny ip 58.192.0.0 0.31.255.255 any (22 matches)
 100 deny ip 59.32.0.0 0.31.255.255 any
 110 deny ip 59.151.0.0 0.0.127.255 any
 120 deny ip 60.0.0.0 0.31.255.255 any
 130 deny ip 61.12.0.0 0.0.127.255 any
 140 deny ip 61.32.0.0 0.7.255.255 any
 ...
 2050 permit tcp any any eq smtp  (4020 matches)
Router1(config)# do reload cancel

Using this method it is easy to end up with the line numbers all over the place so Cisco have kindly provided a re-sequencing method to tidy the world up again.

Router1(config)# ip access-l res aclInternetInbound 10 10

this simple re-sequences the line numbers starting at number 10 and incrementing each line by 10. We then end up with …

Router1(config)# do sh access-l aclInternetInbound
Extended IP access list aclInternetInbound
 10 permit tcp any any established (3579 matches)
 20 permit udp any any eq domain (13 matches)
 30 deny ip 12.0.0.0 1.255.255.255 any
 40 deny ip 24.200.0.0 0.3.255.255 any
 50 deny ip 38.0.0.0 0.255.255.255 any
 60 deny ip 41.0.0.0 0.0.255.255 any
 70 deny ip 41.177.0.0 0.0.255.255 any
 80 deny ip 41.208.192.0 0.0.63.255 any
 90 deny ip 58.192.0.0 0.31.255.255 any (22 matches)
 100 deny ip 59.32.0.0 0.31.255.255 any
 110 deny ip 59.151.0.0 0.0.127.255 any
 120 deny ip 60.0.0.0 0.31.255.255 any
 130 deny ip 61.12.0.0 0.0.127.255 any
 140 deny ip 61.32.0.0 0.7.255.255 any
 ...
 2050 permit tcp any any eq smtp  (4072 matches)

A couple of things to remember…

  • All ACLs, number or named, have an implicit   deny ip any any   at the end of them.  So permit or deny the stuff you definitely want and let the implicit deny handle the rest.  Don’t clog your ACL’s with useless crud that will get picked up by the implicit deny anyway.  It just chew processor resources unnecessarily.
  • The ACL is assessed sequentially so be very careful with the order of statements.  No point putting a permit everything followed by a deny something explicit.
  • As soon as the ACL gets a positive match, it stops processing.  So a   deny ip any any   at the start of an ACL will ensure nothing ever gets through 
  • Use   reload in 10   and   reload cancel   in case you stuff up.  They are life savers if the router or switch is remote. (Thanks again to Daniel996)

So there you go. Edit them live and save a lot of stress. But do be careful won’t you.

Cisco ACL Configuration

Many, Many moons ago, some colleagues far more learned than I, had the arduous task of explaining to me why I had the concept of applying ACLs to an interface correctly, slightly muddled.
This sounds simple enough and for and despite many years of training and use I had thought it was. That’s until I gave some (rather poor) advice to reader regarding blocking some VLAN traffic on his Cisco switch. Due to some misconceptions on my part my advice was errant. The above mentioned gurus set about patiently (at least it seemed patiently to me) correcting my minor, yet important misconceptions regarding the nuances of applying Cisco ACLs to interfaces.

I have since found what I reckon is the best explanation of the concept I have read. And surprisingly it is from the cisco site.

The relevant section is…

When you refer to a router, these terms have these meanings.

Out—Traffic that has already been through the router and leaves the interface. The source is where it has been, on the other side of the router, and the destination is where it goes.
In—Traffic that arrives on the interface and then goes through the router. The source is where it has been and the destination is where it goes, on the other side of the router.
Inbound —If the access list is inbound, when the router receives a packet, the Cisco IOS software checks the criteria statements of the access list for a match. If the packet is permitted, the software continues to process the packet. If the packet is denied, the software discards the packet.
Outbound—If the access list is outbound, after the software receives and routes a packet to the outbound interface, the software checks the criteria statements of the access list for a match. If the packet is permitted, the software transmits the packet. If the packet is denied, the software discards the packet.

The in ACL has a source on a segment of the interface to which it is applied and a destination off of any other interface. The out ACL has a source on a segment of any interface other than the interface to which it is applied and a destination off of the interface to which it is applied.

For this to cement with me I had to imagine I am a Traffic Cop on a router interface.  So to keep it simple, let’s imagine a simple router that only has one LAN and one WAN interface.  Then imagine you are the Policeman standing guard on the LAN interface on that router.  That means you stand facing (connected to) the LAN (probably a switch). In this instance, Inbound traffic is coming at you head on, headed for the router.

So if an ACL is applied in on you that means you are deciding if it should be allowed from the LAN into the Router.  if an ACL is applied out on you that means it you are deciding if it should be allowed from the Router to the LAN.  In both cases you will look at your rule book and consider if the traffic is permissible or not. Hence why it is important to block traffic at it’s source to conserve precious CPU resources.

Back to the analogy, being the good Cop you are you know that if you get a positive match on your list you stop looking any further.  So you see a deny statement for a packet you instantly deflect it and don’t have to deal with it anymore.  You don’t keep looking down the list to see if it’s permitted elsewhere.  Equally if it’s permitted, you don’t keep looking to see if it is later denied.  That’d be silly.

Just remember the Cop (ACL) always faces the direction the interface is connected to.  LAN faces the LAN, WAN faces the WAN, VLAN faces that VLAN.  That’s a tricky one.  The VLAN ACLs inbound traffic is coming at it from the VLAN headed elsewhere!  Hence, on a VLAN ACL, if the ACL is applied out, it is traffic destined for the VLAN!  If you remember/understand that, the rest is a cinch.

RR

Cisco IOS VTI VPN

Virtual Tunnel Interface or VTI (Also known as Route Based VPN) are an excellent choice for site to site IPSec encrypted VPNs terminating on Cisco IOS devices. You can always use the older Crypto maps but I find VTIs so much easier to deal with and to debug. If you are terminating on an ASA firewall or another non Cisco device Crypto Maps (or Policy Based VPNs as they’re known) may be your only choice, but where you have a choice, choose VTIs.

In Jeremy Stretch’s Excellent Blog he covers the differences in these two posts.
http://packetlife.net/blog/2011/aug/15/policy-based-vs-route-based-vpns-part-1/
http://packetlife.net/blog/2011/aug/17/policy-based-vs-route-based-vpns-part-2/

I won’t go into what each stage of the VTI does. This is just a quick example to get you started so you can research the finer points yourself and learn what it all does.

You generally need at least IPSECURITY IOS image or AdvanceIP for VPNs to work in any variation of the IOS.

The following is a very simple example of setting up a basic VTI site to site with IPSec Encryption.

LAN(a) -----  Router1  ~~~WAN~~~  Router2  ----- LAN(b)
IP address assumptions.  But of course, use your own addressing schema...
LAN(a) Subnet - 192.168.10.0/24
LAN(b) Subnet - 192.168.50.0/24
R1LAN Address - 192.168.10.1
R2LAN Address - 192.168.50.1
R1WAN Address - 1.2.3.4
R2WAN Address - 6.8.10.12

On Router1

crypto isakmp policy 10
 encr aes
 hash md5
 authentication pre-share
 group 2
crypto isakmp key 0 [Enter PSK Here] address 6.8.10.12 no-xauth
crypto ipsec transform-set tsVTI esp-aes esp-md5-hmac 
crypto ipsec profile profVTI
 set transform-set tsVTI 
interface Loopback0
 description Loopback Interface for UnNumbered VTIs
 ip address 10.1.1.1 255.255.255.252
interface Tunnel0
 description LAN(a) -- LAN(b)
 ip unnumbered Loopback0
 tunnel source Dialer0
 tunnel destination 6.8.10.12
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile profVTI

On Router2

crypto isakmp policy 10
 encr aes
 hash md5
 authentication pre-share
 group 2
crypto isakmp key 0 [Enter the Same PSK here] address 1.2.3.4 no-xauth
crypto ipsec transform-set tsVTI esp-aes esp-md5-hmac 
crypto ipsec profile profVTI
 set transform-set tsVTI 
interface Loopback0
 description Loopback Interface for UnNumbered VTIs
 ip address 10.1.1.2 255.255.255.252
interface Tunnel0
 description LAN(a) -- LAN(b)
 ip unnumbered Loopback0
 tunnel source Dialer0
 tunnel destination 1.2.3.4
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile profVTI

Now all that is needed is a route for each router to be able to find the other LAN down the VPN Tunnel. The most basic example, shown here, is a static route on each router but you may want to use a proper routing protocol.

Router1(Config)# ip route 192.168.50.0 255.255.255.0 10.1.1.1
Router2(Config)# ip route 192.168.10.0 255.255.255.0 10.1.1.2

You can also use the form ip route 192.168.50.0 255.255.255.0 tunnel 0 but this may have issues with proxy arp traffic if there is a lot of traffic on the tunnel (SIP traffic for example).

You may also want to keep in mind that if you have an ACL or some firewall variant protecting your WAN facing interface you will need to allow UDP 500 and ESP in, at a minimum, for this to work.

Cisco IOS Macros

Ever needed to make an alteration that would mean you could no longer access the router when you did?  Let’s say you have a router with a DSL interface connected to your ISP.  Say you are accessing it remotely and need to change the username and password then bounce the interface.  Remotely, this is a PITA, as, as soon as you issue the shut command  to bounce the interface, that’s it.  Game over you can no longer access the router because the dialer interface is shut down and you have no way to bring it back up without booting the router.  If you boot the router without writing the changes to the startup-config, you have achieved nothing but booting the router and annoying everyone connected.

But sneaky Cisco have hidden a macro functionality in the IOS that allows us to do this without having to resort to EEM or fancy tclsh scripts.  Here’s an example how it works…

First we create our macro

R1(config)# macro name macroNewUserPass
Enter macro commands one per line. End with the character '@'.
interface dialer 0
ppp chap hostname TMPHOST
ppp chap password 0 TMPPASS
shut
no shut
exit@

Next, we need to Run our macro with the substituted actual username and password, instead of the Keyword place holders that I have there now (TMPHOST and TMPPASS).

R1(config)# macro global apply macroNewUserPass TMPHOST "[email protected]" TMPPASS "It's a s3cr3t"

And that’s it. So to pull apart this last command… The macro command puts us in to macro mode in the config, the global apply tells it that this is going to be applied in global config, the macro name is obvious.  The last part is simply Keyword Substitution.  When the Macro named macroNewUserPass runs the keyword TMPHOST becomes [email protected] and the TMPPASS keyword becomes it’s a s3cr3t

So while we will loose connection as soon as the shut is issued on the dialer interface, the macro keeps running and issues the no shut and brings the interface back up again for us.
Now, in this particular example, depending on whether this interface bounce has resulted in an WAN IP address change or not, you may need to ssh in to a different IP than before. But that’s a little outside the scope of this document.