From Peter Mastren on 20 Aug 1998
James,
I appreciate your in depth coverage of the IP Masquerading topic last month.
My own private network now is able to talk through my Linux box using the techniques you described.
Glad to help.
I, however, can't seem to find an answer to my next problem anywhere in the literature. My Linux proxy is connected via ISDN to my employers intranet which itself is behind a firewall and served by a proxy server. From Linux, I can browse, telnet, ftp etc... using SOCKSified clients, i.e. rtelnet, rftp. From any other machine in my private network, I am only able to get as far as the companies intranet, but not all the way to the internet.
If your other machines were using SOCKSified clients they would probably work as well. So the first suggestion would be to find SOCKSified clients for your other systems.
It is also possible to configure SOCKS (v5 at least) for multi-hop traversal (so that one zone or subnet in an organization, such as yours can use a SOCKS server to relay traffic to another SOCKS server.
How do I get modules, ip_masq_ftp.o, ip_masq_raudio.o etc... to use SOCKSified protocols? Basically, another level of indirection is required to actually reach the internet. Can this be done?
I supposed someone could "SOCKSify" the IP Masquerading modules or use 'ipfwadm' to redirect all the appropriate traffic to custom, SOCKSified, programs through the transparent proxying features.
One of the features of the Linux IPFW (kernel packet filters) is a provision to redirect incoming TCP connections into Unix domain sockets on the localhost, where a user space program can be attached to them. This user space program can either handle the request directly or relay/proxy the connection through whatever interfaces and protocols you'd want to build into it.
I think the squid cache and the DeleGate proxy can each be configured to support this.
To find out a little bit more about this redirection feature look for the "-r" switch on the 'ipfwadm' man pages.
Just off hand I don't see that the newer IP-chains code (apparently intended to replace ipfwadm in future kernels) offers any particular help for your situation. It does add significant new features to Linux packet filtering and it well worth the work that's going into it. However, I don't see anything on it's web site:
https://www.adelaide.net.au/~rustcorp/ipfwchains/
... that applies directly to your situation.
Some other work in this field is at:
- The HOWTO for IPChains
- https://www.adelaide.net.au/~rustcorp/ipfwchains/HOWTO.html
As I said It looks like IPChains is going to be the default kernel packet filtering code for the 2.2 kernels.
- The Home of Linux IP NAT
- https://www.csn.tu-chemnitz.de/HyperNews/get/linux-ip-nat.html
(NAT -- network address translation -- is more generalized then IP masquerading. While IP masquerading implements a specific many-to-one NAT, IP NAT allows complex many-to-many translations. It might be able to co-exist with IP masquerading and/or IP Chains).
- Darren Reed's IP Filter
- https://cheops.anu.edu.au/~avalon/
This is the free filtering package used by FreeBSD and its brethren and it is the most popular packet filtering package for Solaris and a few other forms of Unix (which don't include packet filtering in their standard kernels).
Reportedly this has been successfully run under Linux as well.
As we move beyond packet filtering we look into proxying systems. We can look in at the home site of NEC SOCKS at:
https://www.socks.nec.com
(Just hit the "Download" link if you want the package itself).
On a whim I used their "Search" link and found 844 results for "Linux" and 578 results for "Solaris" The numbers are interesting though meaningless and I don't have time to do an analysis to say whether the disparity is good or bad for the Linux community.
We can also look at Thede Lod's "Simple SOCKS Daemon" page at:
https://www.leverage.com/users/tlod/ssockd/ssockd.html
This seems to be a simplified replacement/alternative to the stock SOCKS v4.x server.
It seem that this as only been tested under FreeBSD --- so it might require some coding to port it to Linux.
Thanks for time and keep up the good work. Your efforts are appreciated.
Peter F. Mastren