Home Page

All the Graphics



Internet Sharing Solutions (Part 4)
By Thiravudh Khoman

(If you haven't read Part 3 of this series where I introduced WinRoute Pro, please read it first. Part 4 is pretty advanced stuff.)

When I gave AnalogX to my computer buddy Petch to try out at his workplace, I warned him that one problem he would face would be limiting the number of users who would want to use it once the news got out. This isn't a major problem in small companies where access is naturally limited by the number of computers on the network. But in larger organizations with potentially hundreds of networked computers, it wouldn't take long before the system slowed down to a point where it was unusable. The problem is rooted in the fact that AnalogX being the simple program that it is, has no way to prevent users from piggybacking onto the system. Fortunately, WinRoute Pro (WRP) does.

Setting the Admin Password

Before we do anything, we should first set a password for the WRP administrator, someting we didn't to do in Part 3. Leaving admin without a password cancels out any possible security we could add to WRP since someone could log into WinRoute Administration as "admin" and make changes. So, go to "WinRoute Administration", click "Accounts", highlight the user "admin", click "Edit", and give admin a good password (one that can be remembered, of course) (figure 1).

Limiting Proxy Access

As I mentioned in Part 3, WRP has two methods of accessing the internet: a) NAT mode and b) Proxy mode. In a highly controlled environment, one should prevent users from using NAT (where possible) and force everyone to go through the proxy server. Exceptions could be made to allow users with special needs (or special powers?) to run in NAT mode; for example, to run programs using protocols not supported in proxy mode or to allow said powers-that-be to surf the net "untracked".

I'm going to do this backwards and discuss proxy mode first because it's a lot easier. In proxy mode, access is governed by a list of restricted sites and "exception" users who are allowed to bypass those restrictions.

First, we should define users whom we will allow to bypass site restrictions (there's no need to define users who will be restricted). In "WinRoute Administration", click "Accounts" and you will be presented with a user definition screen. Click the "Add" button to start adding users, giving them appropriate passwords. Under "User Rights", make sure the radio button next to "No access to administration" is selected for everyone except user "admin". When finished defining users, click the "Groups" tab and add a group called "Okay". In "member rights", no one should have rights to "remote administration" either. Next, add all of the users previously defined into the "Okay" group. To do this, highlight the group "Okay" and then highlight each user and click the "<< Add" button (figure 2).

Click "Apply" and that's it for defining users and groups. Now, go to "Settings", "Proxy Server", and "Access". Click the "Insert" button and create the URL * (i.e. a single asterisk). We've just created a rule which prevents access to ALL - repeat, ALL - web sites. To allow our "Okay" group to override this "rule", we just highlight the "Okay" group in the "Avail. Users/Groups" window and click the "<< Add" button. Click "Apply" and that's it (figure 3). Everyone in the "Okay" group now has access to all websites, while everyone not in "Okay" (none so far) can't go anywhere at all.

Actually, it doesn't quite work that way, but close enough. Load Netscape from a client PC, making sure it's still operating in proxy mode, and then try and load https://www.yahoo.com. A window will pop up saying "Proxy authentication required for admin at" and will ask for a user name and password (figure 4). You may enter the name and password of any person in the "Okay" group and Yahoo! will be displayed. Give a wrong name and/or password and you will be denied. Giving a name that doesn't exist in WRP's user database will also deny you.

If you mistype either a name or a password, your "denied" status will be "remembered" and you will not be able to continue anywhere. In this event, just quit and restart your browser. Likewise, if a correct name/password is given, your "authorized" status will be "remembered" and you will not be asked to enter a name/password again (at least not by the proxy server). By the way - very important - both the user name and the passwords are case sensitive.

What we've done is pretty rough. You can, of course, finetune the site restrictions a lot more than this.

Limiting NAT Access

At this stage, it's not difficult to circumvent proxy mode. In Netscape, all you do is set "Direct connection to the Internet" in the proxy preferences, and you're running in NAT mode free of any proxy restrictions. Also, try using a mail program like Eudora. It works! Why? Because it doesn't use the proxy at all. Obviously some additional controls have to be put in place.

What we need to do is to restrict what can be done under NAT mode. We do this using WRP's "packet filter" or "firewall" feature. Log into "WinRoute Administration", "Settings", "Advanced", and "Packet Filter". You will see two tabs: "Incoming" and "Outgoing" and also two interfaces: your LAN card and your RAS device (often a modem, but not always). What we're going to do here is to set "rules" governing what will be allowed or denied when a data packet is incoming to or outgoing from either interface.

To make matters simpler (massive understatement!), let me show you how I've set up packet filtering for a fairly restrictive environment. Under the "Incoming" tab, my LAN card has the following rules (figure 5):

    Allowed: TCP FTPPC all ports => any host port=20
    Allowed: TCP FTPPC all ports => any host port=21
    Allowed: TCP any host all ports => any host port=25
    Allowed: TCP any host all ports => any host port=110
    Allowed: TCP any host all ports => WRHOST port=3128
    Denied: TCP any host all ports => any host all ports

Note: I've defined two "Address Groups" (WRP's terminology) here. FTPPC is a PC with the fixed IP address 192.168.200, while WRHOST is the WRP host PC, whose IP address is These are just nicknames or aliases used in place of IP addresses. They make the rules easier to read and maintain.

What does all this mean?

  1. Lines 1 and 2 allow TCP packets from the FTPPC PC that are destined for ports 20 or 21 at any host on the internet to get through the firewall in NAT mode. Translation: This allows anyone sitting at the FTPPC computer to use an FTP client like WS_FTP or CuteFTP to access any FTP server on the internet. Because FTP transfers can be pretty big, only this computer is allowed to FTP in this manner. (Technical Note: FTP's which take place through a browser aren't true FTP's; they're actually converted to and accomplished by HTTP.)
  2. Lines 3 and 4 allow any TCP packets headed for an SMTP server (port 25) or a POP3 server (port 110) to be able to get through the firewall, also under NAT. Translation: This allows ANYONE to check and send mail from a mail client such as Eudora or Outlook. We didn't put in any restrictions here on who can send/receive email on the assumption that POP email tends to be "light".
  3. Line 5 allows TCP packets headed for the WRP host's proxy server ( port 3128) to reach there unimpeded. Translation: Although any packet may go to the proxy server, the most important will be port 80 packets from web browsers. This doesn't mean though, that the proxy server will know how to handle all the packets that go there. If it doesn't, the packets will just die here. At present, only port 80 packets will be properly handled.
  4. Line 6 is an "Otherwise" rule. All packets which have filtered through the previous 5 rules will be denied entry. For example, a port 80 packet (i.e. web browsing) heading directly for Yahoo! will be denied here, as will a port 20 or 21 packet (i.e. ftp) from any computer other than FTPPC.

Under the outgoing tab, my RAS device has the following rules (figure 6):

    Allowed: TCP WRHOST port=80 => any host all ports
    Denied: TCP any host port=80 => any post all ports

What does this mean?

  1. Line 1 allows TCP packets originating from port 80 (i.e. web browsing) of the WRP host to get through to any host on the internet via the WRP host's modem. Translation: Any web browsing request allowed through the proxy server unimpeded by user/site restrictions will go out to the RAS device/modem here.
  2. Line 2 denies any port 80 packets from any other host other than the WRP HOST (i.e. the proxy server) from getting onto the internet via the modem. Translation: Proxy-less web browsing will not be allowed to pass through the modem.

It should be noted that the last line is NOT an "Otherwise" statement. If the proxy server saw fit to send a non-port 80 packet, it WILL be allowed through. At present though, the proxy server only handles port 80 packets.

Also, notice that port 20/21 (ftp) and 25/110 (SMTP/POP3) packets which were allowed in from the LAN card can exit via the modem here as well, since there are no rules to deny them.


This is pretty difficult stuff, at least for people who aren't accustomed to configuring routers, and I don't deny having trouble with it myself. But basically the firewall shown above allows and disallows the following:

  • Allows true FTP'ing via NAT from the FTPPC computer only
  • Allows anyone to use send and receive email via NAT
  • Allows web browsing via the proxy server only
  • Allows FTP'ing via the web browser/proxy server (not true FTP'ing)
  • Disallows web browsing via NAT
  • Disallows everything else not allowed by the above
Consider well that last sentence. Programs like ICQ, IRC, videoconferencing, etc. will NOT be able to penetrate the firewall as currently configured. In fact, an entry/exit must be created for EVERY new program. Adding support for ICQ in fact is not a trivial undertaking, and requires the use of another technical tool called "port mapping".

What I'm suggesting, of course, is that it's easier NOT to use a firewall unless it's absolutely necessary. Security is rarely an easy task.

Copyright © 1998-2000, Thiravudh Khoman