| PPTP is no longer considered a secure VPN technology because it relies upon MS-CHAPv2 which has been compromised. If you continue to use PPTP be aware that intercepted traffic can be decrypted by a third party, so it should be considered unencrypted. We advise migrating to another VPN type such as OpenVPN or IPsec.
More information on this can be found at https://isc.sans.edu/diary/End+of+Days+for+MS-CHAPv2/13807 and https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/
This article is intended to outline several different PPTP VPN type setups, it includes a how-to on setting up a Windows XP PPTP client to connect to the pfSense PPTP VPN server. Later versions of this document will include Mac, Linux and other clients.
Configuring the PPTP server on a pfSense box requires moderate knowledge of TCP/IP Inter-networking and subnetting. Also required is at least a basic, working configuration of pfSense.
For the sake of simplicity, redirection will not be demonstrated.
Select the Enable PPTP server radio button. Next, set an unused local IP address for the Server address field. This address is virtual will be used for the server side ("gateway") of the Point-to-Point network, and it should be either in an unused subnet, or an unused IP address outside the range of IPs used for PPTP clients. Do not enter a WAN IP or other live address into this field or problems will occur.
The Remote address range defines the range of IP addresses that will be assigned to PPTP clients. The field defines the starting IP address of the range, and No. PPTP Clients defines how many clients will be allowed to connect.
A range that lies within the LAN network may be used, but it must be outside the range of IP addresses used for servers and other networking equipment. It is more common/proper to use a different, unused, subnet however and not the LAN subnet where possible.
Check the Require 128-bit Encryption to require the mppe-128 we'll use from VPN clients.
Again for the sake of simplicity, RADIUS options are left unchecked. If a RADIUS server is available (FreeRADIUS, AD, etc), it may be used. See PPTP VPN Settings for info on the required fields.
Now create users and passwords for PPTP VPN users. An IP address may be specified. Hard-coding an IP address for a particular user allows restricting access to particular resources for that user, rather than by the PPTP interface itself.
Navigate to Firewall > Rules on the PPTP tab.
The rules required to allow PPTP itself to function do not need to be manually created. pfSense automatically creates rules to allow GRE and TCP/1723 to pass inbound to the WAN PPTP termination point.
pass in on $WAN proto tcp from any to 198.51.100.1 port = 1723 modulate state label "allow pptpd 198.51.100.1" pass in on $WAN proto gre from any to any keep state label "allow gre pptpd"
To manually restrict the PPTP service to particular subnet or IP address sources, check Disable all auto-added VPN rules under System > Advanced on the Firewall / NAT tab. Then manual rules similar to the above may be added to restrict PPTP sources.
Now, create some rules to allow PPTP users to access the resources they need.
Liberal rules are often used to allow all traffic (any protocol, any source) on the PPTP interface to the LAN and DMZ subnets, or a destination of any. The picky amongst us further restrict the protocol, source and destination parameters as required to limit access.
That is all that is required. If resources will be accessed which via the VPN that are not directly connected to the firewall itself, such as the Internet, the next steps should be skipped.
By default when a connection is made to the PPTP server, the default gateway for ALL traffic will be via the PPTP VPN. With the current rules created in this example, resources outside the LAN or DMZ subnets would be unreachable. To allow that traffic, add more permissive rules, such as one with a pass to a destination of any.
To change this behavior:
C:\>ping 192.168.1.254 Pinging 192.168.1.254 with 32 bytes of data: Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
C:\>ping 192.168.1.1 Pinging 192.168.1.1 with 32 bytes of data: Reply from 192.168.1.1: bytes=32 time=2ms TTL=254 Reply from 192.168.1.1: bytes=32 time=1ms TTL=254
This document would have borrowed very heavily from the m0n0wall documentation, if I had looked at it before visiting this page. Thanks to firstname.lastname@example.org for mad skill @ reinventing the wheel.