How to: Deploy Wireless Hotspot?

Public hotspots provide an easy method for customers to connect to the Internet. With the increasing number of people emailing, chatting, shopping, uploading and downloading files, surfing the web, and playing games across the Internet, wireless network access is an attractive draw for customers and could potentially lead them to choose one place of business over another. Business travelers can work from their hotel rooms, and special events staff can update schedules, locations, results, and specialized content to their customers without installing kiosks and having lines queued up waiting for a terminal to become available. Employees can work from a local coffee shop while enjoying a caf latte or cup of tea. These benefits offer a revenue opportunity for both the service provider and the owner of the site.

Functionally, a public hotspot is a readily available wireless network connection where users withcompatible wireless network devices such as PDAs, cell phones, notebook computers, or handheldgames can connect to the Internet, send and receive email, and download files all without beingencumbered by Ethernet cables. The hotspot can be temporary or permanent in nature: a trade showthat runs over 3 days or at a local coffee shop, respectively, but should always mimic the user'snative environment with respect to functionality and security. In other words, the hotspot should beinvisible to the user in every respect, other than making the initial connection to the network.

A hotspot is made up of some or all of the following components:

• Mobile Station(s)
• Access Point(s)
• Switches, Routers, Network Access Controller
• Web Server
• Authorization, Authentication and Accounting (AAA) Server
• High-speed Internet connection such as DSL or T1/T3 (WAN backhaul)
• Internet Service Provider (ISP)
• Wireless ISP

Some important features and functionality that a hotspot needs to provide are listed below:

• Enabling access to the wireless link - Providing the mobile station with information about the wireless network - Creating an association with the mobile station - Providing access to the local network - Providing data packet transfer services - Disassociation from the mobile station
• Provisioning the hotspot - Page redirection function - Mobile station authentication - User authorization
• Layer 3 (IP) Address Management - Providing an IP address for the mobile device - Private to public address translation if necessary - Providing Domain Name Services (DNS) - Providing information about gateways
• Providing access to hotspot LAN
• Providing access to the WAN
• Protecting user data privacy
• Provide accounting information (keep track of user network usage)

Some of these functions are provided by a single hotspot network component while others are implemented through the collaboration or combination of two or more components.

Wireless Hotspot Network Architecture :

Wireless hotspot network architecture

How to Add a second Router to your LAN

How to properly add a second (or third) router to an existing LAN that already has a SOHO router connected to the internet.  I'm going to write out a brief guide so the next time it comes up, I can just post a link to this instead of typing it all out again!

The general setup of SOHO Router's is similar.  While some use a different subnet, every one I've worked with uses a Class C Private IP Addressing Scheme.  I'm going to use the basic Class C private for this tutorial (192.168.0.0)

I'm going to give two setup guides: 

Version 1 will be for a simple, single subnet setup

Version 2 will be cover separate subnets

The term “Router1” will refer to the router connected to the internet.  Any others (ie: Router2, Router3) will be downstream of Router1

Version 1:
========

 When connecting a second router to an existing LAN it’s easiest to connect LAN port to LAN port and configure the LAN side of the downstream router as compared to connecting to the WAN side.

Router1 (LAN Side):

IP: 192.168.0.1

SM: 255.255.255.0

DHCP Enabled = Yes

DHCP Scope: 192.168.0.100 to 192.168.0.199

Router2 (LAN Side):

IP: 192.168.0.2

SM: 255.255.255.0

Default Gateway: 192.168.0.1

DHCP Enabled = No

You will note in the above configuration that the LAN IP of Router2 is within the same subnet as Router1 but is outside of the DHCP Scope defined on Router1.  This is important.  If you use an IP within the scope, the DHCP service may attempt to give that IP to another computer you plug into your network.  Using an IP outside of the scope avoids this potential problem.  Also, devices like Routers, Servers, network printers should always have a statically assigned IP address so that the IP never changes.

If you have everything configured correctly, any computer plugged into Router2 will get an IP from the DHCP service on Router1 and will have full LAN and internet connectivity.

The DHCP Scope’s Default Gateway IP address should point at Router1 (192.168.0.1) as it is the gateway to the internet.

If you need to add another router, or two or three, simply set the LAN IP on Router3 to 192.168.0.3 and configure all other TCP/IP settings the same as Router2.  Do the same for any others you may add.  I would like to point out, using a switch makes more sense than using a router as a switch requires no setup.

Version 2:

========

When you wish to have a separate, and secure, LAN attached to your existing network you will need to segregate the new LAN using a different, and separate subnet.  In order to do this, and provide internet connectivity (without providing connectivity between the two LAN’s) you will need to configure your downstream router (Router2) and use routing to go between subnets.  In this case, you will use the WAN port on Router2 to connect to the upstream router (Router1).

Router1 (LAN Side):

IP: 192.168.0.1

SM: 255.255.255.0

DHCP Enabled = Yes

DHCP Scope: 192.168.0.100 to 192.168.0.199

Router2 (WAN Side):

IP: 192.168.0.2

SM: 255.255.255.0

Default Gateway: 192.168.0.1

Router2 (LAN Side):

IP: 192.168.1.1

SM: 255.255.255.0

DHCP Enabled = Yes

DHCP Scope: 192.168.1.100 to 192.168.1.199

Every SOHO Router I’ve setup like this configured the route between subnets automatically when both the WAN and LAN side are configured correctly.  It’s simple enough to find out if it’s working, plug a PC into a LAN port on Router2, if you can access the internet, it’s working.  If you can’t, you may need to check the routing table to ensure you have the route between the two subnets (WAN and LAN side) properly configured.

Once setup and working properly, the 192.168.1.0/24 LAN will have internet access, connectivity with anything else plugged into Router2 but will not have access to anything plugged in to Router1.  The reverse is true also, computers plugged into Router1 will have internet access and LAN access to devices plugged into Router1.  But they will not have access to anything plugged into Router2.

How to recover a PIX Firewall password

If you ever lose a password on a PIX Firewall and need to recover it, follow these steps:

if you ever need to recover a password on the PIX
here are the steps:

Requirements:

* You will need a console connection from the PIX to your machine
* You will need a TFTP server application running on your machine
(I personally use tftpd32, which can be downloaded for free
at http://tftpd32.jounin.net/)

1) Connect the console cable to your serial port and plug the RJ45 end
into the PIX port marked "Console". You can use Hypertrm (which comes
with Windows) or any other console program of your choice. I use
TeraTerm Pro, found at http://www.ayera.com/teraterm/.

2) Find out what version of software is running on your PIX. If you're

not sure, you can find out very easy in the following way. If you
are connected to the PIX via a console connection, simply reboot the
PIX and watch for the output. It will tell you which version is
running.

3) Download the corresponding helper binary file from Cisco, depending
on which software version is running on the PIX. For example, if you
were running version 6.3(x) you could use the file called np63.bin found
here: http://www.cisco.com/warp/public/11... If you were running
6.2 you could simply change the last characters on the above url to be
np62.bin. Download that file and save it to the root directory of your
TFTP application.

4) Next, reboot the PIX again and immediately after the reboot as it is
coming back up and displaying text in your console send a break sequence
with your keyboard. If you are using Hyperterminal with Windows the break
sequence is Ctrl-Break.

5) This will send the PIX into "Monitor" status and you will see the following
prompt on the PIX:

monitor>

6) Patch your computer into the inside or outside interface on the PIX via a
standard CAT 5 cable (i.e. patch from your computers NIC to one of the PIX's
interfaces).

7) Give your computer an IP address. For this example, let's use 10.0.0.1
with a gateway of 255.0.0.0

8) Start up your TFTP server program and keep it running.

9) Tell the PIX which interface you will be connecting to, as follows:

monitor> interface 1

*note interface 1 is inside, interface 0 is outside, but you remember that
from reading the ebook right? :)

10) Give the PIX a temporary IP address on the same network as your computer,
as follows:

monitor> address 10.0.0.2

11) Tell the PIX the IP address of the TFTP server (your computer)

monitor> server 10.0.0.1

12) Tell the PIX which file to copy:

monitor> file np63.bin

13) Start the TFTP copy

monitor> tftp

14) It should copy very quickly. If it does not you will get
an error message on the PIX and potentially on the TFTP server
software. If you do get an error, you likely have a cabling
issue or perhaps a typo of one of the above commmands.

15) Once the file is copied to the PIX, the PIX will ask if you are
sure you want to reset the password. Type "Y" for yes, and the PIX
will reboot.

16) After the reboot the PIX will now have a default telnet password
of "cisco" (no quotes) and no enable password.

That's about it. About 10 minutes of downtime and you and your PIX Firewall are back in action!

How do I make

How do I make Web/HTTP work through my firewall?

There are three ways to do it.

1. Allow ``established'' connections out via a router, if you are using screening routers.

2. Use a web client that supports SOCKS, and run SOCKS on your bastion host.

3. Run some kind of proxy-capable web server on the bastion host. Some options include Squid, Apache, Netscape Proxy, and http-gw from the TIS firewall toolkit. Most of these can also proxy other protocols (such as gopher and ftp), and can cache objects fetched, which will also typically result in a performance boost for the users, and more efficient use of your connection to the Internet. Essentially all web clients (Mozilla, Internet Explorer, Lynx, etc.) have proxy server support built directly into them.

How do I make SSL work through the firewall?

SSL is a protocol that allows secure connections across the Internet. Typically, SSL is used to protect HTTP traffic. However, other protocols (such as telnet) can run atop SSL.
Enabling SSL through your firewall can be done the same way that you would allow HTTP traffic, if it's HTTP that you're using SSL to secure, which is usually true. The only difference is that instead of using something that will simply relay HTTP, you'll need something that can tunnel SSL. This is a feature present on most web object caches.
You can find out more about SSL from Netscape.

How do I make DNS work with a firewall?

Some organizations want to hide DNS names from the outside. Many experts don't think hiding DNS names is worthwhile, but if site/corporate policy mandates hiding domain names, this is one approach that is known to work. Another reason you may have to hide domain names is if you have a non-standard addressing scheme on your internal network. In that case, you have no choice but to hide those addresses. Don't fool yourself into thinking that if your DNS names are hidden that it will slow an attacker down much if they break into your firewall. Information about what is on your network is too easily gleaned from the networking layer itself. If you want an interesting demonstration of this, ping the subnet broadcast address on your LAN and then do an ``arp -a.'' Note also that hiding names in the DNS doesn't address the problem of host names ``leaking'' out in mail headers, news articles, etc.
This approach is one of many, and is useful for organizations that wish to hide their host names from the Internet. The success of this approach lies on the fact that DNS clients on a machine don't have to talk to a DNS server on that same machine. In other words, just because there's a DNS server on a machine, there's nothing wrong with (and there are often advantages to) redirecting that machine's DNS client activity to a DNS server on another machine.
First, you set up a DNS server on the bastion host that the outside world can talk to. You set this server up so that it claims to be authoritative for your domains. In fact, all this server knows is what you want the outside world to know; the names and addresses of your gateways, your wildcard MX records, and so forth. This is the ``public'' server.
Then, you set up a DNS server on an internal machine. This server also claims to be authoritative for your domains; unlike the public server, this one is telling the truth. This is your ``normal'' nameserver, into which you put all your ``normal'' DNS stuff. You also set this server up to forward queries that it can't resolve to the public server (using a ``forwarders'' line in /etc/named.boot on a Unix machine, for example).
Finally, you set up all your DNS clients (the /etc/resolv.conf file on a Unix box, for instance), including the ones on the machine with the public server, to use the internal server. This is the key.
An internal client asking about an internal host asks the internal server, and gets an answer; an internal client asking about an external host asks the internal server, which asks the public server, which asks the Internet, and the answer is relayed back. A client on the public server works just the same way. An external client, however, asking about an internal host gets back the ``restricted'' answer from the public server.
This approach assumes that there's a packet filtering firewall between these two servers that will allow them to talk DNS to each other, but otherwise restricts DNS between other hosts.
Another trick that's useful in this scheme is to employ wildcard PTR records in your IN-ADDR.ARPA domains. These cause an an address-to-name lookup for any of your non-public hosts to return something like ``unknown.YOUR.DOMAIN'' rather than an error. This satisfies anonymous FTP sites like ftp.uu.net that insist on having a name for the machines they talk to. This may fail when talking to sites that do a DNS cross-check in which the host name is matched against its address and vice versa.

How do I make FTP work through my firewall?

Generally, making FTP work through the firewall is done either using a proxy server such as the firewall toolkit's ftp-gw or by permitting incoming connections to the network at a restricted port range, and otherwise restricting incoming connections using something like ``established'' screening rules. The FTP client is then modified to bind the data port to a port within that range. This entails being able to modify the FTP client application on internal hosts.
In some cases, if FTP downloads are all you wish to support, you might want to consider declaring FTP a ``dead protocol'' and letting you users download files via the Web instead. The user interface certainly is nicer, and it gets around the ugly callback port problem. If you choose the FTP-via-Web approach, your users will be unable to FTP files out, which, depending on what you are trying to accomplish, may be a problem.
A different approach is to use the FTP ``PASV'' option to indicate that the remote FTP server should permit the client to initiate connections. The PASV approach assumes that the FTP server on the remote system supports that operation. (See ``Firewall-Friendly FTP'' [1].)
Other sites prefer to build client versions of the FTP program that are linked against a SOCKS library.

How do I make Telnet work through my firewall?

Telnet is generally supported either by using an application proxy such as the firewall toolkit's tn-gw, or by simply configuring a router to permit outgoing connections using something like the ``established'' screening rules. Application proxies could be in the form of a standalone proxy running on the bastion host, or in the form of a SOCKS server and a modified client.

How to configure OSPF step by step?

OSPF short for Open Shortest Path First is a Routing Protocol used to select the best suitable route for packets with in the network. OSPF basically an open standard protocol and not relate to any particular vendor. OSPF propagate the changes to all networks more quickly as compare to RIP and IGRP protocols then only send the changed part of the routing table to the other routers with in their area. We can decrease the size of routing table by dividing a big network into logically small segment using its area feature. OSPF protocol check the availability of others routers in the network by sending Hello packets, if the other router does not respond then it is assumed to be dead router. When you used OSPF for single area configuration, its configuration method is slightly differs from the RIP and IGRP.

There are some common OSPF configuration and Executable commands:

OSPF configuration on Router A

In global configuration mode

Router-A(config) # router ospf 1 (Here 1 indicate the process identification number)

Router-A(config-Router) # network 20.0.0.0 0.255.255.255 area 0 (Here 20.0.0.0 indicate the network ID and 0.225.255.255 wildcard mask with area 0)

Router-A(config-Router) # network 40.0.0.0 0.255.255.255 area 1 (Here 40.0.0.0 indicate the network ID and 0.225.255.255 wildcard mask with area 1)

OSPF configuration on Router B

In global configuration mode

Router-B(config) # router ospf 1 (Here 1 indicate the process identification number)

Router-B(config-Router) # network 20.0.0.0 0.255.255.255 area 0 (Here 20.0.0.0 indicate the network ID and 0.225.255.255 wildcard mask with area 0)

Router-B(config-Router) # network 30.0.0.0 0.255.255.255 area 1 (Here 30.0.0.0 indicate the network ID and 0.225.255.255 wildcard mask with area 1)

Now on both routers each Network will be added automatically, you can ping to Router A and Router B to check communication. You can verify this on Router-A or Router-B by using command Router# ping 40.0.0.10 (ping for Router B) and Router # ping 30.0.0.20 (ping for router A).