Let’s assess the situation: You have a 3G phone which allows tethering, a windows machine, a wireless access point and another PC that is connected to the LAN port of the wireless access point (or typically called a wireless router). The wireless access point is a home network and your ISP decides to disconnect your signal or is experiencing some problems. How do you share your 3G connection, so that other computers can connect through the wireless AP and use your cell phone’s 3G connection? It’s actually quite simple.

Tether your smartphone (in this case let’s say blackberry). Blackberry tethering in Windows over AT&T is allowed using a software called AT&T Communication Manager. Install ACM, and connect your Windows machine using a mini-USB cable to your phone. Goto Start->Run->cmd.exe. Type ipconfig /all to see the IP address and the DNS servers IP addresses.

Now connect the WAN link of your Wireless access point to this Windows machine’s ethernet port. Setup a static IP for this Windows machine say 192.168.10.1 with a netmask of 255.255.255.0. Now go to Network connections (from Control Panel), right click on the Mobile connection representing your blackberry, click on Advanced. In the Internet Connection Sharing section, check the box that says “Allow other network users to connect through this computer’s Internet connection” and select “Local Area Connection” (this is the same connection you connected to the WAN port of the wireless AP). Click OK. You may have to disconnect and reconnect your ACM connection to allow the settings to take effect.

Now that this is done, connect to the administration interface of the wireless access point to the other PC that is connected to the LAN port (or through the wireless) to the access point. Go to the administration interface of the wireless AP, and set a static IP for the router in the same subnet as with the Windows box (the one you set with 192.168.10.1). Set the static IP on the AP to be say 192.168.10.2 (remember this has to be the same subnet), netmask as 255.255.255.0 and then the most important, the default gateway to 192.168.10.1 (the IP of the windows box on the ethernet card). To set the DNS server addresses, use the same addresses you found using ipconfig /all in the first step. Otherwise you could also use open DNS servers or any other DNS servers but it’ll be best to use the DNS servers pointing to the ones used by the tethered connection because you can rule out DNS issues if something isn’t working and it comes down to troubleshooting. Once on the router, the static is set, the gateway is set, the DNS is set, you should be able to connect from your wireless network to the internet through your 3G connection! 🙂
Happy internet sharing! 🙂
Here is a schematic diagram:

[tethering]                [static IP]    [static IP]   [internal IP]  [DHCP address]
                                   |         |                |           |
[ phone ] <==> [Windows machine]:eth0 <==> wan:[Wireless AP]:lan <==> [client]

In the past few days, coincidentally I’ve been thrown into situations where packet forgery has been required. So I thought it’ll be a great moment to enumerate some good options that network or security professionals have. The basis for most of these tools lies in libnet and libpcap which are some of the most wonderfully functional libraries out there.

• Packetforge-ng – On the wireless side this utility allows you to capture wireless packets and create legitimate packets with a pre-determined payload that can then be replayed using tools such as aireplay-ng
• Scapy – This is a python based tool and can be extended to write custom Python scripts to custom create packets. This library has great functions to form packets layer-by-layer and other functions such as fuzz() that allow fuzzing of packets out of the box. The greatest utility comes by the use of python language to create custom tools. Imagine creating custom thick clients just by using simple python scripts. The capabilities with this library are endless!
• TCPReplay – Just convert your pcaps into traffic by replaying them. An excellent tool but be careful if you’ve sniffed some ARP packets. You could end up corrupting the ARP table entries (unless that’s exactly what your intentions is 😉
• file2air – An excellent tool by Joshua Wright to replay packet contents.
• Packit – A really easy to use and functional linux based packet injection tool.

SSH is an excellent piece of software which can help you do a lot of things such as have encrypted shells etc. But what makes SSH incredibly flexible is having tunnels.

A typical ssh tunnel works from the client to the ssh server and it forwards a local port on the client to the server seamlessly.

client ----> ssh_conn ----> ssh_server
client --> tunneled_port --> ssh_server

ssh -L 10000:localhost:10000 username@ssh_server

This connection creates a tunneled port on client:10000 i.e., anything sent to this port appears as if it’s automatically sent to ssh_server on port 10000. The localhost here is confusing, but think of it as….”what is localhost for ssh_server?”. It would be the ssh_server itself, right?
If you do a netstat on the client, you see a listener on the port 10000/tcp.

Now comes the more interesting reverse tunnel. The reverse tunnel is different in that, you have a tunnel being initiated by the client that says to the ssh server, “Hey, I’m initiating this connection that will allow you to automatically access a port on *me* after *I* initiate the connection?” (confused!!?!)

client ---> ssh_connection ---> server  ---+
                                           |
client <-- tunneled_port  <----- server ---+

ssh -NR 10000:localhost:10000 user@ssh_server

Here the meaning of localhost is slightly different, though.  The “localhost” means what is localhost for the client (and not on the server as in the previous case)!   So what you’re saying is, “Hey SSH server, I’m initiating this connection to you but if you connect to your port 10000 you will get a tunnel to *my* port 10000.”  If you do a netstat on the server you see a listener on port 10000. Isn’t it great that you can make the server listen to a port which acts as a tunnel to you…so anyone on the server can seamlessly connect to you even though technically you were the client!