[pptp-server] RE: Can access shares on poptop server but nothing else!

[Cowles, Steve]

> -----Original Message-----
> From: David Rankin [mailto:drankin at cox-internet.com]
> Sent: Tuesday, March 13, 2001 11:23 PM
> To: poptop; Christopher Tresco; George Vieira; Robert; Cowles, Steve
> Subject: Re: Can access shares on poptop server but nothing else!
> 
> 
> "Cowles, Steve" wrote:
> 
> >
> > Based on your prior posts... your WINS server is running on 
> > your PPTP server, so the above "could" actually work because
> > the browse request (from the client) does not have to be routed
> > past the PPTP server.
> >
> > > > Have you got ip forwarding enabled on your pptpd server?
> > >
> > > Uhh, I think so? All of my IP traffic goes through NEMESIS.
> > > It is my internal DNS and gateway and handles all of the
> > > traffic from the router and forwards it to the right machines
> > > in the office. All of the machines have no problem accessing
> > > the net through NEMESIS. I guess a picture would help
> > >
> >
> > What is the value of /proc/sys/net/ipv4/ip_forward  ?? It 
> > needs to be one (1)
> >
> > To check value, type: cat /proc/sys/net/ipv4/ip_forward
> >
> 
> This may be a problem... ip_forward is set to 0. How do I fix 
> this? See response below:
> 
> [david at Nemesis ipv4]$ cat ip_forward
> 0
> 

Without ip_forwarding enabled, packets of data arriving from the PPTP client
will not be routed from ppp0 to eth0 and vice-versa.

To temporarily enable ip forwarding, type: echo "1"
>/proc/sys/net/ipv4/ip_forward

NOTE: The above will not live through a reboot, but at least you can check
if this will fix your problem.

If your using a redhat 7 distro and wanting to permanently enable ip
forwarding at boot-up

edit /etc/sysctl.conf and change the following line from:
net.ipv4.ip_forward = 0
  to
net.ipv4.ip_forward = 1

It your using any other redhat distro like 6.0, 6.1, 6.2 then edit
/etc/sysconfig/network and change and/or add the following line:

FORWARD_IPV4=yes

> >
> > Also, when the PPTP client connects - does /var/log/messages
> > show the ethernet interface (like eth0) being set as proxy
> > arp for the PPTP client?
> > i.e.
> >
> > Mar 12 16:53:52 excelsior pppd[767]: found interface eth0 
> > for proxy arp
> >
> > If not, you will only be able to talk to the PPTP server 
> > (from the client) and no further.
> >
> 
> Here is the latest log from my session (proxy arp looks fine):
> 
> Mar 13 22:46:55 Nemesis pptpd[30016]: CTRL: Client 
> 208.180.113.40 control
> connec
> Mar 13 22:46:55 Nemesis pptpd[30016]: CTRL: Starting call 
> (launching pppd,
> openi
> Mar 13 22:46:55 Nemesis modprobe: modprobe: Can't locate 
> module char-major-108
> Mar 13 22:46:55 Nemesis pppd[30017]: pppd 2.4.0 started by root, uid 0
> Mar 13 22:46:55 Nemesis pppd[30017]: Using interface ppp0
> Mar 13 22:46:55 Nemesis pppd[30017]: Connect: ppp0 <--> /dev/pts/0
> Mar 13 22:46:55 Nemesis pppd[30017]: CHAP peer authentication 
> succeeded for
> davi
> Mar 13 22:46:55 Nemesis pppd[30017]: found interface eth0 for 
> proxy arp

This is good.... eth0 is acting as proxy arp for PPTP client.

If your interested, I wrote a document about what a proxy arp does and how
important it is to PPTP connections. It's still work in progress, but it
should give you an idea of how packets of data make it from/to the PPTP
client.

Checkout: http://www.infohiiway.com/pptp/proxyarp.html

> Mar 13 22:46:55 Nemesis pppd[30017]: local  IP address 192.168.7.106
> Mar 13 22:46:55 Nemesis pppd[30017]: remote IP address 192.168.7.101
> Mar 13 22:46:55 Nemesis pppd[30017]: CCP terminated by peer
> Mar 13 22:46:55 Nemesis pppd[30017]: Compression disabled by peer.

Odd entry (CCP terminated), I have never seen this before, but if its
working....

Steve Cowles