The Short Version: If your VPN client fails to obtain an IP address via DHPC when connecting to a Windows 7 VPN server using PPTP, it may be possible to connect to the server over RDP by accessing it at 169.254.128.230 if your client is assigned an IP in the same network range.
Last night I was logged into my Windows 7 desktop system back home, which runs my home automation software and acts as a VPN server. I recently had to setup the VPN server again and was trying to troubleshoot the problem of VPN clients not receiving DNS server addresses from the server.
At one point I changed the server configuration from providing a specific range of IP addresses to instead provide IPs via DHCP. After making this change I could still connect to the VPN but my client received a 169.254.128.x address and I could no longer access the server over RDP at the previous address.
I was accustomed to thinking of the 169.254.x.x range as being a sign of a problem and not as a useable network range so I kept trying to access the original, internal network via various methods (trying to override my VPN client assigned IP, using a virtual machine with a shared network connection but on the original network). I even tried to RDP to 169.254.128.1 but it also failed.
Finally, at some point I realized that there was an entry for a default gateway in my VPN client settings. In my case it was pointing to 169.254.128.230. I’m not sure if this is always the case.
When I entered this address into the RDP client I was able to connect and then set the server back to distributing the specific range of IP addresses that were previously defined, instead of using DHCP.
I haven’t resolved the original problem but I was able to get back into the machine and restore the VPN setting.
The items above would then be enclosed within a SELECT tag.
For a list this short I would just code it by hand but when you start hitting lists of 25 or more options it quickly becomes time-consuming. I attempted to use a Find and Replace operation in Dreamweaver using RegEx but ran into a problem.
Eventually, I moved over to TextWrangler for Mac. I’m not a RegEx guru but after doing some reading I came up with a method that works well.
In TextWrangler I opened the file and then went to the Search menu option and clicked Find.
Here’s what I’m using:
Replace: <option value="\1">\1</option>
Also, and this is critical, I checked the option to use “Grep” under Matching. This enables the use of Regular Expressions.
The find pattern captures anything between the beginning and end of the line. In the replace section it takes whatever matches and then inserts it into the surrounding text (\1 instructs the software to insert the contents of the match).
Fortunately, the ASUS box also has wireless so I was able to shift all of the network services over to the wifi adapter. I had to re-establish the built-in VPN server, among other annoyances. Since the ethernet port was no longer usable I decided to disable it in Windows 7.
I noticed the service was no longer working and wouldn’t start. When I viewed mControl’s log I saw the following message every time I attempted to start it:
The Installation Code of the license file does not match with Code 2. Please contact your System Administrator.
mServer License Code=Hacked/Hacker, Ver=.
My version isn’t hacked. I paid the commercial price (less because it was an upgrade from a previous version that I had also paid for). At first I thought that perhaps the license information was damaged but then I remembered that I had disabled the ethernet port and I noticed that there were some entries in the log during the activation check that hinted toward a check of the network device.
I re-enabled the built-in ethernet port. Sure enough, the software passed the activation check and started up. It seems to use a hardware identifier that’s part of the network card for activation.
I thought I had mentioned this tip in a previous post but since a quick search didn’t turn it up I figured I’d add this as its own entry. Not long after I started using virtual machines on a regular basis at work I encountered an IP conflict with a VM and another machine on the network.
The cause was simple. The last time I had used the VM I chose to suspend its state. It retained the IP and tried to use it the next time I started it up.
The solution is also simple. I’ve used this method with both VMWare Fusion and Parallels Desktop for Mac. Every time I prepare to suspend a virtual machine I simply disconnect the VM’s network connection prior to suspending. This will cause it to release the IP. The next time the state is restored and the network is reconnected it should pull a new IP.
It’s worth mentioning that this really only applies to VMs that have IP addresses assigned via DHCP.