[ anders ]
[ resume ]
[ choppers ]
[ projects ]
[ netatalk ]
[ route66 ]
[ webgallery ]
[ mockMarket ]
[ merits ]
[ dailyBulletin ]
[ panacea ]
[ words ]
[ pictures ]
[ movies ]
[ contact ]
HOWTO: Getting on the net
By Anders Brownworth
"Yeah, so Linux is great and all, but I want to get on the Net!" Well, we're going to one-up you here, not only will we show you how to get your new Linux box on the Internet, but also how to get the rest of the computers on your home network to access the Internet at the same time! Yeah, we don't fool around.
I have had the distinct pleasure of playing with quite a few different Linux setups that deal with connecting machines to the Internet. Initially they just involved connecting one machine to the Internet via a modem or ISDN circuit, but quickly evolved into routing multiple IP addresses through a PPP or hiding entire networks behind one real Internet address. In this article, I will show by example how to do all of this so get ready to play!
There are three general ways I will discuss to get connected to the Internet, each more involved than the last.
Masquerading vs. IP routing - what should you use?
M is easier. - IP more involved. (requires special settings at ISP)
M won't do non-standard ports - IP does all ports
No inbound connections with M - IP supports inbound traffic
Making one machine pick up the phone and connect to the net is fairly straightforward, and with RedHat, it's really a piece of cake. The fun begins when we start to get a home network on the Internet. By far the easiest way to do this is through a masquerading firewall. In a nutshell, your Linux machine would make Internet requests for the other computers on your home network. In a sense, your other computers aren't really on the Internet, but they can access it through your Linux box. A side effect of masquerading is the fact that other computers out on the Internet can't establish connections with the computers on your home network, which turns out to be a good thing because it would be fairly hard to hack a machine you can't directly connect with.
If you have an ISP that will allocate and route you multiple static IP addresses, or one of the tech guys at an ISP owes you a favor, you could try sending an entire set of real IP addresses through your phone line! If you are that crazy, then all computers on your home network would have a real Internet IP address and would use your Linux box as a gateway.
What is a firewall?
A Firewall is a break point between networks where all traffic is examined and accepted or denied based on a set of rules. They are used to grant some measure of security in a network. By placing a firewall between a home network and the Internet, you block connections to your home machines originating from the Internet while still letting all your machines use the Internet.
Masquerading is probably the most popular choice because it doesn't require the cooperation of your ISP to get things going.
Connecting one box to the Internet
Getting connected your Linux box to the Internet through an ISP is very simple thanks to RedHat's netcfg program. The only things you will need are a RedHat box running X-Windows, an ISP account and a phone line. (could even be an ISDN terminal adapter actually)
To start out, you will want to be logged into your system as root and running X-Windows. (use "startx" to launch X-Windows) Launch the netcfg tool by opening a terminal window and typeing "netcfg". You should see RedHat's Network Configurator. Click the Interfaces button. Everything we do will be centered around this section.
The interfaces panel lists all the network interfaces that are configured in your system. You can ignore "lo", the local loopback device. "eth0" is your ethernet card. We are going to add a "ppp0" device to deal with your Internet connection, so click "Add". Choose "PPP" from the window that pops up, and enter your local access phone number, username and password in the following box. There are additional items hidden behind the "Customize" button that you will probably need to fool with. One of the most important things is where your modem lives. "/dev/modem" is the default, but that isn't defined in a standard RedHat install so you are probably going to want to pick one of the alternate modem port settings. Use the tty chart to figure out what port you should select.
DOS - UNIX
COM1 - /dev/ttyS0
COM2 - /dev/ttyS1
COM3 - /dev/ttyS2 *
COM4 - /dev/ttyS3 *
/dev/ttyS2 and /dev/ttyS3 sometimes require special setup, so try to avoid them
Under the communications button you can see the script that will be executed as the login session progresses. If you are having problems later, come back here and switch on "debug connection".
The networking button holds some fairly slick features such as the ability to launch the PPP when your system starts, or the ability to restart the PPP automatically when the line drops. Set these according to taste.
Most ISPs will accept the clear-text login that we have just created, but some ISPs may use PAP (password Authentication Protocol) instead of a clear-text login. In this case, you will need to edit the PAP area of the the PPP interface editor. More information on this may be found at:
What's PAP anyway?
With a PAP login, a PPP session is started before the username / password is transmitted. PAP is a password authentication scheme supported by PPP. Conversely a clear-text login would deal with passwords (in clear-text ;) before the PPP is started.
After you have everything the way you want it, click "Done" on that window and click "Save" in the box that appears. Now you should see an additional PPP interface listed in your Interfaces section. You will notice that it says "no" in the active column. With the PPP line selected, click "Activate" and your modem should pick up and connect.
More info on getting your PPP established can be found at:
Connecting the rest of your home network
what is Masquerading?
Since the only computer on your home network to have a real Internet IP address is your Linux box, your Linux box will have to make requests on the Internet for the other computers on your network. In a sense, it masquerades around as your other computers so your other computers don't need to have a real Internet IP address.
Now comes the fun part! In order for your other home computers to access the Internet through your Linux box, you need to have them on an ethernet network. There are a few blocks of Internet addresses set aside for "fake nets" or networks with essentially illegal IP addresses. In these examples we will use the 192.168.1.* network.
Each of the computers on your network has to have a different IP address. Tradition seems to dictate that 192.168.1.1 be the router, or in our case, our Linux box, so set a different IP address in each of your other computers and set their gateway to be the Linux box at 192.168.1.1. The netmask for all the 192.168.1.* machines will also be 255.255.255.0. (note, this includes your Linux box.) You should also setup DNS on your other computers to point to a valid DNS server.
Use the Network Configurator to edit the interface "eth0" and give it the 192.168.1.1 IP address and 255.255.255.0 netmask. Make sure you can ping the other machines on your ethernet.
To masquerade, we need to have IP forwarding compiled in the kernel. Luckily for us, RedHat has already done that! All we need to do are the following three lines:
ipchains -P forward DENY
ipchains -A forward -i ppp0 -j MASQ
echo 1 > /proc/sys/net/ipv4/ip_forward
ipchains is a program which manipulates the kernel's firewall and forwarding tables. You can see more information about this command by doing a "man ipchains" or look at the ipchains HOWTO at:
Now all that's left is to test this setup. Go to one of your other computers on your home network and start a web browser. If all is well, you should be able to just type in a URL and you should see the page come up.
So what if it doesn't work? First make sure you can reach your Linux box over the network. Do a ping to 192.168.1.1 and make sure you get responses. If not, your problem lies in your home network. Try deleting and re-installing your eth0 interface in the netcfg tool and look at your IP setup on your other home computers. If all goes well with the ping, from the server, make sure you can ping the website you are trying to reach. If that fails, check your PPP setup. If that works for you, try looking at the masquerading section of the ipchains HOWTO (link above) as it goes into more detail.
So how does this all work? Well your client machine (say 192.168.1.2) wants to get http://www.linux.com/ so it looks up the IP address. The response is given: 18.104.22.168 so the client asks it's gateway (192.168.1.1) for this IP address because it doesn't exist on the local network. The gateway (your masquerading Linux box) rewrites the header of that packet to say that it originated from the ppp0 interface on the Linux box and sends it on it's way. A few milibleams later, the response comes back. Your trusty masqerading firewall remembers that it had rewritten a request to this hosts, so it again rewrites the packet header to say that the destination is your client at 192.168.1.2 and sends it over your home network back to the web browser, and the page is rendered! Cool, huh?
Hardcore: IP subnet routeing
Remember that really good tech friend at your ISP that loves to play with Cisco routers in his free time? Well, you are going to need to call that guy and ask for a few static IP addresses that sit nicely on a subnet boundary if you are going to try this. (wireless PCMCIA cards and stations work well as bribes) Of course if you go hardcore, you will have real Internet addresses on all the machines on your home network and you will be able to directly connect from anywhere in the world to any of your home machines. This has it's advantages because you could mount and have unrestricted access to one of your home network's drives from anywhere in the world. Quite handy at times.
While connecting a school to the Internet, I got the 22.214.171.124 subnet of 16 IP addresses from Steve, my trusty ISP tech guy. Essentially I had the 14 IP addresses from 126.96.36.199 through 188.8.131.52 to play with. (with a netmask of 255.255.255.240, 184.108.40.206 refers to the network and 220.127.116.11 is a broadcast address for this network so those two addresses couldn't be used.) Steve made it so that when I dialed in, all traffic destined for this network ended up going through the ppp0 connection to 18.104.22.168, my "software router".
That coordination was actually the hardest part because after that all I needed to do was add the following route as follows:
/sbin/route add -net 22.214.171.124 netmask 255.255.255.240 dev eth0
I had IP gatewaying and forwarding compiled into the kernel on the router. When I connected to the Internet, my default route on the router machine would be set to the ppp device. When a packet for 126.96.36.199 would come in on the ppp, the kernel would look at it against the route entry above, and see that it fell within the 188.8.131.52 network and then send it out the eth0 device. The important difference here from what we were doing before is in this scenario, the packet headers don't get rewritten, but rather the unchanged packet gets gatewayed to the local ethernet. Of course all the clients on this local ethernet have a valid IP address within my 184.108.40.206 network with 220.127.116.11 set as the gateway. Likewise, packets originating from the inside machines were sent to the gateway (18.104.22.168) which gatewayed those packets out it's default route, the ppp0 device, to the rest of the Internet.
Even more hardcore!
For The Stony Brook School, a private high school in New York, I set up Internet connectivity and a campus network. I had to give the students filtered Internet access, and did I want to open up the possibility for a student to hack the academic office server and change their grades. With a pile of old re-purposed computers and a few extra network cards, I was able to implement several segmented ethernets throughout the school.
Each building had "privileged" and "unprivileged" LANs. The privileged LANs had unblocked web access and access to other privileged LANs while the unprivileged LANs had filtered Internet access and weren't allowed to transmit packets on the privileged LANs. Buildings were linked by long ethernet runs through tunnels connecting each main building router. All inter-building connections were TCP only, so other protocols such as AppleTalk and IPX were encapsulated in TCP and in some cases (depending on the sensitivity of the network) encrypted. Students, while blissfully unaware of the network, could surf the net and use email, while teachers could login to academic office servers in another building all over an essentially public inter-building network connection. After the whole project was done, I had spent something like $2000, mostly in ethernet cable and network cards!
I assigned "fake net" (192.168.*.*) addresses to each of the ethernet segments. Each Linux box had at least 3 ethernet cards in it with fairly vanilla route tables. I used ssh to establish secure tunnels between the privileged LANs. Ipxtunneld was used to encapsulate IPX traffic in TCP to be sent through the tunnels to the other routers for de-encapsulation and decryption. I used netatalk (an appletalk fileserver for linux) to route AppleTalk. I used UAR (unix appletalk router) to encapsulate AppleTalk packets within IP. (at one point, I even had a UAR node at my house so I could browse the internal school network in native appletalk from home!)
Of course, I could go on forever but I guess that's off topic
Other things you might be interested in:
Diald - automatically fires up the ppp connection when someone makes an internet request, and closes it if it is unused for a predetermined amount of time.
SOCKS proxy server - if you want a bit more control, you could implement a true firewall with a SOCKS server.
Other resources for information:
Redhat specific manual routeing: http://www.redhat.com/corp/support/docs/Network-Config-Tips/Network-Config-Tips.html
Redhat specific PPP setup tips: http://www.redhat.com/corp/support/docs/PPP-Client-Tips/PPP-Client-Tips.html