Category: networks

There were times when we were looking for simple yet unorthodox solutions; and this case was one of them. Imagine, if there was a Windows 2012 server with its standard VPN service (RAS, or, Remote Access, actually), configured and operational. The only problem was that static IP of the server (as seen by a connected user) was not up at all times. For instance, assume DHCP IP range for VPN clients was 172.0.2.1 – 172.0.2.199. That makes first address of the range, 172.0.2.1 the server’s address that is accessible by VPN clients (inside VPN tunnel). When server just started that IP would be down – not even pingable, let alone not routable. The IP address becomes live as soon as first VPN client is connected from outside to the RAS service. That presented a challenge for application jobs configured to run in both modes: locally on the server and from remote locations connected to the server. We would configure 172.0.2.1 as a universal connection point for all the applications and grant proper server firewall exclusions, though… they would not be able to connect if no external users connected to the VPN service yet.

Just a quick note as we have had a few reports lately that Shrewsoft VPN client package for Mac OS X (El Capitan release) was missing in main homebrew repository. That caused troubles for folks trying to use our recipe on that subject from last year.

Another showcase with Palo Alto PA-3020 firewall hardware device by Palo Alto Networks running PAN OS 6.0 (PA-3000 series). This time we would like to discuss a use of multiple IP addresses on the external interface. Say, you are running into a situation where more than one HTTPS web services should be offered to the public, but they are based on separate hardware resources internally. The simple solution would be to use another IP address for incoming connection on TCP port 443 and create another NAT policy rule for that additional address.

It is typical for a Windows server to have a auto-generated self-signed certificate for its Remote Desktop service. Not a good practice. Especially when RDP service is exposed on the internet (via TCP port 3389 that would be open in firewall). Here are a few simple steps to install a valid SSL certificate to be used with RDP to protect the host identity and encrypt your remote desktop sessions properly.

We were not able to alter MAC address of main network adapter inside a Windows 2012 R2 instance. No matter how we tried with registry hacks and even 3rd party software tools, the outcome was unsuccessful. Though for certain applications dependent on a particular MAC value it does not have to be on a primary network card. We realized we just needed another network card! That could be achieved by installing a dummy loopback network driver that would serve as an additional network interface. It can be assigned with a bogus IP while its physical (or MAC) address we may alter freely. Luckily, Microsoft offers such driver among most of its Windows distributions that is called KM-TEST Loopback Adapter.

When we got to upgrade our Macbook Pro to the all new Mac OS X 10.11, we surely liked its slick new style and interface improvements. And what not to like. The only drawback was that our Shrew Soft VPN client has fallen victim of the new ship commander.

A new edition of The Debian Administrator’s Handbook by Raphaël Hertzog, Roland Mas—the third one counting only English editions, and the seventh if the first four French-only are included—has been issued by Freexian. Shortly after the first English edition, communal experience with the book has justified the the in its title, the book becoming both the most widely read introduction into Debian and the most used single handbook, leaving out the documentation itself, of course.

Nice and short overview of vulnerabilities hiding inside SSL tunnels from BlueCoat:

Today our challenge was to create a simple setup that is often called inbound TCP port forwarding, or, a pinhole with a more (or less) advanced firewall device. The network appliance for this cosmetic surgery was one of the recent PAN (Palo Alto Networks) PA-3000 series running PAN OS 6.0. First of all, do not do it. Again, do not do it. And again: please, do not create a destination port forwarding from external network interface into an internal or trusted network behind the firewall. There are other (proper!) techniques that would be better to use for remote network access, dedicated line or VPN (stands for Virtual Private Networking), for instance. Modern VPNs have little overhead and lots of security benefits. Though, for testing purposes only, we have decided to ignore our own advice which was just mentioned above for 3 times.

Say, you have a stand-alone Windows 2008 R2 server that is not part of a domain. You decide that it would make more sense to adjust the server name in the system properties (Computer name – Change) from WinServ1 to a more meaningful WinDevelServ1. After mandatory server reboot you discover that (surprise!) Remote Desktop licensing is not active anymore. A brief error message on dashboard icon makes it clear that you have 120 days to activate the license or else users will lose their ability to connect via Remote Desktop.

What went wrong is one of the gotchas of Windows networking. Server name needs adjustments in various places of the system during name change and the Remote Desktop license server setting is apparently one that they forgot to take care of.