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. :)

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.

Here it goes (I am a Python beginner, so beware):

Alternatively, you can download it from here.

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.

• search engines and databases (directories),
• DNS (bruteforcing),
• common addresses.

He shows that this method is quite successful for those who are interested in getting as many IPv6 addresses as possible. So I was thinking – why not put up a public databases of such addresses and provide a way for anybody to contribute them.

The main purpose of such database is to make IPv6 Internet a bit more “enumeratable” for those who would like doing any kind of research on the nature and behaviour of IPv6 Internet. Also, it may convince those who would like to not be listed (I guess for security through obscurity reasons) to actually renumber from <prefix>::1 to something else.

Of course, any ideas about other possible techniques for harvesting IPv6 addresses, are welcome.

However, I was quite stumped when I realized that if I make an “allow all” mixed (IPv4/IPv6) policy, the ICMPv6 packets are not let through the bridge (I am doing filtering on a bridge interface). This is not really intuitive, so I thought it must be some kind of bug. I still recall, that some time ago, netfilter had serious problems tracking IPv6 connections (it would match improperly match valid connections, which made it impossible to drop the packets, which matched INVALID state).

My rationale was: I should pass all IPv6 packets, which match NEW, RELATED or ESTABLISHED state in both directions and I should be fine. This is also what Firewall Builder generates. However, I found out that ICMPv6 packets other than PING (echo/reply) don’t match netfilter states at all! So that was why Firewall Builder’s policy wouldn’t let my ICMPv6 packets (e.g. neighbor discovery) through.

The solution is straightforward: make an additional “allow any” rule only for ICMPv6 packets and make it stateless. Firewall Builder nicely supports that, you can double click the Options column and check the “Stateless” check box.

• running SharePoint Products and Technologies Configuration Wizard, which failed at step 9/10,
• running “psconfig -cmd upgrade -inplace b2b -wait -force“, which failed with various errors.

Finally, I did this to solve the problem: I connected to Central Administration and then went to “Operations” tab. Then, I chose “Services on Server” and clicked “Windows SharePoint Services Search”. There, I entered my administrator account as the “Service Account”. I saved the changes and then rerun SharePoint Products and Technologies Configuration Wizard, which worked this time (although it took it very long time to do everything it had to do).

This is what I wanted to achieve: have three drives, which would contain two gmirror (RAID-1) arrays (one for root partition, the other for swap) and three gvinum (RAID-5) volumes – for

,

and

. For the latter, it is best to use volume management capabilities of gvinum, which allows you to join only three physical devices (or slices or partitions) with it, so that the logical volumes are created “inside” the vinum manager.

The main problem was, that I forgot how to do this “properly”. It was 2 years since I did this (of course, I didn’t write it down how I did it, although it took me a few hours) last time and since the machine is far away, I don’t have physical access. This would have helped, because I could just put the old drives back and see how they were configured, but the remote system administrator already exchanged the drives and I didn’t want to bother him.

In FreeBSD terms, a partition is a logical unit, which resides on a slice (which is actually a partition from other operating systems’ point of view).  Let’s have four drives on the system:

,

,

and

. We’ll assume that on

there is the system we are booting and running FreeBSD at the moment and we wan’t to create the arrays on the other three drives, which will eventually run by themselves (we’ll pull the

out when we finish). When you create a slice on

, for example, you’ll be able to access it via

. When you create a partition on this slice, you’ll see it as

, where the last letter “a” can also be “b”, “d”, “e”, and so on, you know the alphabet. This naming system is somewhat peculiar, and I don’t like it but I can live with it. The letter “a” usually hosts the root partition, and the letter “b” provides swap space. As you can see, there is no letter “c”. This is because it specifies the whole slice and therefore it should not be used for anything else.

Usually, when you’re setting up the gmirror RAID-1 on FreeBSD, you make put it on the physical drive directly, i.e. you make the

visible as

(after you put the metadata on the drive, by running ‘

‘), which also means that all existing slices and partitions will be visible at the new location. If you had

, you’ll now have

. Which is very nice and makes gmirror very easy to set up after the system was installed. In the end, you just add other mirrors (

, …) in the array and that’s it.

However, if you want to use gvinum on the same drives (to make RAID-5 arrays, for example), you can’t do that. You’ll need to gmirror something else: the slices or the partitions, but not the whole drives. Now FreeBSD allows you to have no slices at all – to create the FreeBSD partitions (the letters) directly on the drive (so you’ll have

). So when I started to think about how I would partition the drives and which units will I merge with gvinum and gmirror, I became a bit confused. So I tried a few ideas I had and none of them really worked because I didn’t know what actually the command such as ”

“, ”

“, ”

“, ”

” and creating slices via ”

” actually do. Where do they write their data? At what offsets and what are the sizes of these metadata? I found it quite annoying that there isn’t much documentation about this (at least not well organized), so I had to do some homework. Here is what I discovered:

gvinum — When you run ”

“, it will rewrite the bytes from

to

, that is from block 8 (first 8 blocks are left untouched) to block 265 with its own configuration data, so you have to be careful not to mess with these blocks.

gmirror — Running ”

” puts gmirror’s metadata on the last block of the device. The size in blocks of the mirror is then number of block of the device – 1.

bsdlabel — When labelling a slice (or the drive directly), bsdlabel writes label information to the second block (from address

on, in my tests it never passed the

limit, which still fits into the second block).

boot0cfg — Since it rewrites the MBR with BootMgr, this means it rewrites the first block (block 0) of the drive.

fdisk — Fdisk writes the slice information into first 16 blocks of the slice. This means, that you shouldn’t label them with bsdlabel (don’t assign them to any of the partitions), or you can have problems.

To sum up, the only configuration, which worked for me on FreeBSD 6.1 (yes, quite old one) was the following. First I created slices on all of the drives (one on each drive) and wrote the BootMgr onto them (you can do this easily by running

and then going to Custom and then Partition. You select the first drive (of the three) and then, when in fdisk-editor, press a and then w to write the slice. When asked about MBR, just say BootMgr and that’s it. This will ensure that there is a boot manager on the drive (which means you can boot from it). You have to repeat this procedure for the other (two) drives as well.

Then, you have to edit the label of all three slices, running “

” (for the slice on the first drive). You have to provide the following partition set:

a:  1048576       16    4.2BSD        0     0     0
b:  4194304  1048592      swap
c: 976768002       0    unused        0     0         # "raw" part, don't edit
d: 971525106 5242896     vinum

In this configuration you can see that the size of “a” (root) partition is 1048576 512-byte blocks which means 512 MB. The offset of 16 blocks for the “a” partition is very important, since the slice needs the first 16 blocks for itself. The size of the “b” (swap) partition is 4 times the size of “a” (2 GB) and the “d” takes all the space left on the slice.

So the idea is to make two gmirror arrays, the first one will consist of the three “a” partitions (remember, we have three hard drives) and will be used as the root partition. The second one will consist of the three “b” partitions and will be used as swap space. All the “d” partitions will be used for the construction of the gvinum array.

First, you need to load the

, which enables kernel to handle the gmirror arrays. You do this by running ”

“. But, it is needed to make this change permanent (so the module will load at boot) so you need to add these two lines to

:

geom_mirror_load="YES"
geom_vinum_load="YES"

This will also enable loading gvinum at boot, which we will need later (when the system will boot from the new arrays). No it’s time to create the arrays. You’ll run something like:

# gmirror label -v -b round-robin root /dev/ad1s1a
# gmirror label -v -b round-robin swap /dev/ad1s1b
# gmirror insert root /dev/ad2s1a
# gmirror insert root /dev/ad3s1a
# gmirror insert swap /dev/ad2s1b
# gmirror insert swap /dev/ad3s1b

This was for the gmirror arrays. Now make a file named

and put this in it:

drive disk1 device /dev/ad1s1d
drive disk2 device /dev/ad2s1d
drive disk3 device /dev/ad3s1d
 volume var
  plex org raid5 491k
   sd length 1024m drive disk1
   sd length 1024m drive disk2
   sd length 1024m drive disk3
 volume tmp
  plex org raid5 491k
   sd length 512m drive disk1
   sd length 512m drive disk2
   sd length 512m drive disk3
 volume usr
  plex org raid5 491k
   sd length 0 drive disk1
   sd length 0 drive disk2
   sd length 0 drive disk3

And then you run:

# gvinum create gvinum.conf

This will create three gvinum RAID-5 arrays – for

,

and

. They will be accessible via

,

and

respectively. You should know, that the size of the RAID-5 array is the sum of the size of all drives – the size of one drive. This makes our

2 GB,

1GB and

the rest. If you execute ”

” now, you’ll see that all the arrays are marked as up. However, this will not be the case after you reboot. I don’t know exactly why, perhaps this is a bug. Also I am not sure if it is present in the newest FreeBSD releases. So it is very important now, that you reboot the system now. After it comes back online, you have to run:

# gvinum start var
# gvinum start usr
# gvinum start tmp

Then you have to wait for the arrays to become synchronized. It may take a while. You can always check status with ”

“. When the arrays are synchronized, you need to create the filesystems on all of them:

# newfs /dev/mirror/root
# newfs -U /dev/gvinum/var
# newfs -U /dev/gvinum/usr
# newfs -U /dev/gvinum/tmp

After that, you should mount these new arrays in

and copy the system, you are running now onto them:

# mount /dev/mirror/root /mnt
# cd /mnt
# mkdir var tmp usr
# chmod 1777 tmp
# mount /dev/gvinum/var /mnt/var
# mount /dev/gvinum/usr /mnt/usr
# mount /dev/gvinum/tmp /mnt/tmp
# cd / && find . -xdev | cpio -pm /mnt
# cd /var && find . -xdev | cpio -pm /mnt/var
# cd /usr && find . -xdev | cpio -pm /mnt/usr
# cd /tmp && find . -xdev | cpio -pm /mnt/tmp

Finally, you have to modify your

file on the root gmirror array. Edit

as follows:

# Device                Mountpoint      FStype  Options         Dump    Pass#
/dev/mirror/swap        none            swap    sw              0       0
/dev/mirror/root        /               ufs     rw              1       1
/dev/gvinum/tmp         /tmp            ufs     rw              2       2
/dev/gvinum/usr         /usr            ufs     rw              2       2
/dev/gvinum/var         /var            ufs     rw              2       2
/dev/acd0               /cdrom          cd9660  ro,noauto       0       0

Now you can try to boot the system from one of the three drives which hold the RAID arrays and you should be lucky. If you aren’t, you are welcome to post comments here and we’ll try to sort it out together.

However, our customers are expecting simple solutions: a single package with their own config file and certificate. Although EJBCA supports generating OpenVPN packages on the fly on the server, it would be a bit more complicated to make it work, because we need to generate different config files for our customers. Which means we would need a special lookup-table (we could use the EJBCA’s MySQL database) which would link specific fields in certificates’ “distingished name” with corresponding OpenVPN config files. This would be possible, but a bit too complicated for now.

So I decided that we create the packages “semi-manually”, i.e. manually but in “batch” mode. First, you need my package which includes OpenVPN source environment (OpenVPN 2.1 RC7) which will be compiled with NSIS into an executable together with the certificate and config files.

Then you need to obtain the certificates for the clients you want to create the packages for and provide the config file as well. You must also install NSIS and then you are ready. Just run “generate.cmd” file in the “openvpn-generator” directory and the executables will be created in “openvpn-generator/exes”.

If you have problems, questions, just let me know.