Nejko’s randomness

Not many people know, that Windows Vista and Windows 7 now support another VPN type called SSTP, which is a kind of SSL VPN. This very useful because a secure L2TP can be somewhat difficult to configure since IPsec has to be configured as well. PPTP is neither secure nor does it pass NATs very well since it leverages GRE protocol. SSTP, on ther other hand, uses HTTPS protocol, so it is easy to configure (well, you still need at least a server certificate) and it passes the NATs very well as all other “nice” TCP protocols.

Recent versions of RouterOS (5.X) also support SSTP, so coupling it with Windows RADIUS server, this becomes an easy VPN solution for SMBs. In this post I will show how this can be done.

MikroTik part

First, you create an IP pool for SSTP IP address assignments:

/ip pool add name=sstp-pool ranges=192.168.1.100-192.168.1.150

Then, you add a SSTP profile:

/ppp profile add dns-server=8.8.8.8 local-address=192.168.0.1 \
name=sstp remote-address=sstp-pool use-encryption=yes use-ipv6=yes

Now its time to configure certificates for SSTP server. You can use StartSSL to get free browser-approved SSL certificates. You will need 4 files:

• ca.pem (StartSSL Root CA) – you get this one at StartSSL
• sub.class1.server.ca.pem (Class 1 Server SubCA) – you get this one at StartSSL
• your.mikrotik.pem (public certificate)
• your.mikrotik.key (private key)

You have to import these files by copying them to your MikroTik device (either via WinBox drag & drop into “Files” window or via FTP) and then doing something like:

/certificate import file-name=ca.pem
/certificate import file-name=sub.class1.server.ca.pem
/certificate import file-name=your.mikrotik.pem
/certificate import file-name=your.mikrotik.key

Except for your.mikrotik.key, you just hit ENTER when you are asked about the “passphrase”. For your.mikrotik.key, you must enter your private key password, if the key is encrypted. If it is not, you can just hit ENTER as well.

Now you can just do some configuration on this certificates you just imported:

/certificate set cert1 name="StartSSL CA"
/certificate set cert2 name="StartSSL Class 1 Server SubCA"
/certificate set cert3 ca=no
/certificate set cert3 name="your.mikrotik"

Now you can configure the SSTP server interface:

/interface sstp-server server set authentication=mschap1,mschap2 \
certificate=your.mikrotik default-profile=sstp enabled=yes

If you are unable to use port 443 for SSTP, you can use “port=” option in the command above to define the listening port. Don’t forget to open this port on the firewall (on the INPUT chain) if you are blocking ports by default.

Enable RADIUS authentication for PPP:

/ppp aaa set use-radius=yes

And configure the RADIUS client:

/radius add address=192.168.0.2 called-id="" disabled=no \
domain=YOURDOMAIN secret=yoursecret service=ppp

Don’t forget to change the IP address to the IP address of your RADIUS server. The same goes for YOURDOMAIN and yoursecret.

Windows part

Last time I was configuring MikroTik to authenticate users I was using Windows 2003 Server and its IAS. However, in Windows 2008 this is now called Network Policy Server and it didn’t work for me until I changed some default configuration options. So this is how I did it.

First, make sure the Network Policy Server (NPS) role is added. If not, add it, its very straightforward. Then, open the NPS management console and click the root node in the left pane (it’s called “NPS (Local)” on my server). Then, just use the wizard to configure the RADIUS server for VPN:

1. Select “RADIUS server for Dial-Up or VPN Connections” as the configuration scenario and click “Configure VPN or Dial-Up”.
2. Choose “Virtual Private Network (VPN) Connections” as “Types of connections”. (You can also change the policy name, but that’s completely optional.)
3. Now you have to add a RADIUS client. Click Add and then choose a friendly name for your MikroTik here and write in its (local) IP address. Also, put in the secret you configured it before on MikroTik (yoursecret, remember?).
4. When choosing the Authentication Methods, I chose also MS-CHAP (v1), but perhaps leaving only MS-CHAPv2 selected will also work (I haven’t tried), since MikroTik should support it as well.
5. Now add the user group, which will contain those users who can authenticate for this VPN connection.
6. You can easily leave out the IP filters.
7. You can probably disable 40 and 56-bit encryption, but I didn’t try that.
8. You don’t need to configure the realm name, just skip it.
9. That’s it!

Now to the tricky part:

1. In the left pane, go to Policies, Connection Request Policies. Double click the “Virtual Private Network (VPN) Connections” policy (or whatever you named your policy above). Now set the “Type of network access server” to “Unspecified”. Also, you have to go to the Conditions tab. Edit the entry (it should be a NAS Port Type condition entry) and change it from “Virtual (VPN)” to “Async (Modem)” (deselect “Virtual” and select only “Async”).
2. Do the same for the Network policy with the same name (Policies, Network Policies). I also set the order of the network policy to be the second (right after General Connection Authorization Policy), but I am not sure if this is needed.

WARNING: I have figured out, that configuring these options is somewhat nondeterministic. This means, that it just didn’t work some times and I had to configure the “Type of network access server” back to “Remote Access Server (VPN-Dial up) and after that back to “Unspecified”. And this time it worked. It appears to me as a bug, but maybe its just me being unfamiliar with Microsoft way of thinking. :)

Yesterday, I tried TAYGA, which is a stateless NAT64 (SIIT actually) userland implementation for Linux. It works pretty well, since it can leverage any “classical” NAT44 implementation to do the stateful part, which is probably what a NAT64 deployer will want to have.

So I installed TAYGA on a virtualized Debian 6.0 box where I also installed Ecdysis’ DNS64 implementation, which is actually a patched BIND.

I just followed the instructions on TAYGA web page and everything went smoothly except for the IPv6 prefix setup. TAYGA says it can use IPv6 prefixes of any length, which is allowed by RFC 6052. So first I tried to use my Hurricane Electric assigned /64 prefix (part of my /48 allocation), and it failed to work, at least with DNS64 from Ecdysis. I haven’t tried TOTD (yet), which is mentioned in the instructions, so this might be causing the troubles. However, after I changed the prefix length to /96 both in BIND and in TAYGA configuration, I was finnaly able to connect to the IPv4 world from the IPv6-only machines.

I think that this kind of stateless NAT64 is quite useful and very easy to deploy (especially for smaller environments). The only “quirk” is in that you have to use a special pool of IPv4 addresses, which TAYGA uses for its temporary (you can make them static as well) 1-to-1 IPv6-to-IPv4 mappings. However, since these IPv4 addresses are only “visible” to the NAT64 gateway (if you are running NAT44 on the same box), I can’t see why this would be a significant problem at all.

Yesterday I came back home from Paris, where I attended the V6 World Congress 2011. Since I am interested in IPv4-IPv6 transitioning mechanisms, I was looking forward to hear Jordi Palet Marinez’s talk on the tutorial day about them. During the talk, Jordi mentioned some interesting statistics – the percentage of IPv6 traffic on the Internet and the shares that Teredo and 6to4 have in this percentage. I can not recall the exact numbers, but it is interesting to me because I was planning to do exactly the same for my PhD research. I had this idea of trying to persuade various ISPs or Internet exchange points to let me plug my statistic-gathering equipment into their switches and gather information about which transitioning mechanisms are most used today and what are their respective shares of packets flowing through.

I talked to Jordi and he suggested to Google a bit about 6meter – this is the software they used to measure traffic at various ISPs. One of them can be found here. Because the ISPs don’t like to give out their actual statistics, he has provide overall statistics only. However, I find the numbers very odd. Two thirds of the packets are IPv6 packets? Almost a half of the bytes are IPv6 bytes? I was talking to a few other people at the conference and they said that this is impossible or at least, that this is a very non-representative sample which can not be used to prove that the findings hold true for the whole Internet. The actual IPv6 packet/byte percentages should be a lot smaller than Jordi’s.

Anyway, I am very interested in this topic, so I am still trying to find any other similar published research. If you know of any, please let me know.