Remote Connection Problems-Can't get past the connect machine

I've set up my RH Linux6.0 machine as a dialup server using mgetty and pppd. Both of these work like they should I believe, the only problem is I cannot get past the machine I originally connect to on our local LAN. We're using the standard 192.168.3.* addressing for our LAN and I'm using a Win98 machine to connect. The DNS-ing is not working either, although we do have a DNS server on the LAN, but it is not the dialup server machine that has it.
So I have 2 questions:
1. Do I have to run a DNS server on the connect machine, or can I just set up a file that tells the remote users which one it is?
2. What organization do I have to contact(or do I have to at all) to get an IP address.(I'd like to use the dialup server as a point of access to the internet for remote users.)

Thank you and sorry about the low points, that's all I have. I'll increase it as soon as it goes up a bit.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

1. Use "ms-dns a.b.c.d" option in pppd to specify DNS for the clients, where a.b.c.d is the IP address of the DNS server. Note that the DNS server must of course be reachable by the 192.168.x.x network.

2. Get "valid" IP addresses from your upstream ISP, or your regional NIC, e.g. APNIC for Asia Pacific. This might not come cheap. If your dialup clients don't require a "valid" IP, e.g. there's only a workstation on the other end, an alternative is simply to use 192.168.x.x or other "private" IP addresses and turn on IP Masquerading (ipchains) in the dial-up server. Note that you may need to add one or two ipchain rules so that your dialup users will not be able to access the LAN (unless of course these accounts are only for your employees).

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
tiboriAuthor Commented:
I did the 1. step you suggest but it doesn't work. I've heard that for it to work, pppd has to be compiled with this option. Do you know if in RH6.0 this option is compiled in by default, or do I have to recompile the package?
I do need this only for the employees, so I wouldn't necessarily want to get a valid ip from a NIC, just because of the cost. Is it still possible to do it then through the ms-dns configuration?
tiboriAuthor Commented:
This is what my /etc/ppp/options file looks like. Is it correct?

#Do not fork
#Do not set up escaped control sequences
asyncmap 0
#use the modem control lines
#use hardware flow control
#use uucp style lock to ensure exclusive access to serial device
#create a default route in the routing table

#set up DNS for microsoft(windows) machines
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

You're right...

I'm not sure if stock RH6 pppd has this, but apparently not. Easiest way without recompiling is to run a caching-nameserver on the dialup machine which just has your real NS a forwarder in /etc/named.conf:

options {
        directory "/var/named";
        forwarders {

but then, given the hassle of setting up a dns server (reverse IP lookups blah), perhaps you'd be better off recompiling.

Good luck!
tiboriAuthor Commented:
I'm still not able to reach any other computer except the dial up server. I've used the "proxyarp" command(please see copy of 'options' file above) but it still does not work. I'm not even trying the DNS way yet, just through the IP.
I've downloaded and installed the new PPP package(rpm) Could the local firewall be causing a problem? I've assigned the ip address to the remote to be the in the same domain i.e. 192.168.3.*, but it still does not recognize other machines...not even through pinging. Although a ping does produce a "request timed out" instead of just hanging I think it finds the other machines, it just can't connect to them. The other local machines don't have to run the pppd or something like that do they??
tiboriAuthor Commented:
This is what I get when I run ifconfig:
ppp0      Link encap:Point-to-Point Protocol
          inet addr:  P-t-P:  Mask:
          RX packets:63 errors:1 dropped:0 overruns:0 frame:1
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10

Why does it say NOARP? Also the netmask should be least this is what it is on the lan) Where do I change these paramaters, or do I need to? I've tried adding "netmask" to the /etc/ppp/options file, but that did not help.
Please help,
Thank you
Please check:

1. /etc/ppp/options.ttySx contains


2. /etc/mgetty+sendfax/login.conf contains

/AutoPPP/ -     -       /usr/sbin/pppd auth -chap +pap login

(you ARE using mgetty..?)

3. netmask is normal for dialup ppp

4. NOARP is also ok

Have you tried putting a nameserver on the dialup box as a last resort?
tiboriAuthor Commented:
I'm not using an options.ttySx file, just the old options this bad?

I'm also not using autoppp, instead I set /sbin/pppd in /etc/passwd for a user named ppp. I can see the ppp daemon starting and it logs me onto the network from the dialup machine. I can telnet/ftp etc to the dialup server, and then of course telnet from there to the other machines, but I cannot do it directly. I cannot ping any other machine either. It will try to connect to it, but it gets "request timed out"

3. I am using mgetty which seems to be working fine.

Do I need to set up any other files? Do I need the "defaultroute" or not?

P.S. If we get this problem resolved I'll give you all the points I have...only another 65 extra, but you can have it all. Thanks for the help.
1. How many dialup lines do you have connected to your server? If more than one, you need to use options.ttyS0, .ttyS1, etc.

2. Seems you don't have IP masquerading turned on... search for "Rusty's Three Line Guide to Masquerading" or some such.

Maybe you can start fresh...

1. install mgetty
2. edit /etc/mgetty+sendfax/login.conf so that ONLY the /AutoPPP/ line as described above is not commented out.
3. for each dialup port, add an /etc/ppp/options.ttySx as described above
4. run linuxconf. Add users using "Users accounts/Special accounts/PPP accounts"
5. Setup a caching-nameserver on your machine with your real DNS server as its forwarder
6. Make sure IP masquerading is turned on

Good luck! ... and no need for the extra points.
tiboriAuthor Commented:
do I need to set up any type of packet forwarding etc in network setup.
Also I've tried specifying the DNS on the client(dialin) machine...didn't help.
1. in /etc/rc.d/rc.local

ipchains -P forward DENY
ipchains -A forward -i ppp0 -j MASQ
echo "1" > /proc/sys/net/ipv4/ip_forward

also run those commands from the prompt

2. won't work unless you can reach the nameserver via a ping
tiboriAuthor Commented:
dirge: IT WORKED!!

Thanks a lot. It was IP Masquerading that I needed to turn on. The syntax was a little different than what you specified above. In particular I used ACCEPT instead of DENY for the policy, and I modified the second line to allow only hosts from a specific domain to enter. Anyways, it worked!!
Congratulations! :)

Actually, I gave you the ipchains rules from the wrong server -- that's for a server connected to the net via dialup. My real dialup server uses "-i eth0" (net access via leased line on the gateway) and has a line not to allow access to the LAN -- only the 'Net. We have different requirements, I guess. My policy there is still DENY though.

Thanks for the nice grade...! Heheh, my original answer did have IP masq as one of the requirements ;)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.