The MikroTik Security Guide and Networking with MikroTik: MTCNA Study Guide by Tyler Hart are available in paperback and Kindle!
PPTP is still one of the most ubiquitous VPN technologies in use. It's also one of the oldest, and unfortunately while it does provide encryption it's one of the least secure. However, PPTP is still widely supported by almost all routing platforms, and Windows, Mac, Linux, and most smartphones like Android come with a PPTP client built-in. The encryption it uses isn't as robust as IPSEC and doesn't use PFS, but we can do a couple configuration tweaks to make it as secure as possible. At the same time it isn't sending everything in the clear like GRE or EoIP tunnels do. PPTP is commonly used in a "road warrior" configuration, with remote clients on laptops and tablets VPNing into a network from the road. PPTP can also be used to create routable interfaces on two Mikrotik device and function as a site-to-site tunnel. Put multiple Site-to-Site tunnels together all connecting to a core location and you now have a routable hub and spoke topology.
This article will focus on creating a site-to-site VPN tunnel using PPTP. We'll use static routes on each router that allow devices in one LAN to communicate with devices in the other. The topology being used is the same one in the MPLS with VPLS article, but the Seattle and Santa Fe LER devices have been converted to customer-owned routers. The topology is shown below:
Mikrotik PPTP Site to Site Topology
The requirements for this network aren't too complicated - connect customer LAN networks 192.168.1.0/24 and 192.168.5.0/24 via a PPTP tunnel over a provider's network. This is a cheaper alternative to MPLS tunnels, though in fairness it is also a very different technology and somewhat legacy. The Seattle customer router will be the PPTP server, and the Santa Fe router will run the PPTP client. It could be the other way around, it doesn't matter, as long as one router is the server and the other is the client. First we'll enable the PPTP server on the Seattle router:
/interface pptp-server server set authentication=mschap2 enabled=yes /ppp profile set [ find name=default-encryption ] name=default-encryption use-encryption=required
I've specifically set the authentication to MSCHAP v2 because that is the best encryption that PPTP can handle, and we don't want to use anything less than that. We'll also set the PPTP profile being used to require encryption, it's no longer optional.
Next on the Seattle router we'll set up the credentials that the Santa Fe PPTP client will use to establish the tunnel:
/ppp secret add local-address=10.0.0.1 name=santafe password=supersecretpassword remote-address=10.0.0.2 service=pptp
This PPP secret is what the PPTP client will use to establish the tunnel. It has a username (santafe), a password, the local address that will be dynamically assigned to the PPTP server, and the remote address that will be dynamically assigned to the PPTP client. The IP addresses I chose for the PPTP tunnel are totally arbitrary, you can use whatever you want as long as they don't overlap with anything already in use.
We also need to put some firewall rules in to allow PPTP (which uses GRE) into the firewall:
/ip firewall filter add chain=input comment=PPTP dst-port=1723 protocol=tcp src-address=72.156.30.2 add chain=input comment=PPTP protocol=gre src-address=72.156.30.2
This allows PPTP traffic from the Santa Fe router into the Seattle router. I've only opened up PPTP to a specific source address, and I suggest you do the same. That wraps up the configuration on the PPTP server side in Seattle, let's look at Santa Fe. First thing to do is add those same firewall rules, just with Seattle's source IP address:
/ip firewall filter dd chain=input comment=PPTP dst-port=1723 protocol=tcp src-address=72.156.29.2 add chain=input comment=PPTP protocol=gre src-address=72.156.29.2
Then we'll make sure encryption is being required in the Santa Fe PPTP profile, just like on Seattle's router:
/ppp profile set [ find name=default-encryption ] name=default-encryption use-encryption=required
Next we'll create the PPTP client that connects to the Seattle router:
/interface pptp-client add allow=mschap2 connect-to=72.156.29.2 disabled=no mrru=1600 name=Seattle \ password=supersecretpassword user=santafe
At this point the PPTP client should automatically connect, and a dynamic PPTP interface is created. The IP addresses assigned in the PPP secret will now be set dynamically on both routers as well. On the Seattle PPTP server you should see something like this for interfaces:
Mikrotik PPTP Server Interface
And on the Santa Fe PPTP client you should see something like this:
Mikrotik PPTP Client Interface
On the PPTP server you can see the 10.0.0.1 address that was dynamically (D) assigned when the PPTP client connected:
On the PPTP client side you can see the same thing, just with the other IP address:
The final step is adding the static routes, pointing traffic from one LAN to another over the new tunnel. Because PPTP creates interfaces and assigns IPs that can be used for routing we could use a dynamic routing protocol like OSPF, but because this implementation is so small I'm opting for static routes.
On the Seattle router:
/ip route add comment="Santa Fe LAN" distance=1 dst-address=192.168.5.0/24 gateway=10.0.0.2
On the Santa Fe router:
/ip route add comment="Seattle LAN" distance=1 dst-address=192.168.1.0/24 gateway=10.0.0.1
Traffic destined for the opposite LAN goes to the opposite side of the tunnel, hitting the other router which hands off the traffic to the LAN port. In this case we've used static routes for simplicity, but you could also use OSPF or another routing protocol.
