MPLS, part II: VRF-aware MPLS-VPN.

Where MPLS part I explains the basics of labeling packets, it’s not giving any advantage over normal routing, apart from faster table lookups. But extensions to MPLS allow for more. In this article I’ll explain MPLS-VPN, and more specifically a Virtual Private Routed Network (VPRN).

A VPRN is a routed (layer 3) network over an MPLS cloud, that is VRF-aware, or customer-aware. This means several different routing instances (VRFs, remember?) can share the same MPLS cloud. How is this achieved when there’s only a point-to-point link between routers with one IP address? After all, an interface can only be assigned to one VRF. Solution: by adding a second MPLS label to the data: the ‘outer’ label (the one closest to the layer 2 header) is used to specify the destination router, the ‘inner’ label (closest to the original layer 3 header) is used to specify to which VRF a packet belongs. The outer label workings are identical to standard MPLS: these are learned by LDP and matched with a prefix in the routing table. But for the inner label, a VRF-aware process needs to run on each router that can handle label information and propagate it to other routers. That process is Multiprotocol-BGP, or MP-BGP.

The outer label is used to route the packet through the MPLS cloud, and the last router(s) use the inner label to see to which VRF a packet belongs. Let’s look at the configuration to understand it more. First, the basic setup:

Notice the router names, as these are often used in MPLS terminology.

• The Customer Edge router a router that directly connects to a customer network. It’s usually the demarcation point, where the equipment governed by the MPLS provider begins. Contrary to the name, the CE itself is often managed by the provider as well.
• The Provider Edge router is the ‘first’ router (seen from a customer site point of view) that has MPLS enabled interfaces. It’s where the labels are applied for the first time.
• A Provider router is a router completely internal to the MPLS cloud, having only MPLS enabled interfaces.

The connection between CE and PE is a point-to-point so a /30 subnet is logical. Routing between CE and PE is done using a simple routing protocol, like RIP, OSPF, EIGRP or even static or standard BGP. The only notable part is that the PE router has to use a VRF to place the customer in. Below an example configuration:

Router-CE(config)#interface G0/1
Router-CE(config-if)#ip address 10.1.0.1 255.255.255.252
Router-CE(config-if)#exit
Router-CE(config)#router ospf 1
Router-CE(config-router)#network 10.1.0.0 0.0.0.3 area 0

Router-PE(config)#vrf definition VRF
Router-PE(config-vrf)#address-family ipv4
Router-PE(config-vrf-af)#exit
Router-PE(config-vrf)#exit
Router-PE(config)#interface G0/1
Router-PE(config-if)#vrf forwarding VRF
Router-PE(config-if)#ip address 10.1.0.2 255.255.255.252
Router-PE(config-if)#exit
Router-PE(config)#router ospf 2 vrf VRF
Router-PE(config-router)#network 10.1.0.0 0.0.0.3 area 0
*Mar  1 00:06:20.991: %OSPF-5-ADJCHG: Process 2, Nbr 10.1.0.1 on GigabitEthernet0/1 from LOADING to FULL, Loading Done

If you happen to run a router on an IOS before 15.0, the commands for the VRF change: it becomes ‘ip vrf VRF’ to define a VRF, without the need to specify an address family, as 12.x IOS versions aren’t VRF aware for IPv6. On the interface, the command is ‘ip vrf forwarding VRF’.

So far so good. Now on to activating MPLS between the PE and the P router, and making sure the routers learn the MPLS topology:

Router-PE(config)#interface G0/2
Router-PE(config-if)#mpls ip
Router-PE(config-if)#ip address 10.0.0.1 255.255.255.252
Router-PE(config-if)#ip ospf network point-to-point
Router-PE(config-if)#exit
Router-PE(config)#interface Loopback0
Router-PE(config-if)#ip address 10.0.1.1
Router-PE(config-if)#exit
Router-PE(config)#router ospf 1
Router-PE(config-router)#network 10.0.0.0 0.0.1.255 area 0

Router-P(config)#interface G0/1
Router-P(config-if)#mpls ip
Router-P(config-if)#ip address 10.0.0.2 255.255.255.252
Router-P(config-if)#ip ospf network point-to-point
Router-P(config-if)#exit
Router-P(config)#interface Loopback0
Router-P(config-if)#ip address 10.0.1.2 255.255.255.255
Router-P(config-if)#exit
Router-P(config)#router ospf 1
Router-P(config-router)#network 10.0.0.0 0.0.1.255 area 0
*Mar  1 00:02:29.023: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.1 on GigabitEthernet0/2 from LOADING to FULL, Loading Done
*Mar  1 00:02:33.127: %LDP-5-NBRCHG: LDP Neighbor 10.0.0.1:0 (1) is UP

The ‘ip ospf network point-to-point’ is not really needed but used to reduce OSPF overhead. The loopbacks are needed for BGP later on.

Up until this point, we have MPLS in the default VRF and a separate VRF per customer for routing, but no routing of the VRFs over the MPLS. To exchange the inner labels needed to specify the VRF, MP-BGP between PE and P is configured:

Router-PE(config)#router bgp 65000
Router-PE(config-router)#neighbor 10.0.1.2 remote-as 65000
Router-PE(config-router)#neighbor 10.0.1.2 update-source Loopback0
Router-PE(config-router)#no address-family ipv4
Router-PE(config-router)#address-family vpnv4
Router-PE(config-router-af)#neighbor 10.0.1.2 activate
Router-PE(config-router-af)#neighbor 10.0.1.2 send-community extended

Router-P(config)#router bgp 65000
Router-P(config-router)#neighbor 10.0.1.1 remote-as 65000
Router-P(config-router)#neighbor 10.0.1.1 update-source Loopback0
Router-P(config-router)#no address-family ipv4
Router-P(config-router)#address-family vpnv4
Router-P(config-router-af)#neighbor 10.0.1.1 activate
Router-P(config-router-af)#neighbor 10.0.1.1 send-community extended
*Mar  1 00:11:31.879: %BGP-5-ADJCHANGE: neighbor 10.0.1.1 Up

Again some explanation. First off, BGP neighbors always need to be defined under the main process, after which they need to be activated for a specific address-family. The ‘no address-family ipv4’ command means that no conventional routing information for the default VRF will be exchanged (we already have OSPF for that). The ‘address-family vpnv4’ activates the VPRN capability, and the label exchange for VRFs. In this process, the neighbor is activated. The ‘send-community extended’ means BGP will exchange the community Path Attributes (PA), in which the label information is present. The loopbacks are used to connect to each other, not only for redundancy in case a physical interface should go down, but also because LDP does not exchange labels with another router on a connected subnet for that subnet. This means that if the directly connected interfaces are used as BGP neighbors, the BGP process can’t figure out the labeling properly.

So VRF-aware MPLS is running now, but on each PE router it needs to be specified which VRF needs to be injected in the MPLS cloud. MP-BGP does this using import and export of routing tables. For MP-BGP, a route needs to be uniquely identified, and explained to which VRF it belongs. This is done with a Route Distinguisher (RD) and Route Target (RT). Both are 64 bits, and usually in the format AS:nn, or the first 32 bits the AS number and the last 32 bits a unique chosen number.

• RD uniquely identifies a route. Inside MP-BGP, a route is prepended with its RD, e.g. 65000:1:192.168.1.0/24. This way, if the route exists twice (in different VRFs), it’s still unique because the RD part of the prefix is different.
• RT specifies to which VRF a route belongs. It handles the import and export of routes from a VRF to the BGP process. In its basic form, it’s the same number as the RD, and the same at all PE routers for a certain client.

Configuration of these parameters is done inside the VRF:

Router-PE(config)#vrf definition VRF
Router-PE(config-vrf)#rd 65000:1
Router-PE(config-vrf)#route-target both 65000:1

Now that the VRF can be used in the BGP process, it is imported in the process as following:

Router-PE(config)#router bgp 65000
Router-PE(config-router)#address-family ipv4 vrf VRF
Router-PE(config-router-af)#redistribute ospf 2

The redistribution, of course, needs to be mutual between OSPF and BGP, so a few more lines of configuration are needed to complete everything:

Router-PE(config)#router ospf 2 vrf VRF
Router-PE(config-router)#redistribute bgp 65000 subnets

And now everything is completed: the PE router learns routes from the P router by OSPF, and redistributes it into BGP to propagate them over the MPLS cloud. From this point on, configuration is modular: on another PE router, the configuration is likewise. Adding a P router isn’t any different from the P router in this example, the processes and parameters are the same each time. Do remember that routers don’t advertise iBGP-learned routes to other iBGP peers, so the PE and P routers need to form a full mesh, unless you’re using route reflectors or confederations.

Advertisement

Site-to-site VPNs part IV: Vyatta

A free version of the new Vyatta 6.4 with a remarkable straight-forward configuration for VPN if you’re getting familiar with the concepts (which, if you’ve read the first three parts of this series, should be the case now). Just like the previous example, this will use 3DES, MD5, PFS, DH Group 2, and some default lifetimes. Vyatta also supports SHA and AES-128 and AES-256. Strange but true: AES-192 does not seem to be an option. If anything is unclear, Part I may have the answer.

On to the config. To cover it completely, first the interface configuration and a default route, as the VPN relies on routes to decide where to route traffic before encryption (just like the Cisco devices).

set interfaces ethernet eth0 address ip-address/netmask
set protocols static route 0.0.0.0/0 next-hop gateway-address

Phase 1 parameters:

set vpn ipsec ike-group IKE lifetime 86400
set vpn ipsec ike-group IKE proposal 1 encryption 3des
set vpn ipsec ike-group IKE proposal 1 hash md5
set vpn ipsec ike-group IKE proposal 1 dh-group 2

Just like with Cisco, the proposal number is for the order in which the different proposals are examined. Phase 2 is no different from that:

set vpn ipsec esp-group ESP lifetime 3600
set vpn ipsec esp-group ESP mode tunnel
set vpn ipsec esp-group ESP proposal 1 encryption 3des
set vpn ipsec esp-group ESP proposal 1 hash md5
set vpn ipsec esp-group ESP pfs dh-group2

PFS is optional, of course. Now, IPsec has to be activated on a per-interface basis. Again, a simple command for the outgoing interface:

set vpn ipsec ipsec-interfaces interface eth0

Finally, the definition of a VPN peer, it’s parameters, shared key, local and remote subnets, and Phase 1 and Phase 2 proposals:

set vpn ipsec site-to-site peer peer-ip-address
set vpn ipsec site-to-site peer peer-ip-address local-ip local-address
set vpn ipsec site-to-site peer peer-ip-address authentication pre-shared-secret key
set vpn ipsec site-to-site peer peer-ip-address ike-group IKE
set vpn ipsec site-to-site peer peer-ip-address tunnel 1 esp-group ESP
set vpn ipsec site-to-site peer peer-ip-address tunnel 1 local subnet source-network/mask
set vpn ipsec site-to-site peer peer-ip-address tunnel 1 remote subnet destination-network/mask

That’s it. In fact, I’ve found this to be one of the most simply CLI-based VPN configurations I’ve come across so far. The only thing slightly different from most configurations is the requirement of the local-ip parameter. Usually, this is set to the IP address of the outgoing interface, but it can be interesting to set this to a loopback address for which a route is known, so failure of a physical interface does not terminate the VPN connection.

Site-to-site VPNs part III: Cisco ASA

Third part of the S2S VPN series. Again with Cisco, but this time on an ASA. Since the ASA can be managed in GUI with ASDM, configuration is quite straightforward.

The S2S VPN configuration menu can be found under ‘Configuration’, ‘Site-to-Site VPN’. There you can add a new VPN connection, or edit an existing one.

The configuration menu needs little explanation, as it nicely covers everything a S2S VPN needs (see part I). Only worth noting is IKEv2, which isn’t used a lot these days and can safely be disabled. The IKE and IPsec proposals are already filled in with all supported combinations. The VPN will work this way but it can be easier to troubleshoot and understand to just allow the proposals that are needed for a VPN.

If you want to use PFS, it can be found under ‘Advanced’, ‘Crypto Map Entry’, together with some more options.

Unfortunately, seeing whether a VPN is up or not in the GUI isn’t possible. But the GUI does have logging, which can show the buildup and even reasons for failure in real-time. The CLI, just like with a Cisco IOS, uses the commands ‘show crypto isakmp sa’ for Phase 1 and ‘show crypto ipsec sa’ for Phase 2. Straightforward, isn’t it?

Site-to-site VPNs part II: Cisco IOS

Now that the theory has been explained, on to the first S2S VPN configuration. This example will use 3DES and MD5, DH Group 2, and some default lifetimes.

In Cisco terminology, ‘isakmp’ is used for Phase 1, and ‘ipsec’ for Phase 2 (many systems refer to it this way). VPN uses encryption, so most commands are done using the ‘crypto’ engine. The config for the first Phase is logical:

Router(config)#crypto isakmp policy 1
Router(config-isakmp)#encryption 3des
Router(config-isakmp)#hash md5
Router(config-isakmp)#group 2
Router(config-isakmp)#authentication pre-share
Router(config-isakmp)#lifetime 86400
Router(config-isakmp)#exit

The policy number does not have to match with the rest of the upcoming configuration. In fact, the IOS tries to use all Phase 1 proposals configured for all VPN peers until a matching one is found, e.g. if policy 1 matches, then it will be used, if it doesn’t, policy 2 will be tried, and so on.

This is not a complete Phase 1 configuration: though pre-shared key authentication is specified, no key is entered. A key needs to be entered on a per-peer basis using the following command:

Router(config)#crypto isakmp key 0 key address peer-ip-address

For Phase 2, some more parameters are required. First the ‘transform set’, which is how the packets will actually be encrypted.

Router(config)#crypto ipsec transform-set VPN-1 esp-3des esp-md5-hmac
Router(cfg-crypto-trans)#exit

This needs some more explaining:

• The name is free to choose. Try to keep it consistent, I usually start the name with ‘VPN-‘ here.
• The ‘esp’ in ‘esp-3des’ means the use of the Encapsulating Security Payload (ESP) header. The other option, Authentication Header (AH) is rarely, if ever, used.
• HMAC, or Hash-based message authentication code, specifies the mathematics for the encryption, and it’s the only available option.
• You can set transport or tunnel mode in the configuration. It defaults to tunnel mode and unless transport mode is needed for a specific reason, it’s the best way.

Next the encryption domain. Not surprisingly, IOS uses an extended access-list for this.

Router(config)#ip access-list extended AL4-VPN-1
Router(config-ext-nacl)#number permit ip source-network wildcardmask destination-network wildcardmask
Router(config-ext-nacl)#exit

I like to use naming conventions and best practices. My encryption domain access-lists are usually named ‘AL4-VPN-…’ and use sequence numbers for clarity. Also, it’s perfectly possible to use single hosts in an accesslist (wildcard 0.0.0.0 or ‘host’ keyword), and you can use multiple lines to send multiple subnets through the tunnel. Of course, the remote peer should have the same encryption domain, but his source subnets should be your destination subnets, and vice versa.

The above two parts of the Phase 2 now need to be connected together, and the remaining parameters (lifetime, peer IP, optionally PFS with a DH group) need to be added. Then, an interface has to be selected that will form the VPN. This is the final step, and it’s all done inside a crypto map:

Router(config)#crypto map VPNMAP 1 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
Router(config-crypto-map)# set security-association lifetime seconds 3600
Router(config-crypto-map)# set transform-set VPN-1
Router(config-crypto-map)# set pfs group2
Router(config-crypto-map)# set peer peer-ip-address
Router(config-crypto-map)# match address AL4-VPN-1
Router(config-crypto-map)# exit
Router(config)#interface interface
Router(config-if)#crypto map VPNMAP
Router(config-if)#exit

The ‘1’ used above is the sequence number. You can only assign one crypto map name per interface. To have multiple VPNs through the same interface, create crypto maps with the same name, but different sequence numbers.

Also, depending on the platform, sometimes a (static) route out of the VPN enabled interface for the remote subnet is needed, although usually a default route will do. Either add the static routes manually, or issue ‘reverse-route static’ under the crypto map configuration, after which the routes will automatically be created.

The VPN is now configured but will not come up until it is triggered by ‘interesting traffic’, traffic matching the access list that needs to be encrypted. Troubleshooting is done using ‘show crypto isakmp sa’ for Phase 1 and ‘show crypto ipsec sa’ for Phase 2. These commands and their subcommands give an indication if the VPN is up.

That concludes the Cisco IOS VPN configuration. Other platforms will be described in upcoming parts!

Site-to-site VPNs part I: theory.

The different types of VPN I’ve explained before, but in the upcoming articles I’ll cover more configuration details of site-to-site (S2S) VPN connections on different platforms. To set up a S2S VPN and connect two or more remote subnets to each other, first some theory about the required parameters. I’m not going to cover everything in-depth, just enough to set up the VPN.

A VPN uses encryption and hashing: encryption so no outsider can capture useful data, and hashing to verify that the sender the data is who he says he is and no alteration of data was done in transit.

First encryption. Important to understand here is that no encryption is truly unbreakable. Any key or encryption can be broken with brute-forcing: just trying all possible combinations until the right one is found. The encryption standards just have a massive amount of combinations, making this nearly impossible, e.g. 128-bit keys yield 3.4*10³⁸ possibilities.

There are many possible encryption schemes, but these two are used the most:

• 3DES, uses 168-bit keys to encrypt data. It’s been around since 1998 and some weaknesses have been found, but none that bad that encryption can be broken in a reasonable amount of time.
• AES, which uses 128, 192 or 256-bit keys. One weakness has been found so far, now requiring four times less computational power to break AES, but still well beyond any reasonable time frame (modern-day computers would still need millennia).

Blowfish encryption is an open standard, but not widely supported in vendor products so rarely seen in production environments. Most devices do support DES encryption (yes, 3DES is derived from it), but DES is considered breakable and insecure.

Hashing, the other main VPN parameter, also comes in two widely used flavors:

• MD5, while using 128-bit hashes, is considered insecure. A modern-day multi-core computer can break the encryption in less than a minute.
• SHA. SHA-1 uses a 160-bit hash, but has weaknesses and just like MD5 is supposedly cracked in less than a minute. SHA-2 however uses several different key lengths and has as of this article’s date not yet been broken, which makes it the only safe hash with support on many platforms.
  SHA-3 is a new standard that was announced just this month, and has no practical implementations yet.

While most of these hashing methods by themselves are insecure, they are still widely used in VPNs because the encryption provides sufficient protection already (the hash is also encrypted). Adding to the confusion, some platforms mention ‘SHA’ without indication about the version.

A third important parameter is the Diffe-Hellman (DH) group used. DH is a method of key exchange, since during the initial setup of a VPN, the VPN peers must exchange encryption keys. If these keys are captured by an outsider, the entire VPN can still be decrypted. DH solves this problem mathematically so peers can derive each others keys without sending them unmodified. The DH group means the length of the algorithm:

• DH Group 1: 768-bit group
• DH Group 2: 1024-bit group
• DH Group 5: 1536-bit group
• DH Group 7: 163 bits elliptical curve field

While most implementations simply ask the group, some ask for bit-length. Group 2 and 5 are used widely, and generally group 1 is not recommended because it’s suspected to be breakable in a reasonable amount of time with realistic computational power. DH Group 7 is a special one: it’s made for devices with low processing power, like PDAs. I couldn’t find any objective source claiming this encryption is better or worse than group 5, but most seem to agree it’s less secure.

Another important parameter is the mode used to connect: main mode or aggressive mode. Cisco also supports quick mode, see their site for a brief explanation. Quick mode is rarely used.

And last but not least: the timers. The VPN will renegotiate from time to time. Unlike the previous parameters, if these timers do not match on both ends, the VPN might come up, but will become unstable and disconnect from time to time.

Now that all important parameters are listed, one more thing: a VPN connection consists of two phases. Phase 1 is the initial setup of a secure tunnel, using a common encryption, hashing, renegotiation timer and DH group. Inside that secure tunnel, parameters for the actual encrypted tunnel for data are negotiated: again encryption, hashing, a timer and optionally a maximum data limit before renegotiation. This is Phase 2. Also optionally, during Phase 2, you can use ‘Perfect Forwarding Secrecy’ (PFS), which means Diffie-Hellman key exchange will be used again inside the secure tunnel.

Note  that the parameters (encryption, hashing, timers and optionally DH group) do not have to match between Phase 1 and Phase 2: you can use AES-256 SHA-2, DH group 5 for Phase 1, and a less resource-intensive 3DES MD5 DH group 2 for Phase 2, for example. Obviously, they have to match between the two connecting devices.

Edit 28/10/2012: looks like I forgot two important facts:
1) The Phase 2 also needs to list the traffic to encrypt, usually in a ‘from subnet x to subnet y’ form. Sometimes referred to as ‘encryption domain’.
2) How do the VPN peers actually exchange policy information? Through the exchange of IKE packets on UDP port 500, containing the Phase 1 information.

That concludes the theory. In the following articles, I’ll explain how to set up a VPN connection on different platforms. Stay tuned!

Different types of VPN explained.

Since I’m going to talk more about VPNs in the upcoming weeks, I’m going to explain the different types of VPN here. No configuration guides, but an explanation so it’s clear what is what.

For those who aren’t sure what a VPN is: a Virtual Private Network is an encrypted connection between two or more devices over a public network. Some may argue that it doesn’t necessarily has to be encrypted, but when it’s not, that’s called a tunnel (for me at least). Here’s a list of the types:

Site-to-site VPN
Often abbreviated to S2SVPN. It’s a connection between two sites and encrypts all traffic between two (or multiple) subnets. There are two types of S2SVPN:

• Policy-based: interesting traffic triggers an ACL and is encrypted and sent to the remote VPN peer.
• Routed: traffic is routed into an encrypted tunnel to the remote VPN peer.

For a detailed explanation and configuration, Jeremy made some excellent posts about this on Packetlife: Part 1 for policy-based and Part 2 for routed.

DMVPN
A dynamic multipoint VPN is not a protocol but more a technique using different protocols. One or more central hub routers are required, but the remote (spoke) routers can have dynamic IPs and more can be added without having to modify the configuration on the hub router(s), or any other spoke routers. The routers use a next-hop resolution protocol, combined with a dynamic routing protocol to discover remote peers and subnets. The VPN itself is a mGRE tunnel (GRE with multiple endpoints) which is encrypted. This way, traffic between spoke routers does not have to go through the hub router but can be sent directly from spoke to spoke.

Client VPN
A client VPN is an encrypted connection from one device towards a VPN router. It makes that one remote device appear as a member of a local subnet behind the VPN router. Traffic is tunneled from the device (usually a computer or laptop of a teleworker) towards the VPN router so that user has access to resources inside the company. It requires client software that needs to be installed and configured.

SSLVPN
This type of VPN works like a client VPN. The difference is that the remote client does not need preconfigured software, but instead the browser acts as VPN software. The browser needs to support active content, which every modern browser supports, either directly or through a plug-in. Traffic is tunneled over SSL (or TLS) to the SSLVPN router. From a networking perspective, traffic is tunneled over layer 4 instead of layer 3. The benefit is that the remote user does not need to configure anything and can simply log in to a web page to start the tunnel. The drawback that you’ll likely need a dedicated device as SSLVPN endpoint because this is not a standard feature.

Deploying Vyatta VPN server on dynamic IP.

Yes, I’m really fond of using Vyatta these days. Easy command line, not a resource-hungry system, runs in a VM,… Loving it. I do have to point out that my success with it is mostly from online tutorials and a lot of trail-and-error, as I find the official documentation is unclear about a lot of details. But ‘basic’ network stuff, like setting up a VPN server, works fine. Too bad I haven’t quite figured out yet how to use Vyatta (or any other software) as an IPv6 VPN server, so the following tutorial covers IPv4 only.

First thing to check when deploying a client-server VPN is making sure there’s no subnet overlap. Earlier experiments with VPN and a remote connection behind NAT, both in the same subnet, did not work. For this reason I migrated my own network to the 192.168.168.0/24 subnet a month ago.

Second thing is making sure a remote VPN connection is possible. I’m behind a NAT device so port forwarding is needed. I’m setting up a standard Windows PPTP VPN, which uses TCP port 1723 for control, and a GRE tunnel for the actual transport. In this case, forwarding port 1723 usually is sufficient.

Once this is done, the actual configuration of the VPN server on the Vyatta:

reggle@vyatta# set vpn pptp
[edit]
reggle@vyatta# set vpn pptp remote-access authentication mode local
[edit]
reggle@vyatta# set vpn pptp remote-access authentication local-users username reggle password 123
[edit]
reggle@vyatta# set vpn pptp remote-access client-ip-pool start 192.168.168.10
[edit]
reggle@vyatta# set vpn pptp remote-access client-ip-pool stop 192.168.168.29
[edit]
reggle@vyatta# commit

This is the minimum configuration. It configures the VPN server and allows one user to log in. You can add as many users as you like by repeating the command with the username and password, or you can configure a remote RADIUS server:

reggle@vyatta# set vpn pptp remote-access authentication mode radius
[edit]
reggle@vyatta# set vpn pptp remote-access authentication radius-server 192.168.168.5 key 456
[edit]

Also, you can define a DNS server with ‘set vpn pptp remote-access dns-servers server-1 192.168.168.2’. Don’t forget to exclude the addresses used for VPN on your network’s DHCP server to avoid duplicate IPs.

To set up a Windows 7 client computer, go to ‘Network and Sharing Center’, next ‘Set up a new connection’, and enter the details asked (type VPN, IP, username, password). Sometimes, this does not work. If this is the case, go to the VPN properties in the ‘Network Connections’ page, and under the tab ‘Security’ choose PPTP instead of Automatic for the Type of VPN.

One thing to keep in mind now is that, when dialing in from a Windows computer, by default all traffic including internet access, will flow through the VPN. You can change this on the client only: go to the VPN properties, tab ‘Networking’, select ‘Internet Protocol Version 4’ and choose ‘Properties’ again, next ‘Advanced…’, and there should be a check box ‘Use default gateway on remote network’. Unchecking it makes sure the local internet connection is used.

That enables proper VPN connectivity, but if you don’t have a business-grade internet connection like me, you’ll most likely have a dynamic IP that changes from time to time. It’s possible to bind that dynamic IP to a DNS record using a public free dynamic DNS service. I used dnsdynamic.org and registered a free subdomain of dnsdynamic.com. You can always log in on the website to change the IP to your current IP, or install an automatic updating tool. This way, you don’t have to write down your IP every time you want remote access to your home network.