The Certified Geek

It has been a while I manage to write new stuff given with the new work I am currently dealing but here is the first for this year

We just bought some Cisco Wireless Access Point (model 1131AG) but unfortunately these are already in lightweight mode. In this mode, you would need a Wireless LAN Controller to utilize them. There a documentation to how to upgrade an autonomous Cisco Aironet Access Point to lightweight mode only a small section discusses the reversing the process. This blog discusses how I managed to brick errm reverse the process which is not recommended by Cisco.

1. Download the appropriate Cisco IOS from the cisco website (You need to have a valid Cisco account to do this )

For this I downloaded c1130-rcvk9w8-tar.124-10b.JA3

2. Install a TFTP Service (recommend SolarWinds free TFTP server)

3. Rename the image to c1130-k9w7-tar.default and place the image in the TFP source directory

4. Change to IP address of the TFTP Server to any IP address between 10.0.0.2 to 10.0.0.30 (I used 10.0.0.2 on my laptop where the TFTP service is running)

5. Connect the access point on the same switch where the TFTP service is connected. Note: Ensure there is no DHCP service running on the this device.

6. Press the mode button of the access point while pluggin in the power (wait for about 20-25 seconds). Wait for the one of the LED to turn RED (one them becomes Amber first) then release the mode button.

If everything goes well, the process will take around 10 to 15 minutes.

Here are the screenshots from the console of the access point, the sniffer on my laptop and the TFTP server activity.

On the final outcome, the access point can now operate in autonomous mode with a full fledge IOS that enables it to function in stand alone.

Enjoy!

Ever wondered how to provide remote desktop support to one of your non-techie friends who have a problem using their computer. If they are directly connected to the Internet meaning have public IP address assigned to them then this should be a cinch. We have Windows Remote Desktop and a plethora of VNC program to support this.

But how about if they are connected in an internal network where private network address is used as well NATting their environment prior to reaching the Internet. There are also some ISP out there still providing users in the private addressing space. How do you go about supporting them in case they need your help? Their network administrator as well as security guys would not allow any special treatment for these machines being accessed from the Internet. Now we have a bit of a problem.

But not long ago, programs have been developed to address these concerns. Without disturbing the current infrastructure, clients can be remote accessed and controlled by users outside the network. One particular program I have recently used and liked is theTeamviewer.

One good this about this program is that it is free for non-commercial use meaning normal users like you and I can use the program to be able to provide free remote desktop sharing. Simply downloading and installing the program is fairly straightforward. It has also a light version called Teamviewer Quick Support which does not require any installation and can be run in order to allow users to connect to the user’s desktop.

One the program is installed, running it will show you the main interface:

One the main interface, one can see the “Your Details” section which has the ID and Password (numeric password). These are the credentials required to be sent over to the user requiring remote desktop access to the client. This can be sent via IM or voice call. The Teamviewer mode below explains the type of access allowed for the remote user. Another in the main interface is the “Partner Details” which is used as entry for the ID of the remote client which will be connected if this host will act as the machine that is going to connect. Nifty aint it

One thing people should notice why this program works even if it is inside an internal network is because of a small program called DynGate which runs in the background. It is mainly responsible for the connectivity for the remote desktop access. This program requires outbound access via port 80 to an external IP address which is normally the case for every hosts requiring Internet access. Using the program tcpview, we can see how the program connected to the Internet.

.

Though they state in their clause once the connection is established between the hosts, the line is secured using an encrypted channel and Teamviewers systems cannot decipher this traffic. Some people will raise security and privacy concerns on this. However, since its free and you only utilized it in certain occassions it would not be an issue to me. I would just terminate the program once done.

I encountered a problem with wireless device (ipw2200) in my Gentoo laptop after upgrading its firmware. Here is the error what i got from the system:

ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, git-1.0.8
ipw2200: Copyright(c) 2003-2005 Intel Corporation
ACPI: PCI Interrupt 0000:06:06.0[A] -> GSI 18 (level, low) -> IRQ 177
ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
ipw2200: ipw-2.4-boot.fw load failed: Reason -2
ipw2200: Unable to load firmware: -2
ipw2200: failed to register network device

After searching the net for solution, I stumbled upon a Blog which had the same problem and proposed the solution, see
Eric’s Blog on fixing it

After following the recommended steps:

1. Create a file /etc/udev/rules.d/999-firmware.rules and add the text below and save.

ACTION=="add", SUBSYSTEM=="firmware", RUN+="/sbin/firmware_helper"

Note: the program firmware_helper needs to be installed (check by using which firmware_helper)

2. Unload and reload the modules for the wireless:

# rmmod ipw2200
# rmmod ieee80211
# rmmod ieee80211_crypt
# modprobe ipw2200
# modprobe ieee80211_crypt

3.Check the output of dmesg.

ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, git-1.0.8
ipw2200: Copyright(c) 2003-2005 Intel Corporation
ACPI: PCI Interrupt 0000:06:06.0[A] -> GSI 18 (level, low) -> IRQ 177
ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection

If you get the output above, then your good to go.

IPSec VPN is still a mystery to me but this incident with one of our clients who just purchased an Symantec appliance (SGS 5420) had problems connecting via IPSec to the another corporate network which uses a Cisco PIX device. The problem situated more than 3 weeks with the Symantec vendor third party support cannot establish an IPSec tunnel with the Cisco device.

Taking our notes together, we tried connecting the SGS device to PIX firewall which we luckily have. And finally we got the IPSec tunnel established. The technical details for each system are discussed below:

The extensive testing has shown that it basically comes down to the global IKE parameter, the Phase 1 ID. This is better known within the Cisco configuration as isakmp identity key-id. This parameter has to be the same for both sites.

Extensive testing has proven that:

* The Diffie-Hellman group has no influence. As long they’re the same on both sides. (tested with group 1 and group 2)
* The hostname has no influence.
* The length of the PSK has no influence. As long as it is minimum 20 characters.

Cisco PIX Configuration
——-
sysopt connection permit-ipsec
# IPSec Policy
crypto ipsec transform-set SITE1-Policy esp-3des esp-md5-hmac
# Map IPSec policy to allowed site to connect
crypto map 20 ipsec-isakmp
crypto map SITE1-to-SITE2 20 match address ACL_Site1
crypto map SITE1-to-SITE2 20 set peer Site1 IP Address
crypto map SITE1-to-SITE2 20 set transform-set SITE1-Policy
crypto map SITE1-to-SITE2 interface outside

# ISAKMP Configuration
isakmp enable outside
isakmp key ******** address Site1 IP Address netmask 255.255.255.255
# This value must be set for 3rd party VPN headend device
isakmp identity key-id test
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400

—–
from the Cisco PIX Firewall Command Reference, Version 6.3

isakmp identity key-id value

The isakmp identity key-id key_id_string command sends the specified key_id_string using aggressive mode. This is intended to enable
third-party VPN headend devices that do not support the Unity protocol to interoperate with a DHCP-enabled firewall at a remote site.

For debugging in the Cisco PIX, use “debug crypto isakmp” and “show isakmp log” and wait for the output to reach “ISAKMP (0): Creating IPSec SAs” and a value 1 for created tunnel.