[pptp-server] Netmask woes... Last thing I'm sure.

[Cowles, Steve]

> -----Original Message-----
> From: Dread Boy [mailto:dreadboy at hotmail.com]
> Sent: Thursday, February 22, 2001 6:02 AM
> To: pptp-server at lists.schulte.org
> Subject: [pptp-server] Netmask woes... Last thing I'm sure.
> 
> 
> OK.  Here goes.  I'm able to log in from anywhere with any SMB 
> username/password combo, strip off the MS domain crap, and 
> authenticate perfectly from Win95A, 95B, 98, 98SE, NT4, and
> 2000.  Cool.
> 
> However, my client's IP address always shows a netmask of 
> 255.255.255.0 which is correct.  My LAN is a private subnet
> 192.168.0.x (I've used Class "C" even though these are for a
> Class "B" network, no matter either way.)
> 
> Now, after the client connected, I could never, ever see any
> Windoze machines, including my Linux Samba server with WINS,
> DNS, remote announce, blah, blah, blah, blah, blah.
> 
> This is because when I check the ppp0 interface with "ifconfig"
> the ppp0 interface always shows a netmask of 255.255.255.255.
> Of course this is quite futile if you want to view any of the
> 253 computers on your Class C network.  =(

No its not futile. In fact, its correct! Your ppp* devices *should* show a
32 bit mask as you have stated. This is normal when you have a ppp virtual
device that has another device (eth*) answer arp requests on behalf of the
remote pptp clients ip address. i.e. proxyarp

> 
> I can run "ifconfig ppp0 netmask 255.255.255.0" and force the 
> netmask, but this seems to make no difference after connection.
> I still can not see even the samba server trying WINS, BCAST,
> or LMHOSTS.
> 
> I assume this is because I am stuck with that 255.255.255.255 
> netmasking door in my face.

As you have stated, changing the netmask will not help. In fact, this would
probably cause problems for the next ppp connection. i.e. concurrent ppp
connections. Leave the netmask alone for the ppp devices. It's correct!

> 
> I am running PoPToP 1.0.1 with ppp 2.3.11 and kernel 2.2.17.
> 
> I have an NT server at 192.168.0.1.  (Netmask 255.255.255.0)
> 
> I have a Linux SMB server at 192.168.0.2 with two network cards
> for gateway usage, etc.  192.168.0.2 is eth0 and my other IP is
> eth1.  My ipchains script is almost perfect for forwarding,
> blockage, etc.
> 
> I can see neither of these machines, or any other nodes for 
> that matter.
> 
> I can connect remotely from other Windoze machines.
> 
> I read through the man pages for pppd and found the "netmask" 
> option which is supposed to be placed in /etc/ppp/options.
> However, when I add "netmask 255.255.255.0" into the options
> file, it definitely isn't rejected by pptpd or pppd, but still
> 255.255.255.255 comes up on the ppp0 interface.  In the pppd
> man pages it states that "some O/Ses won't allow anything but"
> 
> What?!  I've read several threads on the mailing list of 
> people having success with RedHat Linux.  What am I doing wrong?
> I have RedHat 6.2 (Originally kernel 2.2.14-5.0, now is 2.2.17
> with GRE and ppp-2.3.11 with all of the MS patches which seem
> to be working fine.)
> 
> Argghhh!!!
> 
> How does one get by this?  I'm sure it's the last step to enabling
> MS clients to access our VPN.
> 
> Who's got the quick answer for this one?

Based on the content of your post (you have explained the problem well, but
I see no relevant config data), there is no simple answer. If I could
suggest - 
you need to resolve the layer 3 (protocol) issues between the PPTP client
and your LAN *FIRST*, then deal with MS Networking, which requires Layer 3
to be functional since netbios is encapsulated within a TCP/IP packet.

A simple test would be to (from the remote PPTP client):

1) ping the remote ip address of the PPTP server's ppp* ip address, this is
not the eth0 device. If you get a reply, then...
2) ping the eth0 ip address of the PPTP server. If you get a reply, then...
3) ping another server on the same LAN as the pptp server. If you get a
reply, then layer 3 is functional.

If you do not get a reply to any of the above, then the following are
possible culprits:
   * The eth* device on the PPTP server is not being set
     to "proxyarp" for the ppp* devices.
   * IP_FORWARDING is not enabled on the PPTP server.
   * ipchain rules are not allowing forwarding from device
     eth* to ppp* and vice-versa


Once you resolve the above issues, MS Networking should start working if
your WINS server is functional and other clients have registered with it. If
you know it is, then I would check to be sure there is not an ipchain rule
on the PPTP server that is blocking ports 137:139 from being passed to the
PPTP client.

Steve Cowles