"The Linux Gazette...making Linux just a little more fun!"

Drop-in Replacement for "WinGate"

From Paul A Pick on Mon, 22 Feb 1999

Hiya,

I have a win95/redhat5.2 dual boot system, which I use as a proxy server for one win95 client machine (as my system has the net connection).

Under win95, I use wingate for my proxy software... so my client's system is setup expecting things to be wingate-like on my system. The problem comes with the recent addition of redhat5.2. I want my linux box to be a transparent plug-in replacement for the win95/wingate config but I haven't really found the proxy software to do this.

So... my question is: are you aware of proxy software for linux which can behave like wingate? So far, I've seen squid (monstrous overkill) for ftp/http and then I have to add 'portfwd' (?) to map dns/pop and then there was another app for socks (req'd for telnet). All of this makes me want to run wingate via wine (which I will try soon, actually). [ Of course, I could just buy another system to do ipmasq/ipchains... ] Anyway... have I missed an obvious solution? Thanks, - Paul

I don't know what sort of proxying WinGate does. So I can't address the issue of a transparent, drop-in replacement for it.

Squid may be "monstrous overkill" for your situation. However, it will probably provide the key features you need and it doesn't take appreciably more memory, CPU, or (non-cache) disk space than any other proxying system. Apache can also be configured to act as a caching proxy web server.

You could get the SOCKS RPMs from any Red Hat "contrib" site/mirror. WinGate probably implements the SOCKS protocols (which govern how client software traverses a proxy; how it relays it's service requests through the proxy). There are also a couple of other SOCKS compatible proxy server packages for Linux including DeleGate, and Dante (find them both on Freshmeat at https://www.freshmeat.net).

You don't have to add ipportfw or autofw (or tcprelay or udprelay, or any of its cousins). These are all small utilities that can listen on a given TCP/UDP port and relay traffic to another system. They are more useful to virtual host servers on a private net.

Consider the following scenario:

  /^^^^^^^^^^^\     ______
 |  Internet   | ---| fw |------   (Internet LAN)
  \___________/     ~~+~~~           192.168.1.*
                      |
                      +--- (servers)
                           192.168.2.*

In this simple diagram we show a gateway/router/firewall (running Linux). It has three interfaces. One leads to the Internet. Let's think of that as ppp0 though it doesn't matter what sort of IP interface we use. Another leads to our internal LAN (let's call it eth0) and the other leads to a small segment with one or more different types of servers.

We use 192.168.1.* addresses (one of the RFC1918 "reserved net" address blocks) on the internal LAN. We use another RFC1918 on the other (we can use any of the 192.168.x.* addresses and we can subnet them in whatever fashion we like).

But wait! We can't run an Internet server on an RFC1918 address! No router on the Internet will have valid routes to any of those addresses. True enough.

However, we do have one valid, real Internet address (direct routable IP address or DRIP). We might not want to run a web server, DNS server, mail relay or other service on our router (due to security, administrative, or capacity considerations). So we put ipportfw to relay connections to our router's web, DNS, or SMTP ports to one or more machines on the bastion segment. This makes 'fw' (our firewall/router) "appear" to be a multi-service host --- though it is only running a simple set of port forwarders. (Actually you really wouldn't need to have a third segment --- you could port forward or relay into hosts on your internal LAN. However, I wouldn't recommend that --- since any attacker that subverts one of those servers through the relayed connection can then attack all of your other systems --- rather than being isolated to one segment).

Note: I've never actually done this. However, that's what the IP, TCP, and UDP port forwarding utilities seem to be for.

However, this doesn't seem to meet your needs. You want to support the clients on your LAN in their access to public services out on the net. You don't seem to have any need to provide services ("virtual" or "relayed" or whatever) to the 'net.

So, you can use proxying. You can run a caching web server proxy (like Squid and/or Apache or even the old CERN web server). You can also run a caching name server on your gateway system. This is handy since your gateway (fw) has routes to your internal LAN and to the net. So it can reply to DNS request by your internal clients and make them of the outside world.

You can also use IP masquerading (using the ipfwadm command for your 2.0.x kernels and the newer, snazzier, ipchains command for 2.2). This is basically an alternative to proxying. You can think if IP masquerading (a particular form of "Network Address Translation" or NAT) as a "transparent, transport layer proxying" method. If you have a proxy server in place, and all of your client software supports the proxy (through the SOCKS protocol) then you don't need NAT/IP masquerading.

It's possible to use them together (so your SOCKSified clients talk to the proxying servers on your system, and anything else still goes through the NAT system. It's possible to do this with just one router --- and it's even useful for some cases. For example, using some services is difficult and someone unreliable through a masquerading router.

Protocols like FTP pass IP addresses in band (as part of the data/payload of the control connection --- to be used to establish a series of data connection from the server back to the client). This is trivial for programs to support at an applications layer and very difficult to do at the transport layer (from "under the hood"). It's like cartography --- making a map by walking around in the forest takes a lot of work --- doing it from a higher level is much handier.

So, try one of the SOCKS compatible server packages. If that gives you any trouble try a command like:

ipfwadm -F -a acc -m -S 192.168.0.0/16

... one your fw system. This will add (-a) a rule to the forwarding (-F) table in the kernel to accept (acc) for masquerading (-m) any packages with a source address (-S) from any of the 192.168.x.* ranges (to anywhere).

The reason we don't have to be explicit about destinations and interfaces is because the determination of which packets are presented to the which packet filtering tables is done by the kernel's routing table. Teh filtering tables decide which ones to drop, accept, reject and "re-write" (masquerade). So that's all given.

If we add the following two rules:

ipfwadm -F -a acc -m -S 172.16.0.0/12
ipfwadm -F -a acc -m -S 10.0.0.0/8

we've configured our system to gleefully masquerade IP packets from ANY RFC1918 address --- so you can use any of them for any of your intenal LANs, segments, etc.

I personally doubt that WinGate will work properly under WINE --- and it seems very unlikely that it would give decent performance or stability.

Drop-in Replacement for "WinGate"

From Paul A Pick on Tue, 23 Feb 1999

>[M]y question is: are you aware of proxy software for linux
>which can behave like wingate?

There are also a couple of other SOCKS compatible proxy server packages for Linux including DeleGate, and Dante (find them both on Freshmeat at https://www.freshmeat.net).

There ya go. I had never heard of freshmeat... (sorry guys)

I just downloaded delegate and it looks to be exactly what I was looking for... it seems to be available only as source (for linux) but compiled no problem at all. I'll try configuring it in the next coupla days.

Interestingly, delegate (according to the documentation, at least) runs under windows as well. This means that I could chuck wingate (if I wanted to) and have a very consistent interface to my client.

[ illustration of ipportfw snipped ]

Note: I've never actually done this. However, that's what the IP, TCP, and UDP port forwarding utilities seem to be for.

Yes, but I was trying to twist them to my own ends anyway.

You can also use IP masquerading (using the ipfwadm command for your 2.0.x kernels and the newer, snazzier, ipchains command for 2.2).

Alas, my win95 interface and my linux interface must be consistent.

I don't want to think about the client system's net access should I decide to play half-life, for instance.

In both cases the clients can point to your server/gateway as their default route. It just shouldn't be a problem.

I personally doubt that WinGate will work properly under WINE --- and it seems very unlikely that it would give decent performance or stability.

I gave it a shot and it didn't fire up at all. It encountered a fatal error in 'kernel32' or some such. I wasn't too interested in performance (my load average is generally 0.00) but stability would be an issue. A 'moot' issue, as it turns out.

Presumably WinGate is Win32s (or such). WINE only has very limited and preliminary support for Win32s.

I expect that the moment that WINE has reverse engineered reasonable support for the Win32s APIs we'll see a new Win32X out of Redmond and a suite of compilers that generate the new code by default --- to minimize the compatibility and interoperation.

Thanks for the info. Would you like to know how the delegate configurations go?

Sure. You could submit an article or review to the Linux Gazette.

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 38 March 1999

				1	2	3	4	5	6	7	8	9	10	11
				12		14		16	17	18	19		21	22
				23	24		26		28	29	30	31	32