- Order a Hetzner Dedicated Root Server with no operating system, called a “Rescue Server”.
- Purchase an add-on IP address for the server and request a separate MAC address for it.
- Request a LARA Console session from Hetzner with a VMWare ESXi installer USB inserted in the server.
- Once LARA Console is start and you are connected, set up RAID on your hard drives if you are going to use it.
- Install ESXi to Hetzner root server, in ESXi Developer Tools enable SFTP or SSH.
- Transfer your pfSense installation image and other guest operating system images to the server datastore.
- Login to the ESXi host control panel using the vSphere Client or Web UI.
- On the Configuration tab of the ESXi host, go into the Networking settings.
- Create a new Standard Switch, name it “vSwitch1” by default with it’s network named “VM Network 2”.
(So now you should have a vSwitch0 on VM Network and vSwitch1 on VM Network 2.)
- Create a virtual machine named “Router” on the ESXi host with 1 Core, 1GB RAM, 8GB HDD, OS set to “Other”, and choose FreeBSD OS.
- Assign one of the Router virtual machine NICs to “VM Network” and the other to “VM Network 2”.
- Assign a CD/DVD Drive to the Router virtual machine and point it to the pfSense image transfered to the datastore.
- Power on the Router Virtual Machine and install pfSense with all the default settings.
(You will end up with one NIC acting as WAN using your Hetzner main IP and one NIC acting as LAN with no IP.)
- Create another virtual machine on the ESXi host with your desired main operating system and NIC on VM Network 2.
- Install your operating system to the “Main VM” and start it, you should have local network access but no internet access.
- Open the Main VM’s web browser and go to the pfSense UI url, which is http://192.168.1.1. by default.
- Login to pfSense with the default credenital “admin” and “pfSense”, start the pfSense setup wizard/walkthrough.
- When setting up LAN, choose the option to Spoof MAC Address and enter the MAC from the Add-on IP bought from Hetzner.
(Do NOT manually set Static IP, use MAC Address Spoofing and ONLY enter the MAc Address… learn from my mistakes.)
- Restart the Router VM – the Main VM should now have a local IP, an external IP, and internet access!
I rented a rescue/root server from Hetzner and was attempting to install VMWare ESXi to it via LARA Console. After Waiting 45+ minutes for the .iso to transfer and load via Drive Redirection, the ESXi image booted successfully and the install process started.
Then, as my luck would have it, an error occurred with a crazy purple screen I had never seen before:
So what was the solution? Ask Hetzner to put a ESXi image on usb for you to use. 😀
A while back I installed VMWare ESXi 6.5 on some Root Servers from Hetzner. The majority that I setup were Hetzner EX41S-SSD builds but I also did a Hetzner PX91-SSD build.
The first few EX41S-SSD servers took VMWare ESXi 6.5 fine without problem – the only thing I’d suggest is having Hetzner put a 6.5 image on usb for you to use since loading a remote image through LARA Console doesn’t work too well.
Then I did a PX91-SSD server and had to downgrade to 5.5 in order to solve a Datastore connection issue. The PX91-SSD servers are in a different datacenter than the EX41S-SSD servers that I was used to, so this really isn’t surprising.
The surprise came when I was setting up another EX41S-SSD server and I had to downgrade to 6.0 from the usual 6.5 because the NIC card in this EX41S-SSD wasn’t supported by 6.5 even though other EX41S-SSD servers run 6.5 just fine. I should note that I couldn’t get 6.0, or even 5.5, to work myself and was about to just install Windows and run VMWare Workstation when a Hetzner support specialist offered to get 6.0 working for me. I assume he used a custom ESXi 6.0 image that had the missing NIC drivers that the regular image was missing.
So.. in conclusion.. even though you may order two servers with the same name from Hetzner, you may not be getting two physically identical servers with the same hardware – especially with the EX server packages running residential grade hardware and Skylake/Haswell CPUs.
For Windows 7/8/8.1/10:
- Right-click on “My Computer” or “This PC”.
- Select “Properties”.
- Click “Advanced System Settings”.
- Click “Environment Variables”.
- Under the “System Variables” sub-section select the Variable Path and click “Edit”.
- Append “;C:\Python27” to the existing path, click “Ok”, and “Ok” again.
- Restart CMD Prompt for the new path setting to take effect.
I was having a problem recently with Remote Desktop connections not working, Remote Desktop would just exit without any error while trying to connect. I checked Event Viewer and saw this entry:
Faulting application name: mstsc.exe, version: 10.0.14393.447, time stamp: 0x5819bc5f
Faulting module name: vorbis.acm, version: 0.0.3.6, time stamp: 0x50a51541Exception code: 0xc0000005
So after searching for problems with RDP related to vorbis.acm I found this article discussing the same problem in Windows 8.1 x64.
It turns out that a recent install of FL Studio 12 introduced vorbis.acm to my system which is not compatible with mstsc.exe in 64-bit machines, which I found strange since the FL Studio 12 install from Image Line has both a 32-bit and 64-bit version.
So what was the fix to get Remote Desktop working again? Well, just rename the “vorbis.acm” file located in C:\Windows\System32 to “vorbis.acmBAK” and RDP will start working again! Sure, it’s a temporary work-around, but at least you can connect to remote machines!