*Note: This configuration is based on a Redhat/Fedora installation, but should work the same with other linux distributions. Some commands may differ.
I needed to setup a VPN server so that I can access some tools that run here from home.
I came across a bunch of hurdles and thought i’d document them here for anyone who needs to do the same.
This will allow MS clients and probably Apple too.
PPTP server uses interface ppp0 is the Point to Point Protocol interface number 0.
Packages Required for PPTP VPN:
Kernel that supports MPPE 128-bit encryption
PPP
PPTPD
Fedora ships out of the box with MPPE and PPP ready to rock. The only thing I really need to do is add the PPTPD package.
Step 1: Install PPTPD
yum install pptpd
Once yum has installed this package successfully, you will notice that it has created a pptpd.conf file in your /etc directory. Go ahead and check for it:
ls /etc | grep pptp
pptpd.conf
At this point, you should have a working pptp daemon. This is a matter of personal preference, but I like to go ahead and start pptpd just to make sure that the service is functioning and that it opens up the PPTP port (1723) on the machine:
[user@hostname ~]# /etc/init.d/pptpd start
Starting pptpd: [ OK ]
[user@hostname ~]# telnet localhost 1723
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
If you get this far and the service starts and you get the message “Connected to localhost.” when you telnet to port 1723, you should be right as rain.
Step 2: Configuration Files:
There are three configuration files we need to worrry about. They are /etc/pptpd.conf, /etc/ppp/options.pptpd, and /etc/sysctl.conf.
Let’s start with /etc/pptpd.conf. There are three main criteria that we need to worry about, so you will need to edit this file and make sure these entries are in it. Bear in mind that a “#” symbol in front of the lines means that the line in front of the # is disabled. You do not want this for the following three lines. Also, the localip and remoteip fields will need to be changed according to your ip addressing scheme. :
option /etc/ppp/options.pptpd
ppp /usr/sbin/pppd
localip 10.20.254.249
remoteip 10.20.254.250-253
In the example above, the first line, “option /etc/ppp/options.pptpd” tells the pptp daemon
where to locate the options.pptpd file which contains various options on how to set up the
pptp tunnel (encryption type, authentication type, and so on).
The second line, “ppp/usr/sbin/pppd” tells the pptp daemon where to find the ppp daemon.
This is necessary because the pptp daemon will need to initialize the ppp daemon in order for
this all to work. Both daemons work together to create our tunnel.
The final two lines with “localip” and “remoteip” are also quite important.
In your case, localip should be the ip address of your particular linux machine.
The remote ip will be the ip address, or addresses that you will hand out to your mobile VPN clients – similar
to a very simple DHCP scope.
For example, the above entry allows for 10 simultaneous connections of which 192.168.10 will be
the first address given to the remote user. Just make sure that these addresses are actually available
on your network and not in any other DHCP scope. *Note: You may use CIDR if you have a particular
subnet that you want to hand remote users, just make sure that your routing can handle it.
Now, on to /etc/ppp/options.pptpd
As stated previously, options.pptpd is concered with how the VPN will authenticate and encrypt. Below are the options that you actually care about:
name pptpd
require-mschap-v2
require-mppe-128
ms-dns 192.168.1.73
lock
nobsdcomp
auth
require-mppe
I will go through these briefly.
The first line indicates the name of the daemon.
The 2nd and 3rd lines indicate what type of authentication and what kind of encryption is required.
MSCHAP-v2 is preferred for Microsoft clients.
Mppe-128 bit encryption is also preferred.
The fourth line is optional as you can choose whether or not to give your mobile clients a DNS entry
so that they access resources by name.
The fifth line indicates that each individual session is locked and only accessible by the initial connected party.
This is quite important and should ALWAYS be present.
Sixth line, nobsdcomp, disables BSD type compression, which MS clients tend to have problems with. The last two lines auth and require-mpp just tell the daemon to authenticate the client and require MPPE.
Lastly, /etc/sysctl.conf:
Edit this file and make sure the net.ipv4.ip_forward is set to 1. This enables ip packet forwarding on the LAN which is required if you expect your VPN users to be able to access any other resources on the network besides the VPN server itself.
net.ipv4.ip_forward = 1
Step 3: Setting up Users:
The users can be set up one of several ways, either through LDAP, MS Active Directory, or /etc/passwd authentication – however, that is outside the realm of this tutorial. If you did want to do it that way, you would need to modify the above options.pppd file. The auth in the options.pppd file defaults to the chap-secrets file which we will now modify. The chap-secrets file in the /etc/ppp/ directory.
# client server secret IP addresses
rich pptpd apassword 80.40.0.0/13
geoff pptpd apassword 212.219.0.0/14
The above is pretty self explanatory. Each line will represent one user. The “*” specifies that any of the allotted ip addresses will be assigned to that particular user. You could enter in a specific IP address that you would like each particular user to receive upon connection, if necessary.
Step 4: Test and Troubleshoot:
At this point you will want to restart your pptpd service so that it can read your newly edited config files.
/etc/init.d/pptpd stop
/etc/init.d/pptpd start
You will want to set up a vpn connection on either a windows or linux machine just as you
would normally do, and try to connect. The main output of the attempted connection will
be located in /var/log/messages. More detailed logging can be found in the pptp logs.
My first connection attempt completely failed and here is the output of /var/log/messages:
Linux PPTP Server IPtables Rules :
You will need to port forward on public facing router pptp tcp port 1723 from the internet to
the server to enable the connection.
( on cisco router)
ip nat inside source static tcp (local-ip-address-of-server) 1723 interface FastEthernet0/0 1723
!
You will need to allow GRE packets ( udp 47) on public facing router incoming from the internet.
( on cisco router)
ip access-list extended INTERNET
permit gre any any
!
Generic Routing Encapsulation (GRE) is a tunneling protocol designed to encapsulate a wide
variety of network layer packets inside IP tunneling packets.
GRE protocol cannot inspect non-IP traffic, as above we allow GRE return packets through the public facing router on the incoming firewall rule.
!
You will need to allow pptp port 1723 on the INPUT chain on linux server.
iptables -I INPUT -d (local-ip-address-of-server) -i eth0 -p tcp -m tcp –dport 1723 -j ACCEPT
!
You will need to allow GRE packets on the OUTPUT chain on linux server.
iptables -I OUTPUT -s (local-ip-address-of-server) -p gre -j ACCEPT
!
You will need to allow pptp port 1723 packets OUTPUT from server with a SNAT (source-nat) of tcp 1723.
iptables -I OUTPUT -s (local-ip-address-of-server) -p tcp -m tcp –sport 1723 -j ACCEPT
Sumarize Firewall Rules :
Allow GRE-47/pptp-1723 on internet facing router.
Configure a port forward for pptp-1723 to internal lan server ip address.
Allow GRE traffic out from pptp server.
Allow pptp tcp port 1723 out from pptp server with a source nat of 1723 to remote host or any.
PPTP Server is hosting a CIFS share, add iptables rules to allow pptp host 10.20.254.249 access to CIFS share on another interface on server (192.168.2.4)
PPTP server uses interface ppp0 is the Point to Point Protocol interface number 0.
INPUT CHAIN :
iptables – I INPUT -s 10.20.254.249/32 -d 192.168.2.4/32 -i ppp0 -p tcp -m tcp –dport 139 -j ACCEPT
iptables – I INPUT -s 10.20.254.249/32 -d 192.168.2.4/32 -i ppp0 -p tcp -m tcp –dport 445 -j ACCEPT
OUTPUT CHAIN :
iptables – I OUTPUT -s 192.168.2.4/32 -d 10.20.254.249/32 -p tcp -m tcp –dport 445 -j ACCEPT
