Linux-Networking Digest #694, Volume #9 Mon, 28 Dec 98 01:13:36 EST
Contents:
Re: firewall tool for linux? (lowercase)
IRC Crashes Linux, fix? (Glenn Valenta)
Re: IRC Crashes Linux, fix? (Glenn Valenta)
Re: 3c905b (Dale Miracle)
Re: firewall tool for linux? (lowercase)
Re: PPP 2.3.5 compile problem (Karl Kamin)
Netatalk, LocalTalk, and TCP/IP (Todd Litwin)
Where's RedHat rc.inet1, rc.inet2 files?? (Vincent)
Re: firewall tool for linux? ("NoneYa")
Some problems related to IP masquerading (Mohd-Hanafiah Abdullah)
----------------------------------------------------------------------------
From: lowercase <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.security.firewalls
Subject: Re: firewall tool for linux?
Date: Mon, 28 Dec 1998 05:05:24 GMT
Paul,
You're quite knowledgeable in these kind of setup. The information
you've given is quite good. Thanks.
I have a similar setup but with cable modem. You see, I have my cable
modem connection goes to eth0 (24.112.132.x) on my firewall (S.u.S.E
5.3); eth1 (10.0.0.x) goes to a hub; and all other computer on the
network (10.x.x.x) is hooked into that hub to share the bandwidth. Now,
I've installed all necessary packages for network IP firewall
(accounting, forwarding, input, output, proxy, etc.) Firewall policies
work great. However, I can't get my firewall to route from my LAN to
the net. Do you have any suggestion?
lowercase
"Paul B. Brown" wrote:
>
> James,
>
> Actually, that's a good question. It's a bit tricky because it involves
> a number of issues. Let me see if I can make it clear. Hummm . . . where
> to begin . . . .
>
> What you are about to read is a synopsis of how our theoretical network is
> setup. Plough through it and please ask questions if you do not understand
> something.
>
> Our Theoretical Network:
> -----------------------
>
> 192.168.1.x 207.54.15.y 207.54.12.x
> | | |
> ------- | | |
> | | x=2 v | |
> | B |::::::: | |
> | | eth0 : | |
> ------- : ------- | |
> : x=1 | | y=6 v v z=5
> :::::::| A |::::::::{modem}::::::::{modem}:::::::[TS]
> : eth0 | | ppp0
> ------- : -------
> | | eth0 :
> | C |:::::::
> | | x=3
> -------
>
> A = Our firewall
>
> B = A host inside our protected network
>
> C = Another host inside our protected network
>
> x = The fourth octet in our 192.166.1.0/24 private address space
>
> y = The fourth octet in the 207.54.15.0/24 public address space at our ISP
>
> z = The fourth octet in the 207.54.12.x/24 public address space at our ISP
>
> ppp0 = Our modem interface that we use to connect to our ISP
>
> eth0 = Our internal network connectivity interface
>
> TS = Our ISP's Terminal Server
>
> NOTES:
>
> 1. All hosts in your private network use the 10BaseT eth0 interface for LAN
> connectivity.
>
> 2. Your firewall (A) uses an analog connection to the Internet via a modem
> and PPP, thus the public interface of the firewall (A) is ppp0. Of
> course, you can easily substitute another interface, such as eth1, if
> another connection method is used. Cable modems, xDSL routers, Frame
> Relay, PtP T1, etc, etc, ad nausium.
>
> 3. I assume that we have a static IP address to use that was provided by
> our ISP.
>
> That's the picture of how this are. What's next is the routing on each
> host in our network so things work at TCP/IP stack layers 1 (physical) and
> 2 (data link).
>
> Static routes our Firewall (A), interfaces eth0 and ppp0:
> --------------------------------------------------------
>
> Destination Gateway Genmask Flags Metric Window Use Iface
> 207.54.12.5 * 255.255.255.255 UH 0 0 124 ppp0
> 192.168.1.0 * 255.255.255.0 U 0 0 2 eth0
> 127.0.0.0 * 255.0.0.0 U 0 0 5 lo
> default 207.54.12.5 * UG 0 0 1970 ppp0
>
> Notice that all traffic destined for 192.168.1.0/24 is heading out our
> eth0 port. Anything destined for the terminal server on the other side
> of our connection is heading out our PPP port. Ignoring the loopback (lo)
> interface, all other traffic goes out the ppp0 interface. Make since??
>
> You can setup our loopback interface as follows:
>
> /sbin/ifconfig lo 127.0.0.1
> /sbin/route add -net 127.0.0.0
>
> You can setup our eth0 interface as follows:
>
> /sbin/ifconfig eth0 192.168.1.1 \
> broadcast 192.168.1.255 \
> netmask 255.255.255.0 \
> up
>
> /sbin/route add -net 192.168.1.0 netmask 255.255.255.0
>
> Our ppp0 interface and route statements will be setup when we initiate
> the ppp connection. Something like this:
>
> --------------------------------- ppp-on ----------------------------------
> DIALER_SCRIPT=/etc/ppp/ppp-on-dialer
> TELEPHONE=555-1212 # The only telephone number
> ACCOUNT=username # The account name for logon
> PASSWORD=password # The password for this account
> LOCAL_IP=207.54.15.6 # Local IP address if known. Dynamic = 0.0.0.0
> REMOTE_IP=0.0.0.0 # Remote IP address if desired. Normally 0.0.0.0
> NETMASK=255.255.255.0 # The proper netmask if needed
>
> export TELEPHONE ACCOUNT PASSWORD
> exec /usr/sbin/pppd debug lock modem crtscts /dev/ttyS1 38400 \
> asyncmap 20A0000 escape FF kdebug 0 $LOCAL_IP:$REMOTE_IP \
> noipdefault netmask $NETMASK defaultroute connect $DIALER_SCRIPT
> ---------------------------------------------------------------------------
>
> Notice the "defaultroute" variable in the pppd command? That's what sets
> up the default route statement. Also notice the REMOTE_IP is 0.0.0.0.
> That's because pppd will negotiate this with the pppd on the other side
> and set it up automatically. Neat, huh?
>
> ---------------------------- ppp-on-dialer --------------------------------
> exec chat -v \
> TIMEOUT 3 \
> ABORT '\nBUSY\r' \
> ABORT '\nNO ANSWER\r' \
> ABORT '\nRINGING\r\n\r\nRINGING\r' \
> '' \rAT \
> 'OK-+++\c-OK' ATH0 \
> TIMEOUT 60 \
> OK ATE1Q0S0=0M0DT$TELEPHONE \
> CONNECT '' \
> ogin:--ogin: $ACCOUNT \
> assword: \\q$PASSWORD
> ---------------------------------------------------------------------------
>
> Static routes on host B, interface eth0:
> ---------------------------------------
>
> Destination Gateway Genmask Flags Metric Window Use Iface
> 192.168.1.1 * 255.255.255.0 U 0 0 2 eth0
> 127.0.0.0 * 255.0.0.0 U 0 0 5 lo
> default 192.168.1.1 * UG 0 0 1970 eth0
>
> Notice that all traffic heads for the gateway 192.168.1.1.
>
> We can setup our loopback interface as follows:
>
> /sbin/ifconfig lo 127.0.0.1
> /sbin/route add -net 127.0.0.0
>
> We can setup our eth0 interface and default route as follows:
>
> /sbin/ifconfig eth0 192.168.1.2 \
> broadcast 192.168.1.255 \
> netmask 255.255.255.0 \
> up
>
> /sbin/route add -net 192.168.1.0 netmask 255.255.255.0
> /sbin/route add default gw 192.168.1.1 metric 1
>
> Static routes on host C, interface eth0:
> ---------------------------------------
>
> Destination Gateway Genmask Flags Metric Window Use Iface
> 192.168.1.1 * 255.255.255.0 U 0 0 2 eth0
> 127.0.0.0 * 255.0.0.0 U 0 0 5 lo
> default 192.168.1.1 * UG 0 0 1970 eth0
>
> Notice that all traffic heads for the gateway 192.168.1.1.
>
> We can setup our loopback interface as follows:
>
> /sbin/ifconfig lo 127.0.0.1
> /sbin/route add -net 127.0.0.0
>
> We can setup our eth0 interface and default route as follows:
>
> /sbin/ifconfig eth0 192.168.1.3 \
> broadcast 192.168.1.255 \
> netmask 255.255.255.0 \
> up
>
> /sbin/route add -net 192.168.1.0 netmask 255.255.255.0
> /sbin/route add default gw 192.168.1.1 metric 1
>
> Whew . . . OK . . . that was the tough part. If things are working well,
> then we can begin to think of a security policy that will make since in
> our situation. Make sure, once the connectivity has been established,
> tested, and verified, that you create a security policy. Here is one
> that's pretty basic for any small business:
>
> Security Policy:
> ---------------
>
> * Allow only the following outbound TCP connections:
> Telnet from 192.168.1.0/24 to 0.0.0.0/0
> FTP from 192.168.1.0/24 to 0.0.0.0/0
> NNTP from 192.168.1.0/24 to 0.0.0.0/0 (UseNet News)
> SNTP from 192.168.1.0/24 to 0.0.0.0/0 (Network Time Protocol)
> HTTP from 192.168.1.0/24 to 0.0.0.0/0
> SHTTP from 192.168.1.0/24 to 0.0.0.0/0
> SSL from 192.168.1.0/24 to 0.0.0.0/0
> SMTP from 192.168.1.0/24 to 0.0.0.0/0
> Finger from 192.168.1.0/24 to 0.0.0.0/0
> Whois from 192.168.1.0/24 to 0.0.0.0/0
>
> * Allow only the following inbound TCP connections:
> FTP from 0.0.0.0/0 to 192.168.1.2
> SMTP from 0.0.0.0/0 to 192.168.1.2
> HTTP from 0.0.0.0/0 to 192.168.1.2
>
> * Allow only the following outbound UDP connections:
> SNTP from 192.168.1.0/24 to 0.0.0.0/0
> DNS from 192.168.1.0/24 to 0.0.0.0/0
>
> * Allow only the following inbound UDP connections:
> SNTP from 0.0.0.0/0 to 192.168.1.0/24
> DNS from 0.0.0.0/0 to 192.168.1.0/24
>
> * Allow only the following outbound ICMP connections:
> Echo Request from 192.168.1.0/24 to 0.0.0.0/0
> Echo Reply from 192.168.1.0/24 to 0.0.0.0/0
> Traceroute from 192.168.1.0/24 to 0.0.0.0/0
>
> * Allow only the following inbound ICMP connections:
> Echo Request from 0.0.0.0/0 to 192.168.1.0/24
> Echo Reply from 0.0.0.0/0 to 192.168.1.0/24
> Traceroute from 0.0.0.0/0 to 192.168.1.0/24
>
> * Deny all other inbound and outbound TCP, UDP, and ICMP traffic.
> Any from 0.0.0.0/0 to 0.0.0.0/0
>
> NOTES:
> -----
>
> 1. 0.0.0.0/0: any destination
>
> 2. Bear in mind that you must destinguish between TCP, UDP, and ICMP when
> making your policies. If you want to get real sophisticated then you
> can plan for RIP, RIP2, EGRP, HEGRP, etc, etc, ad nausium.
>
> So, what does this policy boil down to? Basically, the users in our
> network can cruise the web, do e-mail, ftp files, read news, keep their
> computer's clock accurate, do finger, whois, ping, traceroute, and do
> secure transactions on the Internet. Also, we allow DNS to operate.
> As a small business, we allow anyone from outside to ftp to our ftp
> server (B), web surf on our web site (B), and send e-mail to our users (B).
> Everything else is not allowed.
>
> We would now use our packet filter (IP Chains) and our proxy filters (TIS)
> to build these rules. You can use the source and destinations as they are
> given above to allow/deny the various protocols.
>
> Finally, to answer you question, when you create your policy, you will be
> specifying which protocols and hosts/networks are allowed or denied.
>
> If you have any questions. please let me know.
>
> Enjoy! :-)
>
> Paul
>
> ---------------------------------------------------------------------------
> Paul B. Brown [EMAIL PROTECTED]
> President
> Brown Technologies Network, Inc. http://www.btechnet.com/
>
> Unix Systems Administration "Sailing is a state of mind . . . ."
> ---------------------------------------------------------------------------
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (James Ho) writes:
> >On 26 Dec 1998 20:21:56 GMT, [EMAIL PROTECTED] (Paul B. Brown)
> >wrote:
> >
> >Sorry if my question sounds stupid since I am a newbie in
> >networking/linux.
> >
> >For the packet filters, how would I know what source/dest to allow and
> >what to deny?
> >
> >James.
> >
> >>Jan,
> >>
> >>There are two types of firewalls. Alone, neither of them are solid
> >>protection against a persistant and knowledgable cracker. Together,
> >>however, they are formitable. Properly setup, it can defeat pretty much
> >>any attack long enough for you to be notified of the attack so you
> >>can take action against the perps.
> >>
> >>Two Firewalls:
> >>-------------
> >>
> >>1 Packet Filters: These firewalls will allow to to reject/allow packets
> >> in and out of your network based on source/destination
> >> IP addresses and source/destination ports. They work
> >> between the data link and IP layers of the TCP/IP
> >> stack.
> >>
> >>2 Proxy Filters.: These firewalls insert a piece of software between the
> >> service inside the protected network and the big, bad
> >> wolf (Internet). Lets take web services as an example.
> >> Your web browser will actually ask the firewall to
> >> connect to a site and download the page. The firewall
> >> will then pass the page back to you. In this way, you
> >> the user, hides behind the firewall so you cannot be
> >> touched. These firewalls work at the application layer
> >> of the TCP/IP stack.
> >>
> >>Putting those two types of firewalls together will allow you to create a
> >>strong security policy. Use the packet filter to allow only those
> >>networks and hosts that are trusted access to and from your proctected
> >>network and shutdown all unused ports. Use the proxies to hide the users
> >>allowed access through the firewall via the allowed services.
> >>
> >>They only real question is: Do you want both types of firewalls on loaded
> >>or do you want to separate the firewalls into separate boxes. Hummmm.
> >>
> >>Anyway to actually answer your question: ;->
> >>
> >>Use IP Chains as the packet filter and either TIS or SOCKS as the Proxy
> >>filter.
> >>
> >>Nuff said? ;->
> >>
> >>Paul
> >>
> >>>i need to setup a firewall on a linux machine. the firewall should
> >>>be an intelligent packet filter not a proxy.
> >>>
> >>>question: which package should i take?
> >>>
> >>>there are:
> >>>* the sinus firewall tool (http://www.ifi.unizh.ch/ikm/SINUS/firewall/)
> >>>* ipfwadm
> >>>* ipchains
> >>>* tis ?
> >>>* ...
> >>>
> >>>has anyone made some experience with the packs?
------------------------------
From: Glenn Valenta <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: linux.redhat.install
Subject: IRC Crashes Linux, fix?
Date: Mon, 28 Dec 1998 05:16:20 GMT
I can't seem to figure out if I am being hacked or if irc is making my ssytem
crash to the core.
I was having this problem with RH5.1. Everything was stable for over a year
until I started using irc. After a few hours of just watching, I will generally
have a crash that will at least kill the x server and usally lock up the whole
computer. I have never seen a linux system lock up like this!
Anybody else have this problem?
Is it someone doing some sort of IRC attack?
(I have hosts.deny = deny:all and have shut down all services)
How do I evaluate a core dump to see how and what created it?
--
x-no-archive: yes
--
Glenn Valenta Engineering @ http://www.coloradostudios.com
[EMAIL PROTECTED] http://ouray.cudenver.edu/~gavalent/
[EMAIL PROTECTED] Personal mail
[EMAIL PROTECTED] Work mail
------------------------------
From: Glenn Valenta <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: linux.redhat.install
Subject: Re: IRC Crashes Linux, fix?
Date: Mon, 28 Dec 1998 05:21:10 GMT
I have upgraded to RH5.2 and installed the ircII 4.4 (internal version
19971207)
Glenn Valenta wrote:
>
> I can't seem to figure out if I am being hacked or if irc is making my ssytem
> crash to the core.
>
> I was having this problem with RH5.1. Everything was stable for over a year
> until I started using irc. After a few hours of just watching, I will generally
> have a crash that will at least kill the x server and usally lock up the whole
> computer. I have never seen a linux system lock up like this!
>
> Anybody else have this problem?
>
> Is it someone doing some sort of IRC attack?
> (I have hosts.deny = deny:all and have shut down all services)
>
> How do I evaluate a core dump to see how and what created it?
>
--
x-no-archive: yes
--
Glenn Valenta Engineering @ http://www.coloradostudios.com
[EMAIL PROTECTED] http://ouray.cudenver.edu/~gavalent/
[EMAIL PROTECTED] Personal mail
[EMAIL PROTECTED] Work mail
------------------------------
From: Dale Miracle <[EMAIL PROTECTED]>
Subject: Re: 3c905b
Date: Sun, 27 Dec 1998 22:45:01 -0500
Giovanni Gigante wrote:
> On Wed, 23 Dec 1998 10:44:02 -0800, Dan Conti
> <[EMAIL PROTECTED]> wrote:
> .
> >The reason the card was initially not found (probably) had to do with the
> >'B'. 3com made enough changes between the 3c905 and the 3c905b that the
> >drivers for the 905 didn't work for the 905b. Chances are you are using
> >the most current ones, however.
>
> Are you sure the most recent drivers solve the problems? I haven't
> been able to have my 905b work yet, despite the fact that it is
> recognized and no error message is given. And redhat site gives the
> 905b (only the "b") as "not supported"... ouch
>
> Giovanni
I have found with 3com network cards as with most network cards you have to
disable the plug and play (i like to call Plug and Pray) and set the card for
the settings you want to use and turn off media type and manually select that.
(RJ45, etc).
--
Dale Miracle "No matter where you go, there you are",
System Administrator Oliver's Law of Location
The Edge of Insanity "Real funny Scotty, now beam down my
[EMAIL PROTECTED] clothes"
"I've gone to look for my self, if I return before I get
back keep me here."
------------------------------
From: lowercase <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.security.firewalls
Subject: Re: firewall tool for linux?
Date: Mon, 28 Dec 1998 05:27:35 GMT
Paul,
How do you set all these policies up? I write a script which uses
"ipfwadm" tool to specify my policies. Is that what you're using? Are
there any other tool to make the job easier? I'm using S.u.S.E. 5.3.
If it's possible, could you please post your script for these policies?
Thanks,
lowercase
"Paul B. Brown" wrote:
>
> Security Policy:
> ---------------
>
> * Allow only the following outbound TCP connections:
> Telnet from 192.168.1.0/24 to 0.0.0.0/0
> FTP from 192.168.1.0/24 to 0.0.0.0/0
> NNTP from 192.168.1.0/24 to 0.0.0.0/0 (UseNet News)
> SNTP from 192.168.1.0/24 to 0.0.0.0/0 (Network Time Protocol)
> HTTP from 192.168.1.0/24 to 0.0.0.0/0
> SHTTP from 192.168.1.0/24 to 0.0.0.0/0
> SSL from 192.168.1.0/24 to 0.0.0.0/0
> SMTP from 192.168.1.0/24 to 0.0.0.0/0
> Finger from 192.168.1.0/24 to 0.0.0.0/0
> Whois from 192.168.1.0/24 to 0.0.0.0/0
>
> * Allow only the following inbound TCP connections:
> FTP from 0.0.0.0/0 to 192.168.1.2
> SMTP from 0.0.0.0/0 to 192.168.1.2
> HTTP from 0.0.0.0/0 to 192.168.1.2
>
> * Allow only the following outbound UDP connections:
> SNTP from 192.168.1.0/24 to 0.0.0.0/0
> DNS from 192.168.1.0/24 to 0.0.0.0/0
>
> * Allow only the following inbound UDP connections:
> SNTP from 0.0.0.0/0 to 192.168.1.0/24
> DNS from 0.0.0.0/0 to 192.168.1.0/24
>
> * Allow only the following outbound ICMP connections:
> Echo Request from 192.168.1.0/24 to 0.0.0.0/0
> Echo Reply from 192.168.1.0/24 to 0.0.0.0/0
> Traceroute from 192.168.1.0/24 to 0.0.0.0/0
>
> * Allow only the following inbound ICMP connections:
> Echo Request from 0.0.0.0/0 to 192.168.1.0/24
> Echo Reply from 0.0.0.0/0 to 192.168.1.0/24
> Traceroute from 0.0.0.0/0 to 192.168.1.0/24
>
> * Deny all other inbound and outbound TCP, UDP, and ICMP traffic.
> Any from 0.0.0.0/0 to 0.0.0.0/0
>
------------------------------
From: Karl Kamin <[EMAIL PROTECTED]>
Subject: Re: PPP 2.3.5 compile problem
Date: Sun, 27 Dec 1998 23:30:39 -0600
Clifford Kite wrote:
> Ed Meyer ([EMAIL PROTECTED]) wrote:
>
> : Karl Kamin wrote:
> : >
> : > While doing a make modules, I get the following errors:
> : >
> : > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
> : > -fomit-frame-pointer -fno-strength-reduce -pipe -m486 -malign-loops=2
> : > -malign-jumps=2 -malign-functions=2 -DCPU=686 -DMODULE -c -o ppp.o
> : > ppp.c
> : > ppp.c: In function `ppp_dev_xmit':
> : > ppp.c:3104: too few arguments to function `dev_kfree_skb'
>
> <snip>
>
> : There seems to be a bug in /usr/src/linux/drivers/net/ppp.c on
> : line 3079:
>
> : #if LINUX_VERSION_CODE < VERSION(2,1,86)
>
> : which I believe should read
>
> : #if LINUX_VERSION_CODE > VERSION(2,1,86)
>
> Yes. For a pristine ppp-2.3.5 distribution; the starting line may vary
> for a modified package.. (Although it's likely ">=" - not that it's
> going to make any difference for most people.)
>
> --
> Clifford Kite <[EMAIL PROTECTED]> Not a guru. (tm)
> /* Speak softly and carry a +6 two-handed sword. */
That fixed it.. Thanks. Works great now. I like the demand mode..
~Karl
------------------------------
From: Todd Litwin <[EMAIL PROTECTED]>
Subject: Netatalk, LocalTalk, and TCP/IP
Date: Sun, 27 Dec 1998 21:16:10 -0800
Does anyone have experience with netatalk changing the IP address of a
network interface? I'm
relatively new to Linux networking (although not to Unix),and I'm
confused.
I recently installed the cops driver to control a Dayna LocalTalk board,
giving me access to a
couple of Macintoshes that I have on a Classic AppleTalk network (not
ethernet). I have my
cops-controlled lt0 network interface set to the private-subnet address
192.168.1.1, and my
Macs set to other addresses on 192.168.1.*. Everything looks fine until
I bring up netatalk. At
that time lt0 gets its address changed from 192.168.1.1 to 0.255.7.1.
Everything else about netatalk is just fine. I can access my Linux
machine from the Macs through AppleShare, and I can print from the Linux
machine to my LaserWriter Plus on LocalTalk. But I
don't know what to do about the network address. I'd like to use
OpenTransport from the Macs to
create a telnet session to Linux, but unless I can get a handle on the
address issues, I'm hung.
Does anyone know what's going on?
Todd Litwin
[EMAIL PROTECTED]
------------------------------
Date: Sun, 27 Dec 1998 21:50:17 -0800
From: Vincent <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.help,comp.os.linux.questions,comp.os.linux
Subject: Where's RedHat rc.inet1, rc.inet2 files??
The Slackware distrubution has the following files for building an
Intranet:
/etc/HOSTNAME
/etc/hosts
/etc/host.conf
/etc/resolv.conf
/etc/rc.d/rc.inet1
/etc/rc.d/rc.inet2.
The RedHat 5.1 distrubution has all of the above, except for:
/etc/resolv.conf
/etc/rc.d/rc.inet1
/etc/rc.d/rc.inet2
I cannot find these 3 files anywhere in the RedHat distribution. Where
would these files be in RedHat 5.1?
Thanks,
Vincent
------------------------------
Subject: Re: firewall tool for linux?
From: "NoneYa" <[EMAIL PROTECTED]>
Date: 27 Dec 1998 03:55:47 GMT
Crossposted-To:
news.software.nntp,alt.gothic,soc.culture.jewish,uk.test,soc.culture.israel,comp.security.firewalls
"BICUSPID" BARRY BOUWSMA BORINGLY BITES BIG BAD BRITISH BISEXUAL BACKSTREET BULLDOGS
!!!
------------------------------
From: [EMAIL PROTECTED] (Mohd-Hanafiah Abdullah)
Crossposted-To: comp.os.linux.misc
Subject: Some problems related to IP masquerading
Date: 28 Dec 1998 13:35:03 +0800
We have set up several Linux client machines behind an IP masquerade server.
That is, the server is the GATEWAY to the outside world. We are using the
addresses 192.168.1.x for all the machines within the masquerade. The server
has two NIC cards and it acts as the DNS and DHCP server for the clients as
well. Things work fine if the server is up. But as soon as the server goes
down for any reason, the GATEWAY is no longer available of course, and the
other machines will have problems running like not being able to:
- open xterm sessions
- run KDE
- scan emails in MH
- and many other things related to X windows
Why do all the above operations need to have the GATEWAY to be up before they
can run properly? Please help. Thanks.
Napi
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.networking) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Networking Digest
******************************
