VPN is short for "Virtual Private Network". A VPN works by encapsulating packets to/from the network you want to participate in (the "remote network") and sending them (usually encrypted) as data in packets from/to the network to which you are connected (the LAN). The "Point to Point Tunneling Protocol" (PPTP) is probably the most common way of establishing a VPN connection. Most versions of Windows and Unix/Linux come with code to do this.
When a VPN connection is established, the client computer is issued a second IP address by the VPN server. All traffic intended for use on the "remote network" is generated using this second IP address, encapsulated in the native IP address and sent through the VPN "tunnel". The three configurations described below differ primarily in what address range the second IP address is issued from.
Using any of these configurations requires editing four or five
configuration files on the firewall: three to configure the PPTP server, one to
arrange to start it when the firewall system is rebooted and, for the remote
access configurations, changing a rule in the "tables" file which by default
only allows local PPTP connections). See also "/usr/doc/pptpd"
on the firewall itself.
Unfortunately, authentication directly via UWnetID is not an option (as far as I can tell). The best alternatives may be:
To make every VPN password consist of two halves: a user-half you issue each user just once and a departmental-half which is changed periodically and placed in a UWnetID-protected webpage where users can obtain it. Or...
To authenticate usernames and passwords against an existing Windows Domain Controller. The additional steps required to authenticate VPN users against a Windows DC are below.
In this configuration, a pool of your public/routable addresses is reserved for the VPN server to assign to VPN clients. Each system connecting through this configuration will get an address from the pool and appear to other systems on the internet to be on your subnet behind the firewall at that assigned second address (except that traffic to and from the client's local LAN will bypass the VPN). If you don't have enough spare addresses on your firewall's subnet to allocate a pool for your VPN server, you may want to consider Configuration 2 below.
For security, by default, the firewall will only accept PPTP
connections from the local 10. subnet. To use PPTP remotely, you'll need to
change that. The restriction is enforced by the
"-s $I_NET" clause of a line in section A
of the "/usr/local/sbin/tables" file containing
"--dport 1723". To allow PPTP connections from
anywhere, remove the "-s $I_NET" clause and rerun the file.
Place the following (suitably edited) lines in
"/etc/pptpd.conf":
speed 115200 option /etc/ppp/pptpd-options localip 192.168.254.254 # Note: replace a.b.c.d-e below with a suitable block of addrs from your subnet remoteip a.b.c.d-e # Note: uncomment logwtmp to show VPN users as "logged in" on the firewall # logwtmp
Place the following (suitably edited) lines in
"/etc/ppp/pptpd-options".
(For increased security at the expense of some compatibility, you can
substitute the green or red text from here
for the green or red text below.)
| Use the green text on the left with Gibraltar 0.99.8 and newer OR the red text on the right with older releases: |
# the name below must only match the "server" field in chap-secrets
name LFW
domain your_dept.washington.edu
auth
require-mschap +chapms
require-mschap-v2 +chapms-v2
require-mppe mppe-40
require-mppe-128 mppe-128
nomppe-stateful mppe-stateless
-mru
#
# Note: replace p.q.r.s below with the IP address of a DNS server
ms-dns p.q.r.s
# Note: replace a.b.c.d below with the IP address of your WINS server
ms-wins a.b.c.d
netmask 255.255.255.0
nodefaultroute
proxyarp
lock
The chap-secrets file, is used to authenticate clients (by
name/password). You must put each name/password you want to enable in the
"/etc/ppp/chap-secrets" file but since these are stored
unencrypted, and can't be readily changed by users, they should not be
passwords used for other purposes. Because Windows 98 (perhaps others)
sometimes prepends "YOUR_DOMAIN\\" to the front of the name, you may need to
make two entries (one with and one without your login domain). The
"chap-secrets" file has the following lines:
#name server password IP_address user1 LFW user1pw * DOMAIN\\user1 LFW user1pw * user2 LFW user2pw * DOMAIN\\user2 LFW user2pw *
Once these configuration changes are made, the PPTP daemon
on the firewall ("pptpd") must be started. For testing, it can
just be started manually from the command line (it requires no command-line
options). For use in production, you'll want to cause it to start
automatically by uncommenting the "pptp" line in
"/etc/runlevel.conf".
In this configuration, the VPN server assigns an IP address to VPN clients from a pool of private/unroutable addresses in the 192.168.x.y range. Each system connecting through this configuration will get one of these as its assigned second address. Traffic using that address will be subjected to "masquerading NAT" before it leaves the firewall so it appears, when leaving the firewall, to be originating from the fireawll itself. (As above, however, traffic to and from the client's local LAN will bypass the VPN). As usual with masquerading NAT, inbound connections are not permitted and those protocols which don't work through NAT won't work. Unlike Configuration 1 above, remote clients of this configuration can use ipsec tunnels, if they exist, in the same way local firewall clients do.
For security, by default, the firewall will only accept PPTP
connections from the local 10. subnet. To use PPTP remotely, you'll need to
change that. The restriction is enforced by the
"-s $I_NET" clause of a line in section A
of the "/usr/local/sbin/tables" file containing
"--dport 1723". To allow PPTP connections from
anywhere, remove the "-s $I_NET" clause and rerun the file.
Place the following lines (unedited) in
"/etc/pptpd.conf":
speed 115200 option /etc/ppp/pptpd-options localip 192.168.254.254 remoteip 192.168.0.1-254 # Note: uncomment logwtmp to show VPN users as "logged in" on the firewall # logwtmp
Place the following (suitably edited) lines in
"/etc/ppp/pptpd-options".
(For increased security at the expense of some compatibility, you can
substitute the green or red text from here
for the green or red text below.)
| Use the green text on the left with Gibraltar 0.99.8 and newer OR the red text on the right with older releases: |
# the name below must only match the "server" field in chap-secrets
name LFW
domain your_dept.washington.edu
auth
require-mschap +chapms
require-mschap-v2 +chapms-v2
require-mppe mppe-40
require-mppe-128 mppe-128
nomppe-stateful mppe-stateless
-mru
#
# Note: replace p.q.r.s below with the IP address of a DNS server
ms-dns p.q.r.s
# Note: replace a.b.c.d below with the IP address of your WINS server
ms-wins a.b.c.d
netmask 255.255.255.0
nodefaultroute
proxyarp
lock
The chap-secrets file, is used to authenticate clients (by
name/password). You must put each name/password you want to enable in the
"/etc/ppp/chap-secrets" file but since these are stored
unencrypted, and can't be readily changed by users, they should not be
passwords used for other purposes. Because Windows 98 (perhaps others)
sometimes prepends "YOUR_DOMAIN\\" to the front of the name, you may need to
make two entries (one with and one without your login domain). The
"chap-secrets" file has the following lines:
#name server password IP_address user1 LFW user1pw * DOMAIN\\user1 LFW user1pw * user2 LFW user2pw * DOMAIN\\user2 LFW user2pw *
Once these configuration changes are made, the PPTP daemon
on the firewall (pptpd) must be started. For testing, it can
just be started manually from the command line (it requires no command-line
options). For use in production, you'll want to cause it to start
automatically by uncommenting the "pptp" line in
"/etc/runlevel.conf".
In this configuration, your client is physically on your firewall's LAN and
has a private/unroutable 10.x.y.z primary IP address. The goal of this VPN
configuration is only to avoid NAT. Each system connecting via this
configuration must be assigned (by the VPN server) the public/routable address
corresponding to (with the same last three octets as) its private 10. address.
This is accomplished by listing that IP address in the
"/etc/ppp/chap-secrets" along with a unique name and
password to identify it. Systems connecting this way appear exactly like
systems placed behind the firewall the normal way (with NAT) except that NAT is
not used (so protocols which have trouble with NAT will work). The setup
for this configuration is described in detail in:
Unsupported NAT-free Variations
This allows you to use existing user accounts in a Windows Domain instead
of putting authorized usernames and cleartext passwords in the
"/etc/ppp/chap-secrets" file.
In all three configurations above, the "/etc/ppp/chap-secrets"
serves two functions: it conains the username/password pairs
which are allowed to authenticate and optionally associates a predictable
IP address with a given username. When authenticating against a
windows domain, the "chap-secrets" file is not used and assigning
predictable IP addresses is not possible (only random ones from a pool).
When authenticating against a Windows Domain, it is highly recommended to require "ms-chap-v2" and refuse other "chap" and "pap" variations both on the server and on each client. The goal is to prevent either server or client from agreeing to be backwards-compatible and divulging an insecure (easy to crack) LANMAN hash.
It is "best practice" to disallow both LANMAN and NTLM on your Domain Controller and to require NTLMv2. Disallowing LANMAN is good (and gains most of the benefits) but unfortunately, requiring NTLMv2 on the Domain Controller will (currently) prevent ms-chap-v2 authentication from working.
If your Windows Domain Controller has trust relationships with other domains, everyone with an account in any of those trusted domains will be allowed to authenticate to your VPN.
Assuming you still want to do this, configure your VPN as per instructions above and in addition, follow the instructions below.
Add the following two lines to
"/etc/ppp/pptpd-options":
plugin winbind.so ntlm_auth-helper "/usr/bin/ntlm_auth --helper-protocol=ntlm-server-1"
| Use the green text on the left with Gibraltar 0.99.8 and newer OR the red text on the right with older releases: |
| require-mschap-v2 | +chapms-v2 |
| require-mppe-128 | mppe-128 |
| nomppe-stateful | mppe-stateless |
| refuse-mschap | -chapms |
| refuse-chap | -chap |
| refuse-pap | -pap |
To the "[global]" section
of "/etc/samba/smb.conf" add:
client ntlmv2 auth = yes password server = your.domain.controller.here security = domain realm = YOUR.WINDOWS.DOMAIN.IN.UPPERCASE workgroup = YOUR
Contrary to what you may read elsewhere, you do NOT need additional changes to any of the following files:
/etc/krb5.conf /etc/ppp/chap-secrets /etc/pptpd.conf /etc/nsswitch.conf
On your firewall, type the following commands at the shell prompt to join the domain with a username which has sufficient privelege on the domain controller to do so:
net rpc join -S your.domain.controller -U Username
Start and test "winbindd" on the firewall by typing
at a shell prompt:
/etc/init.d/winbind start...then wait a few seconds... wbinfo -p wbinfo -t
"wbinfo" will tell if winbind is configured and running properly.
You can arrange for "winbindd" to start automatically
after a reboot by uncommenting the "winbind" line in
"/etc/runlevel.conf".
Start "pptpd" by typing at a shell prompt:
/etc/init.d/pptpd start
You can arrange for "pptpd" to start automatically
after a reboot by uncommenting the "pptp" line in
"/etc/runlevel.conf".
for Gibraltar version 2.3 and earlier, arrange to save/restore
"/var/lib/samba/" across reboots by copying it to/from
somewhere in "/etc/local". (Failure to do this
will require you to rejoin the domain after rebooting the firewall).
That's it. If the above steps are completed successfully, a PC should be able to negotiate a VPN connection with the LFW using the username and password of a valid domain user.
Corey Satten
Email -- corey @ u.washington.edu
Web -- http://staff.washington.edu/corey/
Date --
Mon Jan 28 12:28:24 PST 2008