tirsdag 21. juli 2015

E.T. phone home - piVPN as a remote network access point for all your network resources

My  original homemade plexi casing for the RPi 2 made it look a little bit like E.T. ,with it's "long head" and USB ethernet cards "eyes".

piVPN's E.T. phone home

While E.T. himself made a "makeshift communicator" (among its parts was a Speak & Spell, an umbrella lined with tinfoil, and a coffee can filled with other electronics) to phone home, the piVPN RPi version of "phone home" can do a lot more than just to call home using audio.
E.T.'s makeshift communicator

The piVPN "phone home" box act as a an wired and wireless access point to bridge all network resources in a home or office to any networked device over a VPN line. Also you can connect several devices to the "phone home" box at the same time. As the VPN is bridged, all the devices will look like they are a part of the main network. 
For example they get their IP addresses by the main DHCP server in the office, and they are also able to log on to active directory as they where in the office.
The IT admins in the office does not need to know anything about the exact network configuration on the remote site where the piVPN connects from. 
The connection to the "phone home box" it self can be over a 3g/4g phone, a cable to a switch, a wifi guest network or whatever available on the site you are connecting it from.
Network traffic is encrypted between the "phone home box" and your main office, making this system safe over untrusted networks. 
Network devices that are used by other people on any remote open networks that you connect your "phone home box" to, will not be able to see or access your devices or network.
The piVPN is also able to run on a solar powered battery. 
This makes it a very portable mobile field solution too. 

Best of all... It is based on opensource software, small and cheap hardware, and it is very configurable :-)

First a quick drawing on how this is done:

In the main network (this can be your office, home or wherever you have your main network resources) we will need to install a SE VPN server, which can be downloaded from here:

You could install this VPN server on a RPi 2, a windows or a linux box.
In this case I will install it on a old windows 7 pizza box, as it is less fuzzy about routing. The linux installation tend to have some issues sometimes with how the kernel sets up the routing tables.
This is fixable, but requires some extra work recompiling the linux kernel for the VPN server.

So I just get my windows 7 pizza box, and install the SE VPN server software from here.

The SE VPN official how-to is found here

Make sure you also install the server manager software that comes with the package, as we will need that later to configure the bridge on the pivpn "phone home" box.

The VPN mode you install is VPN server (central) that accepts connections from other servers.

During the installation you will be asked if you want to use a dynamic DNS name and a azure DNS name (this makes it possible to connect to your office trough the microsoft cloud).
Security wise it is not recommended to use these settings, but  for this experiment (and ease) we will do it for now.
You can try to suggest a name that you will actually remember instead of the SE auto-generated one if you want to and write it down.

I would recommend to give your PC a static IP address and NAT' the port 443 through your router to that IP address. This will guarantee a TCP connection between the remote host and your office using https. If not the system may be running on UDP which is more unstable. 
Even though SE VPN support several ports, 443 is the most practical one, as this port is normally open on all remote networks that you are able to access internet from.

If you don't have access to open ports or do changes on your router, you can just use the azure cloud DNS name (the vpnazure.net address given to you during the SE VPN server install).
This ensures a link from your VPN server to the cloud. A remote VPN client will then connect to the cloud server, and access your network through this (note that this may be a very slow link).

When the installation is done connect to the server with the "SE VPN manager" application which is installed during the SE VPN server setup.
When you connect to the localhost the first time it wants you to create a new admin password for the VPN server. Choose a long safe password. This password is for connecting to the server using the "SE VPN manager" application.
Now create a new "virtual hub", the system normally suggest the name "VPN" for this virtual hub.
Create a username and a password for the virtual hub.This is the username and password to be used for VPN clients (and bridges) that connects to the server
Create a "local bridge setting" for the virtual hub (this will be the  physical network card as this is not a multi homed PC). If you plan to have a lot of traffic, you should get one physical network card per virtual hub, but this is way out of scope for our simple setup.

Now the VPN server should look like somthing like this:
The virtual hub name is home and is online
It got two users
You will be able to see the 
softether.net DDNS and vpnazure.net DNS names 
at the bottom of the window.

You should test that it is working by connecting with a SE VPN client from another machine.

When you know the server is working, we can go ahead with the "phone home" box.

To keep control of the device ID name, I just start with a clean RPi 2, connected to my network switch using the built in ethernet card eth0, a USB keyboard connected to a USB port and freshly installed raspbian OS (16 gb SD card formatted with SDFormatter and 2015-05-05-raspbian-wheezy.img added using win32imager).

On my main windows machine I start putty and ssh to the machine.

First thing to do is to install and run the vpn bridge script

wget http://home.pivpn.net/pivpnbridgeinstall.sh
chmod 777 pivpnbridgeinstall.sh

If all the current RPi network settings are OK, there is nothing much to to do just now. Just wait for the RPi to finish the script and reboot (approx. ten minutes).

After the RPi reboot you should see a message on the console that the VPN bridge daemon has started (e.g. "The SoftEther VPN Bridge service has been started")

So now on to the hardware to be added to our RPi:
What we want to do

eth0 (the built in ethernet card) - This will be available to connect to remote switches using a network cable 

eth1 (aadded usb ethernet port) - Available as a cabled bridged port (A port to directly connect you remote PC by cable. When you are connected a virtual network cable between your device and the office network is created).

wlan0 (added USB wifi card #1) - This will be a wifi client connection that may be used to connect to a remote wireless access point

wlan1 (added USB wifi card #2)- Available as a wireless bridged port using hostapd (SID pivpn, WPA key Passw0rd, It will act as a wifi access point for any devices that has a wireless client. When you connect with any wireless device to this AP, you will get bridged to the SE VPN server and have a virtual network cable between your device and the office network)

The basic system is this:
eth0 and wlan0 is connecting and using the remote network, respectively by cable or wireless.

eth1 and wlan1 is bridging through either of the connections eth0 or wlan0 to provide access to your office network for any client that connects through those interfaces.

First to the two cabled interfaces eth0 and wlan0. For the moment we will just leave them as is.
They both got a DHCP setting by default, so they should recieve a dhcp IP address for whatever they connect to.
It may seem a bit strange but we don't have to setup DHCPD or a static IP address for any of them. The reason is that we will let eth0 just get what ever IP address that remote network provides.
When it gets an IP address, eth0 then will connect to the VPN server. When connected through the remote internet using the https port (443) to your VPN server it will assign both eth1 and wlan1 as the interface to provide the bridge.
For wlan0 we will need to manually connect to a remote wireless AP,. We will really need to do that on site, if we don't have the wlan info beforehand. 
So conclusion; these two ports will provide any host connecting with them with the network settings from the VPN server and they should connect with DHCP wich is the default network setting in RPi.

So first we connect one WiFI USB card to the RPi to make sure it gets the interface name wlan0.

Do a reboot
(sudo reboot)

If you want you are now able to connect to a wireless access point using 
the gui application 
logon with your user to your RPi
startx (if it is not in gui mode)
in the gui scan and connect to a wireless AP

Now, check the file /etc/wpa_supplicant/wpa_supplicant.conf

sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

It should contain something like this:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev


So at this time we have eth0 and wlan 0 configured

For eth1 we do not have to do anything but connect it and reboot... Yes really, don't even ask. It will not need an IP address ever.

After a reboot and the command ifconfig, you should see something like this:

pi@raspberrypi ~ $ ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:da:87:2e
          inet addr:  Bcast:  Mask:
          RX packets:350 errors:0 dropped:1 overruns:0 frame:0
          TX packets:146 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:31363 (30.6 KiB)  TX bytes:16842 (16.4 KiB)

eth1      Link encap:Ethernet  HWaddr 00:50:b6:12:84:d5
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:  Mask:
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:160 errors:0 dropped:0 overruns:0 frame:0
          TX packets:160 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:13592 (13.2 KiB)  TX bytes:13592 (13.2 KiB)

wlan0     Link encap:Ethernet  HWaddr 34:21:09:1a:f2:95
          inet addr:  Bcast:  Mask:
          RX packets:336 errors:0 dropped:126 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:44012 (42.9 KiB)  TX bytes:4334 (4.2 KiB)

pi@raspberrypi ~ $

So three of four is done :-)

So now to the last interface wlan1 which will be our wireless access point.
In principle this acts as the eth1 USB card. As long as the client is able to connect AND the internet connection is OK on either eth0 or wlan1 it will connect without any DHCPd setup.
What we need is to be able to connect a client. 
Do do that we will need to install the hostapd daemon, and the good thing is that the script has already done that, and the service is already started.
We will need to connect the USB wifi card and configure it, that is all :-)
Remember to run sudo reboot when you connect the new USB card wait until the reboot is finished

This may be the point where the RPi start to get a bit confused, you may notice that both wlan0 and wlan1 gets an address from the dhcp server - they both are clients to the same wireless access point now.

We need to make sure they get seperated by their device names.

The configuration file for hostapd is found here:

sudo nano /etc/hostapd/hostapd.conf

Paste something like this in to the file (dependent of the driver of wlan1):


There is a little thing with the hostapd service. Even if it is installed, it does lack a link to the config file so the daemon does not start.

So we will need to edit one more file to make the hostapd read  and run our config file:

sudo vi /etc/default/hostapd

add or edit the line to:


Now reboot

With some luck all should work now. While rebooting check the console output:

If the piVPN network is not appearing in the available wireless access point list on another PC in a few minutes, please check the command

sudo iw list

and see if the usb wifi card is recognised.

The final part; getting this all together.

Now you should have a fairly long list of devices if you run the command ifconfig:

On my PC:

pi@raspberrypi ~ $ ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:da:87:2e
          inet addr:  Bcast:  Mask:
          RX packets:1015 errors:0 dropped:2 overruns:0 frame:0
          TX packets:354 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:95467 (93.2 KiB)  TX bytes:35540 (34.7 KiB)

eth1      Link encap:Ethernet  HWaddr 00:50:b6:12:84:d5
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:  Mask:
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:152 errors:0 dropped:0 overruns:0 frame:0
          TX packets:152 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:12928 (12.6 KiB)  TX bytes:12928 (12.6 KiB)

mon.wlan1 Link encap:UNSPEC  HWaddr 34-21-09-1A-F2-83-00-00-00-00-00-00-00-00-00-00
          RX packets:94 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:10737 (10.4 KiB)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 34:21:09:1a:f2:95
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:199 errors:0 dropped:89 overruns:0 frame:0
          TX packets:19 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:24550 (23.9 KiB)  TX bytes:3896 (3.8 KiB)

wlan1     Link encap:Ethernet  HWaddr 34:21:09:1a:f2:83
          RX packets:8 errors:0 dropped:3 overruns:0 frame:0
          TX packets:494 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1157 (1.1 KiB)  TX bytes:203133 (198.3 KiB)

pi@raspberrypi ~ $

Time to configure the bridge VPN part.

Start the SE server manager and go to the eth0 ipaddress.

Set a password

Go with the default

Choose step 2

 Enter the info from the earlier VPN server setup at home, 
enter vpnazure.net or softether.net DNS name, username and password

Make sure it connects

Step 3 Set local bridge
Do this twice for eth1 and wlan0

Done and reboot :-)

Now for the final setting change the wireless client card settings (sudo nano /etc/wpa_supplicant/wpa_supplicant.conf) to something that makes sense when you are offisite.
This can be your phones 4g setting when you tether it.

søndag 19. juli 2015

Making a generic Windows 10 Pro wim image for remote installations

One of the general big issues with deploying unattended installations with imaging is that MS wants you to create one image per PC model to make sure that the drivers are added OK.

In principle this means that you will need to create one golden image per machine model; add that image to your server, and then deploy the different images to the specific PC models that your company have.

This is a very time consuming job, and therefore I would normally do this deployment in a totally different way; using one central "brass image" with the possibility to apply any driver needed by any of the PC's.

Before you laugh about this attitude, note that I have used this method for a windows 7 rollout for 350 PC's, so it does work.
In this company it was a mixture of Dells (workstations and laptops), HP (workstations and laptops) and Acer (laptops). None of them was on a domain.
In the end we figured out that it was at least forty different models, and brand new unknown models popped up on every site. Just collecting drivers revealed a staggering 14 GB of drivers in total.

The way I got it to work was to make sure that I added any new drivers for a any newly found PC model to the original wim image (I will show how later), and figured out a way to apply the drivers to the central image, deploy the image to the PC and apply the drivers to the to the different models unattended..
After that it was just renaming by naming convention and then add to domain :-)

It did really work, and it is easier than you think :-)

For the moment there is still some kind of lack of windows 10 drivers and one attitude to solve thsi can be to add new drivers to the golden image as they becomes available. This can call for the method above.

Bugs in windows 10 unattended deployment

First of all there are two major bugs with making unattended installations with the latest preview of Windows 10
1) When you do the first installation on the technician PC (the source PC), turn off the "Apps Updates" at once. If not, you will not be able to to sysprep the machine, as it will try to update the apps on your profile automatically. As this is done for one user only, sysprep will not allow you to run a general sysprep. The "fix" is to delete the profile with another user.. or start over again. I really hope they stop doing these automatic updates of apps. At least they should give an option to turn it off during OOBE. The first thing you should do then, is to turn off Apps Update in  the Store App at once after first login.
2) You can not reuse the username you used on the machine you sysprepped. If you used the login name "admin" on the tech-computer (source computer) you will not be able to to use that username in your unattend.xml file. Fix is to use a username that you will never normally use, a swearing word works fine :-)

Create a "golden image" (or brass image in this case)

First install windows 10 on one computer, in any way you like (netboot, DVD, USB).
I used an old HP Elitebook 6930p for this and Serva32 for a PXE installation from  a preview iso.
On my Elitebook most of the HP specific drivers where missing after the installation, and I did not care much about finding them either.
What I want is that the image I get from this HP will do an unattended installation with all drivers for a much more usable Dell latitude E5540.

Make sure that you stop the "app update" by starting the windows store app, clicking on the "head icon" (I guess that means profile) on the top row and choose to disable updates.
Now install any application you want, I installed 7zip, putty, VLC and some other free stuff that I always need.
Make sure that you do all windows updates etc. too
Reboot the machine once in a while to make sure all settings and updates are applied.

Now to the interesting part -- how to get the dell drivers (or any other drivers) in to the image, without it a PC crash during setup.

1) First I put a file named setupcomplete.cmd in c:\windows\setup\scripts. What this file does is to call up a batch file in c:\temp that using a MS driver tool to check and add for drivers under the folder c:\temp\X64. The power config thing is to make sure the PC don't go to sleep if there is a lot of drivers to be scanned and installed. It is commented out for now, as I am not sure it works in Windows 10. SetupComplete runs automatically after setup, but before login.

2) Download the windows 10 drivers you need for your computers and put them in any subfolder(s) under c:\temp\X64. Since my Dell E5540 does not have any official windows 10 drivers from Dell yet I extracted the E5540-Win8 cab driver package and hoped the Windows 8 drivers might be kind of supporting the windows 10 drivers too ....

3) add these files to c:\temp

Now finish sysprep as normal by starting it from C:\windows\system32\sysprep

After shutdown, boot the PC on a winPE USB stick and run imagex.

My winPE is a bit special, so I am able to transfer my new install.wim directly to my Serva64 (the machine I do PXE against) machine, but without such luxury you can just transfer it a USB drive or something, it doesn't matter.

Now I add a new entry in Serva64 with this unattend.xml file. NB the production key is for a windows 10 preview
Notice that I have enabled the administrator account in this one. At least I can run commands without UAC errors (OK the real reason is number 2) in bugs over here)

So.. Just to connect the Dell to the network, press F12, do an unattended installation with the new image and see if it get it drivers.....

And yes... after 20 minutes, it automatically logs on as administrator with all its drivers already installed :-)
Since there is no feedback during the installation the easiest way of seeing that it works, is that it have a Dell touchpad driver installed. This driver is not to be found in the MS driver repository :-)
A good thing here is that all the drivers you add to c:\temp\x64 only takes space, but will not be added to the driver repository in windows if not the device ID is correct.
Of course the install will take longer time for each driver you add, as the system will need to scan through all drivers, but since most mass deployments are happening at nights and are unattended, it really does not matter if the installation takes 20 minutes or one hour.
Also note the Windows sometimes have device ID issues with mouses and storage devices, so it can be good to remove some of those drivers from c:\temp\X64 and add them later (I would never do that as my users is normally not using gestures on their touchpad or similar)


Of course, I don't think this is the ultimate drivers for my Dell, but this is the drivers that was available now. I hope Dell can put out some supported windows 10 drivers soon (and all the other companies too) :-)

A working Windows 10 Pro unattend.xml file

Only a few days to go until the new Windows 10 release, and finally time to get the latest preview (10240) to work with automatic installation methods.
In the earliest previews these methods had some issues, but the latest one is so close to RTM as it can be, so time to test :-)
I had some issues finding a working file for unattended windows 10 installations, so I figured I had to write one myself. Please note that this one is edited manually, so please check and double check before using...
Also note that keyboard and regional settings is set up to Norwegian.

Can be downloaded from here

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="oobeSystem">
<component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<TimeZone>W. Europe Standard Time</TimeZone>
<LocalAccount wcm:action="add">
<Description>Local Admin</Description>
<DisplayName>Local Admin</DisplayName>
<settings pass="specialize">
<component name="Microsoft-Windows-Security-SPP-UX" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<RegisteredOwner>End User</RegisteredOwner>
<settings pass="windowsPE">
<component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<component name="Microsoft-Windows-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Disk wcm:action="add">
<CreatePartition wcm:action="add">
<CreatePartition wcm:action="add">
<ModifyPartition wcm:action="add">
<Label>System Reserved</Label>
<ModifyPartition wcm:action="add">
<MetaData wcm:action="add">
<Value>Windows 10 Pro</Value>

lørdag 18. juli 2015

Installing Windows 10 IoT on RPi using windows 7/8

Annoyingly MS has decided that you need to have windows 10 preview installed on a PC to be able to transfer their "InternetOfThings" image in their proprietary ffu format to a Raspberry Pi.

First of all, it really is a unnecessary approach from a technical point of view.
What you need is a just updated DISM to handle the image (or they could have released it in another format in the first place)

For all us techs that have been around using Microsoft's imaging tools for a while, this is not a surprise, as they have changed a lot on their imaging tools on every release (including switches .. aaarghhh).

What you really just need to do is to create a folder with the new windows 10 DISM.exe and it's needed dll files, and run the needed command from that folder.

First, we will need some files from the windows 10 DVD (which is not available for the moment, as MS will realease that in the end of this month, of course :-( )

these are:


The total size of these files uncompressed is about 4 Mb, which with convenience could have been included in the msi file they provide in their setup file (most of them actually is included but with a bit cluttered names to ensure that you will not be able to run them from a older version of windows )

In addition you will need the flash.ffu image which is to be found in their IoT Core RPi.iso file approx 1,2 Gb.

You can collect all the files including the latest preview flash.ffu image from here: (400 mb)
Without flash.ffu here (3mb)

So what you do is the following:
Insert a SD card in your PC (16 gb should be OK)
Format it with SD formatter:
unpack the downloaded files (iot.7zip) to c:\iot

start a command prompt as administrator
Type the following commands:
list disk
you should now get a list of the disks on your pc:

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          238 GB      0 B
  Disk 1    Online           14 GB  7721 MB

Note the disk number of the SD card (in this case disk 1)


Then type :
cd c:\iot
 # to go to the folder containing the files
./dism.exe /Apply-Image /ImageFile:c:\iot\flash.ffu /ApplyDrive:\\.\PhysicalDriveN /SkipPlatformCheck

Where the N in PhysicalDriveN is the drive number from the previous step ( In my case 1).
Notice the ./ in front of the dism command, this is to ensure that it runs the dism.exe in the current folder.

The image will be transferred to the SD card

Insert the SD card into your RPi and wait a while (this will take several minutes)

If you have a monitor connected to the RPi, it will eventually show the IP address of your device.

Open putty and do a SSH against the RPi IP address (strangly this takes some time to, it could be a reverse DNS issue on my system).

Log in with:

Username: administrator
Password: p@ssw0rd

tirsdag 14. juli 2015

How to deploy a windows image with PXE over internet using bridged VPN

So this is the scenario:
You have a PC in a remote home office that you will need to reinstall with your enterprise windows image.
At the HQ office you normally just deploy the image using a windows WDS server or similar.
This means that you boot a new PC on the network (pressing F12) and then using WDS with a network broadcasted PXE package and a unattended.xml file, you apply the image and domain settings for a windows machine.

So what we want to do here is to extend your HQ office network settings so that the remote user  is able to do the WDS installation at his remote home office network over internet.
This is not possible to do with a "normal" routed point to point VPN. The installation method we have choosen is based on broadcasted network packages which is not routable.

This is where a bridged VPN is working perfectly. Seen from the network perspective, the remote home office and the HQ office is then at the "same" network, so all network broadcasts are forwarded over the VPN connection. We got a virtual layer two ethernet cable between the sites
This means
(1) when the remote machine is requesting a DHCP address, it gets it from the office DHCP server
(2) the WDS server broadcasted PXE and BINL packages will be received in the home office as well, so that the windows image installation will be able to run..

What is needed:

In the HQ office: 
DHCP server
Softher VPN server (or a piVPN in VPN server mode)
Some kind of PXE service able to deploy the windows image (I will use Serva 64 for this)
A fairly good internet connection

At the home office (where the image will be deployed) :
A piVPN  machine, or any other machine running softether VPN, in bridged mode.
The machine to be installed is connected to the same switch\router  as the piVPN machine.
A fairly good internet connection (approx 10 mbit should be OK).

The image of the scenario is then like this:

Now, there is one problem with the remote home office setup.
It have a router ( which probably already got a DHCP server and we may not be able turn that service off or modify it.
What we will have to do to make sure that the remote laptop is only seeing the office network. We will need to have two network cards on the piVPN running in bridged mode at the remote site.
Any supported USB ethernet card will do, in addition to the built in ethernet card on the raspberry pi.
The first network card (the built in eth0) is then connected to the remote router and the other network card (USB eth1) is connected to the laptop to be reinstalled. Both cards can just run as DHCP clients (as they will do by default, so no modifications of the network settings are needed, and either is any knowledge of the remote infrastructure)

Another clever way can be to connect a wireless card to the piVPN and connect that to a wireless access point at the remote site and then connect the PC to be reinstalled to the ethernet port. This opens up for installations over mobile access points (wifi and USB tethering) and guestWiFi's on hotels :-) Of course you can also put a switch in the USB ethernet port and connect several PC's to it for multiple PC deployments.

Experiment time in the mini lab:

First I will setup two separate networks with two different routers.

Network 1 (e.g the main HQ office network) is a network with IP range /24
accessing 75 Mbits/s internet with a ASUS  RT-AC66U (ip address: which is also a DHCP server for this range)
Also I connect a lenovo think pad hosting Serva64 (a cheap WDS clone) which is able to do a unattended deploy of an install image of Windows 7 Enterprise.
Also it got a tiny pre setupAcer Ubuntu SoftEther VPN server (192,168.50.2) which is nat'ed through the Asus router on port 443. Of course you could have used a piVPN, a Softether VPN server running on windows or whatever you want. The best reason to run on port 443 is that this port is close to always available on remote networks with internet access.

Network 2 (e.g the remote home office network) is a network with IP range /24 accessing a 4g (approx 30 Mbits/s) internet using a D-Link DIR 615 (with dd-wrt set in client mode towards a 4g phone with wifi tethering). All incoming ports are closed.
A very old HP laptop (to be reinstalled)
My piVPN box with an additional USB ethernet card (asix of some kind)

piVPN setup

First I have modified the pivpninstall.sh script for VPN bridging instead of VPN server.
I have also commented out the original X application removal, added xrdp (to be able to log in using X and connect to a wireless network using gui)
The script can be found here.
On a freshly installed Raspian you can just install and run the script using:

wget http://home.pivpn.net/pivpnbridgeinstall.sh
chmod 777 pivpnbridgeinstall.sh

When the script has finished the RPi will reboot and the VPN in bridgemode will be enabled.

You will see the IP address of the ethernet card (eth0) on the Raspberry which is connected to the remote router, in this case it gets by DHCP from the remote router. Eth1 (the USB NIC) is not connected yet.

I connect a windows PC  to a port on the remote router to be able to configure the VPN bridge using the SoftEther Server Manager (it gets from the DHCP on the remote router):

Choose "New Setting", and the IP address of the raspberry PI (eth0, as the host name you will connect to.

Click connect

Choose a password

Click OK

Go with default, and click next

Press yes (or "Ja" if you are Norwegian :-))

Click "Step 2" "Configure Connection settings". the host name here will be the softether VPN server that you connect to at the HQ office. When you install the VPN server in HQ you will get the option to use a address in the cloud provided by SoftEther (vpnazure.net), or a dynamic DNS name (requires a NAT'ed open port on your router to the VPN server).
 I have set my own DNS address for the HQ VPN server, as I own a DNS server and a domain (test.pivpn.net). The user and password also have to be set at this VPN server prior to your connection from the bridge VPN (in my case the user is pi with password pi)

Connection is successful

For the local bridge I chose the network card that is not connected to the remote router (eth0), as I will connect my computer to the USB Ethernet card (eth1)

All done

I connect my windows PC to the USB card (eth1) on the raspberry, and now it gets an IP address from the "HQ office" router (

Make sure the serva64 is running on the network, and reboot the PC (in my case is the same machine as I have configured the VPN bridge with) connected to the raspberry USB card and remeber to press F12 for network boot :-)

It actually works :-)

Installation time is of course dependent on image size and internet connection speed.

Why use the SE VPN solution on a RaspberryPi

Most traditional VPN solutions do require expensive hardware and software. Also you will need to open specific ports on both ends, public IP's and a lot of configurations.
The Softether VPN has a different approach. It is able to connect to traditional hardware VPN's as Cisco, but it is also able to just use simple and effective SSL VPN between two PC's. This means that you will be able to set up a VPN connection between two offices using just any internet connection.

You don't need to use a raspberry for this, as the Softether VPN do run on most OS's and most VPN clients like smartphones can be set up to connect.
You can have a Windows machine on one site, Linux on another and both connecting to a Cisco at HQ. After that you can have a piVPN in bridge mode at home feeding you IP addresses from the office DHCP server.

What is SoftEther VPN

1.2.jpgSoftEther VPN ("SoftEther" means "Software Ethernet") is one of the world's most powerful and easy-to-use multi-protocol VPN software. It runs on Windows, Linux, Mac, FreeBSD and Solaris.
SoftEther VPN is open source. You can use SoftEther for any personal or commercial use for free charge.
SoftEther VPN is an optimum alternative to OpenVPN andMicrosoft's VPN servers. SoftEther VPN has a clone-function of OpenVPN Server. You can integrate from OpenVPN to SoftEther VPN smoothly. SoftEther VPN is faster than OpenVPN. SoftEther VPN also supports Microsoft SSTP VPN for Windows Vista / 7 / 8. No more need to pay expensive charges for Windows Server license for Remote-Access VPN function.
SoftEther VPN can be used to realize BYOD (Bring your own device) on your business. If you have smartphones, tablets or laptop PCs, SoftEther VPN's L2TP/IPsec server function will help you to establish a remote-access VPN from your local network. SoftEther VPN's L2TP VPN Server has strong compatible withWindowsMaciOS and Android.
1.0_vpnserver.jpgSoftEther VPN is not only an alternative VPN server to existing VPN products (OpenVPN, IPsec and MS-SSTP). SoftEther VPN has also original strong SSL-VPN protocol to penetrate any kinds of firewalls. Ultra-optimized SSL-VPN Protocol of SoftEther VPN has very fast throughput, low latency and firewall resistance.
SoftEther VPN has strong resistance against firewalls than ever.Built-in NAT-traversal penetrates your network admin's troublesome firewall for overprotection. You can setup your own VPN server behind the firewall or NAT in your company, and you can reach to that VPN server in the corporate private network from your home or mobile place, without any modification of firewall settings. Any deep-packet inspection firewalls cannot detect SoftEther VPN's transport packets as a VPN tunnel, because SoftEther VPN uses Ethernet over HTTPS for camouflage.
1.0_vpnclient2.jpgEasy to imagine, design and implement your VPN topology with SoftEther VPN. It virtualizes Ethernet by software-enumeration. SoftEther VPN Client implementsVirtual Network Adapter, and SoftEther VPN Server implements Virtual Ethernet Switch. You can easily build both Remote-Access VPN and Site-to-Site VPN, as expansion of Ethernet-based L2 VPN. Of course, traditional IP-routing L3 based VPN can be built by SoftEther VPN.
iphone.jpgSoftEther VPN has strong compatibility to today's most popular VPN products among the world. It has the interoperability with OpenVPN, L2TP, IPsec, EtherIP, L2TPv3, Cisco VPN Routers and MS-SSTP VPN Clients. SoftEther VPN is the world's only VPN software which supports SSL-VPN, OpenVPN, L2TP, EtherIP, L2TPv3 and IPsec, as a single VPN software.
SoftEther VPN is free software because it was developed as Daiyuu Nobori's Master Thesis research in the University. You candownload and use it from today. The source-code of SoftEther VPN is available under GPL license.
Features of SoftEther VPN

Architecture of SoftEther VPN

1.0.1.jpgVirtualization of Ethernet devices is the key of the SoftEther VPN architecture. SoftEther VPN virtualizes Ethernet devices in order to realize a flexible virtual private network for bothremote-access VPN and site-to-site VPN. SoftEther VPN implements the Virtual Network Adapter program as a software-emulated traditional Ethernet network adapter. SoftEther VPN implements the Virtual Ethernet Switch program (called Virtual Hub) as a software-emulated traditional Ethernet switch. SoftEther VPN implements VPN Session as a software-emulated Ethernet cable between the network adapter and the switch.
You can create one or many Virtual Hub with SoftEther VPN on your server computer. This server computer will become aVPN server, which accepts VPN connection requests from VPN client computers.
You can create one or many Virtual Network Adapter with SoftEther VPN on your client computer. This client computer will become a VPN client, which establishes a VPN connections to the Virtual Hub on the VPN server.
You can establish VPN sessions, as called 'VPN tunnels', between VPN clients and VPN servers. A VPN session is the virtualized network cable. A VPN session is realized over a TCP/IP connection. The signals through the VPN session is encrypted by SSL. Therefore, you can safely establish a VPN session beyond the Internet. A VPN session is established by SoftEther VPN's "VPN over HTTPS" technology. It means that SoftEther VPN can create a VPN connection beyond any kinds of firewalls and NATs.
1.0.2.jpgThe Virtual Hub exchanges all Ethernet packets from each connected VPN session to other connected sessions. The behavior is same to traditional Ethernet switches. The Virtual Hub has a FDB (forwarding database) to optimize the transmission of Ethernet frames.
You can define a local bridge between the Virtual Hub and the existing physical Ethernet segment by using the Local Bridge function. The Local Bridge exchanges packets between the physical Ethernet adapter and the Virtual Hub. You can realize a remote-access VPN from home or mobile to the company network by using the Local Bridge function.
You can define a cascading connection between two or more remote Virtual Hubs. With cascading, you can integrate two or more remote Ethernet segments to a single Ethernet segment. For example, after you establish cascading connections between the site A, B and C, then any computers in the site A will be able to communicate with the computers in the site B and the site C. This is a site-to-site VPN.
SoftEther VPN can also establish a VPN session over UDP. The UDP-mode of SoftEther VPN supports NAT traversal. The NAT traversal function allows the VPN server behind existing NATs or firewalls to accept incoming VPN sessions. You need no network administrator's special permission before setting up a VPN server on the company network behind firewalls or NATs. Additionally, SoftEther VPN Server may be placed on the dynamic IP address environment since SoftEther VPN has built-inDynamic DNS (DDNS) function.
SoftEther VPN Server supports additional VPN protocols, including L2TP/IPsecOpenVPNMicrosoft SSTPL2TPv3 andEtherIP. These realizes the interoperability with built-in L2TP/IPsec VPN clients on iPhone, iPad, Android, Windows and Mac OS X, and also with Cisco's VPN routers and other vendors VPN products.

OpenVPN vs. SoftEther VPN

Popular Question: What is the advantage of SoftEther VPN to OpenVPN?
Obviously, OpenVPN is an excellent tool. However, the development of OpenVPN has been stalled for many years. And as you know OpenVPN has no significant improvement in recent years.
The following table will show that the more benefit that SoftEther VPN can provied you. SoftEther VPN supports multi VPN protocols and multi native-VPN clients of various operating systems. SoftEther VPN has an easy-to-use VPN server management GUI tool. SoftEther VPN has also multi-language support. There are any other advantages in SoftEther VPN. Furthermore, SoftEther VPN has the OpenVPN-clone server function. It means that any OpenVPN users can replace it to SoftEther VPN seamlessly.
The SoftEther VPN Project believes that SoftEther VPN has the potential ability to occupy the even stronger position in today's OpenVPN.

How to Use SoftEther VPN ?

SoftEther VPN is an essential infrastructure to build-up IT systems on enterprises and small-businesses.

Ad-hoc VPN

Make an ad-hoc VPN consists of the small-number computers with SoftEther VPN. Despite long-distance, it is easy to communicate mutually with any kinds of LAN-oriented protocols.

LAN to LAN Bridge

Geologically distributed branches are isolated as networks by default. SoftEther VPN lays virtual Ethernet cables between your all branches. Then all computers of all branches are connected to the single LAN.

Remote Access to LAN

Does employees need to connect to the company LAN from outside or home? Remote Access VPN will realizes virtual network cable from a Client PC to the LAN from anywhere and anytime.