[pptp-server] PoPTop, Samba, Windows and Firewalls (Oh My!)
Steve Rhodes
srhodes at cpinternet.com
Thu Jul 29 00:46:16 CDT 1999
INTRODUCTION
After spending the better part of two weeks developing my configuration
for a pptp sever for remote file access by Windows(tm) clients, I
thought I would pass along these notes to those who may be interested.
The basic configuration involves a Samba/PoPToP server behind a
firewall, through which clients using Win98 machines will connect using
the VPN facility built into that OS. This is diagrammed below.
_____ ___ ______ ______
| | | \ | fire | | file |
| win | ---> / net \ ---> | wall | ---> | srvr |
|_____| \__/\_/ |______| |______|
The components of the system consist of the Win98 clients running the
built-in VPN facility dialing in to their ISP's and connecting through
the firewall to the Samba server on the internal network using the pptp
protocol. The firewall uses Network Address Translation to convert an
open Internet IP address to an internal one. Sounds simple enough
right?
SIMPLE TEST SETUP
As a starting point, I configured a Win98 box to connect directly to a
PoPToP server without any authentication or encryption. This was just
to get a feel for how pptp works and verify the setup. Using the
pre-packaged rpm's was a big help here. You just rpm the thing onto the
system and fire it up, and you're in business. The diagram below
represents this simple system.
192.168.56.142 192.168.56.11
_____ ______
| | | file |
| win | ------------------> | srvr |
|_____| |______|
Emboldend by my success, I set out to turn on MS authentication and
encrytion, and this is where the fun started.
AUTHENTICATION AND ENCRYPTION
This is an area where Microsoft really shows its true colors. Turning
on password and data encryption on the Win98 VPN server configuration
was quite the eye opening experience. First with the authentication,
you will have to go through a somewhat difficult compilation of the
ppp-2.3.8 package. The worst part here is getting all the pieces
together, namely the rc4 files. This process is well documented in this
archive, so I won't go into it here.
The next realization is that Microsoft prepends the domain name to the
user name when submitting the login credentials. For example, srhodes is
now DBNET\\srhodes. If that wasn't bad enough, I found that the domain
wasn't even the one I was logged into. My best guess is that the first
domain that the computer ever logs into is stuck with it for ever. This
is a real problem if you have multiple domains that you log into. I
modified the pppd.c code to strip out the domain on MSCHAP logins, but
you can just set the user name in chap-secrets to match the windows
version.
Then I spent a whole day trying to figure out why data encryption does
not work. I tried just about everything I could think of that could be
wrong. That's when I discovered this archive, for which I am truly
grateful. It turns out that the Win98 implementation of encrytpion is
FUBAR! You have to download one of those patches from Microsoft,
DUN40.exe to get the thing to work. This is for 40 bit encryption.
Don't hold your breath waiting for 128 bit.
ftp://ftp.microsoft.com/softlib/mslfiles/dun40.exe
FIREWALL CONFIGURATION
The issue with a firewall in this setup is that you need to cover two
types of protocol communication. There is one connection which is a tcp
connection on port 1723 that handles the control functions and another
connection using IP type 47, or GRE, which handles the actual data
communication. This second connection presents a problem for the
convention linux firewall, ipfwadm. You see, its only set up to handle
tcp, udp and icmp protocols. It doesn't know about GRE.
The trick around this block is to use one of the new 2.2 kernels, which
employ a new firewall called ipchains. This tool willl handle arbitrary
protocols, which can be specified by their numbers.
192.168.2.142 192.168.56.11
_____ ______ ______
| | | fire | 192.168.56.1 | file |
| win | --------------->| wall | --------------> | srvr |
|_____| 192.168.2.1 |______| |______|
You need to remember a few things before getting too deep into this.
The default gateway on win is set to 192.168.2.1, and the default
gateway on file srvr is set to 192.168.56.1. The firewall has the two
network interfaces spanning the two subnets and is configured for
IP forwarding. If you have not yet applied any firewall rules, this
configuration will work as before. The interesing part is to block out
all other access to file srvr by implementing ipchains rules.
The short story is:
ipchains -F
ipchains -P forward DENY
ipchains -I forward -p tcp -d 192.168.56.11 1723 -j ACCEPT
ipchains -A forward -p tcp -s 192.168.56.11 1723 -j ACCEPT
ipchains -A forward -p 47 -d 192.168.56.11 -j ACCEPT
ipchains -A forward -p 47 -s 192.168.56.11 -j ACCEPT
NETWORK ADDRESS TRANSLATION
The next hurdle is to configure the firewall so that it can run an open
internet IP address on the outside and allow access to an internal
address on the inside. NAT is very well suited to this task, although
you may hear otherwise from knowledgable sources. It happens to be my
preference, though certainly not the only way to skin this cat. You can
obtain the NAT software and some detailed information from
http://www.csn.tu-chemnitz.de/HyperNews/get/linux-ip-nat.html
But again, there is a problem with the GRE protocol of type 47. The
tool for configuring NAT, ipnatadm, like its half-brother ipfwadm, is
not set up to handle arbitrary protocols. Unfortunately, you'll have to
go into the code and make a slight modification if you want to use it
for this purpose. There is a procedure called parse_protocol in the
file routines.c that discriminates the type of protocol to be filtered.
The basic idea is to accept a string representing a number and use that
as the filter. Since you have to recompile the kernel anyway to get the
NAT functionality, maybe it's not so horrible, relatively speaking.
For those ambitous enough, here is the diff for the routines file, copy
this into a file called routines.diff and use the command patch -p0 <
routines.diff from within the same directory.
--- routines.c Thu Mar 25 15:41:58 1999
+++ /mnt/zip/nat/routines.c Wed Jul 21 21:09:28 1999
@@ -112,11 +112,18 @@
else if (strncmp("icmp", s, strlen(s)) == 0)
nat_set.nat.protocol = IPPROTO_ICMP;
else {
+ int number;
+ char * end;
+ number = (int)strtol(s, &end, 10);
+ nat_set.nat.protocol = number;
+ }
+ /*
+ else {
fprintf(stderr, "ipnatadm: invalid protocol \"%s\"
specified\n", s);
exit_tryhelp(2);
- /* make the compiler happy... */
return;
}
+ */
}
void parse_hostnetworkmask(char *name, struct in_addr **addrpp, __u32
*maskp, int *naddrs)
The patch is actually lifted from ipchains, which was derived from
ipfwadm, which provides the basis for ipnatadm.
Once you've got all that running, what you want to do is to set up the
NAT rules so that the incoming client thinks its talking to the
firewall, as does the outgoing file server. The short of it is:
ipnatadm -F
ipnatadm -I -i -P 6 -D 192.168.2.1 1723 -N 192.168.56.11 1723
ipnatadm -O -i -P 6 -S 192.168.56.11 1723 -M 192.168.2.1 1723
ipnatadm -I -i -P 47 -D 192.168.2.1 -N 192.168.56.11
ipnatadm -O -i -P 47 -S 192.168.56.11 -M 192.168.2.1
Here, the -P argument sets the protocol, 6 is tcp and 47 is GRE.
PPTP packets targeting the firewall are translated to the internal host
inbound and vice-versa on the way out. Very slick.
SAMBA
Here's a subject so complex you could probably devote a whole career to
it. We don't want to get too bogged down, so I'll be brief. Samba
implements the NetBIOS protocol, which has more quirks than you can
shake a stick at. One of the biggest problems is the use of subnet
broadcasting. Suffice it to say, if you want the best results, you
should set your PoPToP IP addresses to reside within the subnet on which
the file server ethernet is located. I choose 192.168.56.12 for the
server address, and it hands out IP's from 192.168.13-127.
Setting the IP forwarding on the file server to true will give you
access to other machines on the internal network.
When you go at the samba sever from Win98, you have to use encrypted
password. Look at smbpasswd and related stuff.
Finding shares on the server is not so easy. The short story here is
that browsing is implemented via broadcast packets, and broadcast
packets will not travel down a PPP link. The only way to get browsing
to work over pptp is to set Samba up as a WINS server and a Domain login
server, and configure the clients to use that WINS server and force them
to login to that Domain. Believe me, I tried just about everything to
avoid that. You will also want to set the samba server as the domain
master and preferred master for the browsing.
If you can't do that, you can set the ppp/options file to include a
ms-wins setting for the samba server. This will set the client up so
they can at least resolve host names. The only way to find a share
under this configuration is to name it explicitly. You can use the
tools menu from the Win98 file browser and say find -> computer and
enter in the name of the samba server and it will be found. I have
found that setting domain master = yes and preferred master = yes gives
a rather nice boost to the speed of name lookups on the network.
Here is my abbreviated smb.conf
[global]
workgroup = VAULT
server string = acer
log file = /var/log/samba/log.%m
max log size = 50
security = user
encrypt passwords = yes
smb passwd file = /etc/smbpasswd
socket options = TCP_NODELAY
domain master = yes
preferred master = yes
domain logons = yes
wins support = yes
dns proxy = no
[homes]
comment = Home Directories
browseable = no
writable = yes
You should also use the lmhosts option for nmbd (-H) and set up an
lmhosts file on the samba server. Make sure also the the samba server
can resolve its own name, through either /etc/hosts or DNS.
In all honesty , I went through the same simple test setup with samba as
I did for PoPToP, although its not shown here explicitly.
CONCLUSION
PoPToP is a good program, as is Samba. This configuration can work if
you put a little effort into it. I have seen a lot of questions here
and in other places about these types of systems, so I would think that
there is some demand on the part of users who want this type of
functionality. I hope these notes are useful to you if this is what you
want to do.
Regards,
Steve Rhodes
More information about the pptp-server
mailing list