Blog

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. 

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.

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