This post will describe how to dig into a Windows system and check to see USB devices that have been connected to a computer locally. This can be interesting, for example, if you are interested in monitoring what kind of devices are being connected and identifying potentially dangerous devices that are being attached to a system.
The manual way of checking to see these devices is to navigate through the registry keys and check the devices through RegEdit. The path to the USB device key is:
Just expand the tab to see which devices are listed here.
Then drill down into a particular device in this subtree to get information about the USB device. There should be a field named FriendlyName that you can check.
The other (quicker) way to get this information is to use Powershell. Use the following command to quickly enumerate these devices.
This post will go over the basics in getting basic VoIP inbound and outbound calling to work using Google Voice as a SIP trunk in your home or lab environment. I believe this solution will work with domestic calling (I live in the United States) so I’m not sure about international calling, from what I’ve read it doesn’t sound like this solution will work out of the box. Since I just got this working myself so there is much to be learned as I have no prior background experience in the world of voice. But I do have to say though, I’m super excited to get this working, how cool is it to say that you have your own free phone commercial grade phone system working at home! Ok, maybe its just the nerd in me talking.
The first step is head over to Google and create an account to associate this phone number with. From what I’ve read it is good practice to separate this account from your main, day to day account to avoid unsolicited messages and spam to your main account. By no means is it absolutely necessary, but it is the way I chose to do things so that is how this the direction this tutorial will follow. Once the account has been created and you log in the first time you will need to associate a Google Voice number with the new account. After that is done you will need to adjust your Voice settings in your new account. Make sure your phone allows Google Chat, otherwise inbound calling won’t work.
Also make sure your Calls settings look similar if not the same as the following:
Ok, now we need to adjust the settings on our voice server. I will not be going over the details of getting your voice server up in running in this tutorial so if you need help getting to this point let me know and I will write something up to help. Suffice it to say, there isn’t much difficulty getting to this point, just install the ISO image and configure the networking, accounts and passwords and you will be ready. I used PBX in a Flash for my setup (box.net 64-bit version), so grab the latest ISO and get started on the install!
Once you have completed the installation and configuration go ahead and open up a browser and head to the address you configured when setting your environment up. If you can’t remember, run a status command from the PBXiaF command line to check the address as well as other important information.
You need to ensure that you have the Google Voice module installed by first checking to verify that it is installed and enabled (Admin -> Module Admin -> Third Party Addon -> Google Voice).
Then go take a look at the configuration page (Main Page -> Third Party Addon -> Google Voice). Here we need to configure our settings to match the new account we just created with Google. Make sure your settings look similar to the following:
Phone Number: The 10-digit Google Voice phone number we created.
Username: The uername we created through Google. Only use the first part witouth the @gmail.com.
Password: The matching username password for your Google account.
Add Trunk: Checked
Add Routes: Checked
Agree to TOS: Checked
Next, we need to create an extension to route incoming/outgoing traffic to. I chose 701 for mine (kinda borrowed it from another tutorial). These settings can be found by going to Basic -> Extensions and choosing “Add Extensions” on the top right of the page. There are tons of options to configure here but I am focused on basic functionality I picked a display name of 701 and a secret for that extension. These settings are what your phone uses to talk to the server.
After that is done, add in inbound route (Inbound Call Control -> Inbound Routes) and configure it to use your Google Voice phone number and point it to the extension you just created. The settings should look similar to the following:
Now we need to install and configure a phone to test out our new VoIP connection. Since I don’t have a hard phone to test with I decided to sample a few different Linux options, finally settling on Qutecom. It is relatively painless to install and configure and looks the best out of all the options I tried IMO. To install, sudo apt-get install qutecom from command line. Once it is installed open up the program and adjust the soft phone setting to point to your voice server, the secret you created and your newly created extension.
It is finally time to test! At this point, I had outbound calls working through my SIP phone but incoming calls weren’t working. hmm, ok after some research I found that there was a patch for the Google Voice Addon that I needed. From the command line on your voice server issue the update-programs and update-fixes commands to update your programs and software fixes, pretty self explanatory but was pretty much impossible to find.
In my case this step was VERY IMPORTANT and was what allowed me to receive incoming calls. Make sure you don’t overlook this step if your are having problems receiving calls. There are still a ton of things to work on with this setup but I was just excited I got it to work to begin with. I hope you get som use out of this tutorial and try it for yourself.
As my home lab continues to grow and becomes increasingly complicated I need an easy way to access my servers and network resources by their name rather than their addresses on the network. By using DNS I can quickly and efficiently access these network resources by their given host names, not having to worry about the growing complexity of the network. I looked into a few different options for accomplishing this task but ultimately decided to go with the tried and true Linux BIND implementation. The installation and configuration isn’t all that complicated to get up and running, so in this post I will go through some of the high points of my experience in standing up this service. Let’s get going.
First, we need to install the proper packages. By the way I was using a Debain 6.0 minimal VM for my server in this project. So to install this stuff you need to update your repos to look for the packages.
apt-get update
Then the necessary packages
apt-get install bind9 dnsutils resolvconf
We need to configure the correct files to make our DNS function properly. Everything that we need to configure (for Debian distros) should be located in /etc/bind. So the first thing to change is the named.conf.local file to create the zones for our local network. We need a zone for resolving names to IP addresses as well as a zone reverse DNS. If you don’t know what that is, you can find more here. In my configuration psa.local is my local domain so any hostname will resolve to hostname.psa.local in DNS. Here is what my named.conf.local configuration file looks like:
Next, we need to set up our zones to point to the correct hosts. The easiest way is to use the db.local as a template and copy it to a new file. cp /etc/bind/db.local /etc/bind/db.psa.local Here is what my db.psa.local file looks like:
We need to do the same thing with our reverse records. For me, his file is located in db.192 and we will use db.127 as the template for this file. cp /etc/bind/db.127 /etc/bind/db.192. If you are using a different type of network layout adjust accordingly. For example if your network is a 172.x.x.x network just name the file as db.172 or whatever the network is. Here is what the configuration looks like, it is similar to our forward lookup zone.
Now we should be able to resolve host names (both forward and reverse) to the entries we’ve added to these configuration files. Next we need to edit our resolv.conf file to get our host name resolution to work smoothly. So edit /etc/resolv.conf with your favorite text editor and make the necessary changes. Here is what mine looks like after the necesary tweaks. NOTE I haven’t figured out why yet, but every time you restart your bind service it wipes this config out, I will update this when I figure out how to make these changes persistent.
Finally, and most importantly, here is my final named.conf.options file, with all the troubleshooting done. This file tells bind where to forward DNS queries externally as well as other important configuration options. You can adjust the forwarders to whichever public DNS server you choose. I chose two well known DNS servers. There are a few things to note here. If you are having issues with anything check the log files 🙂 At first I had strange resolution errors for anything that was external to my domain. The logs helped me pinpoint where the problems were and to make the necessary changes. The most important iformation for troubleshooting is located in /var/log/syslog.
The last few entires in this file are very important for getting external DNS to resolve and is not part of the default configuration file. You will have to add these in yourself.
Start/restart your DNS service for these configuration files to get loaded in. /etc/init.d/bind9 restart and you should be able to ping your newly added entries by host name.
That’s it. You can test these settings for yourself, host -l psa.local will list the hosts in your zone file. I should also note, machines that were already on the network will need to have their DNS configurations adjusted to point to the new DNS server by editing the /etc/resolv.conf file like we did on the server itself. Piece of cake. With local DNS in place it makes things much easier for me to remember, just don’t forget to add new network devices to your zone files when bringing them onto your network.
UPDATE: I think it is important that I inform readers that this guide is strictly for setting up and using L2TP. It has come to my attention that many of you are are looking for a L2TP/IPSec solution, which is currently not supported in PFSense as of the version I am using (2.0.1). I will update this post with full L2TP/IPSec instructions once this functionality has been added in new versions of PFSense.
I’ve been toying around with setting up a home VPN for about a week or so now, which has progressively improved. At first, I had a working VPN implementation with PPTP and life was good. But apparently PPTP is known to be less secure than other methods. So that got me thinking about beefing up my security. Here’s a quick summary I found.
PPTP has been the subject of many security analyses and serious security vulnerabilities have been found in the protocol. The known vulnerabilities relate to the underlying PPP authentication protocols used, the design of the MPPE protocol as well as the integration between MPPE and PPP authentication for session key establishment.
After discovering this information I decided to poke around for a little bit to decide what would work the best for me. There were pretty much two options when it came down to setting up my VPN server the way I wanted it. L2TP and OpenVPN. They are both considered secure and from what I’ve read OpenVPN is considered slightly better. The reason I chose L2TP is becuase it is built in to the VPN client on pretty much every OS these days, making client set up and configuration fairly quick and painless (I’m sure its not difficult to set up and use OpenVPN either but I didn’t get that far, maybe I will experiment with it in the future).
There isn’t really all that much to getting things up and going. Open up the pfSense management interface and navigate to the L2TP VPN settings. VPN -> L2TP
Next, we have to configure our settings.
Server address – Use an ip address that doesn’t fall into the subnet that the VPN clients connect to. I used my external IP address to make things easier.
Remote address range – This will be the subnet that VPN clients connect to. I am using the 192.168.2.0/24 subnet.
Subnet mask – I am using the entire subnet so I chose /24.
Number of L2TP users – pretty self explanatory, I have 10 right now for testing purposes.
>I left everything else as the default initially. Here is what the configuration page looked like for me when I got everything working. Remember to change these values accordingly.
Next we need to throw up some user accounts.
So far so good. Now we need to set up some traffic rules for our L2TP clients that connect. This is the absolute most basic method you can go with, so if you have restraints here you will need to adjust these settings.
<
The last and most important piece to get this working is setting up the firewall rules for the WAN interface. I got stuck at this part and didn’t realize there were two sets of ports that I needed to allow through for things to work correctly. Port 500 for Internet Key Exchange (IKE) UDP traffic and port 1701 for L2TP UDP traffic. Here’s what the rules look like.
That should be it. Try connecting to your VPN server with an endpoint client. I was testing this with my Android phone and had no problems after creating the two firewall rules. Happy VPNing!
I am in the middle of a home project to build a virtual environment using Proxmox and running into Java issues. Since Proxmox uses java as a VNC console it is necessary to use the correct version (of Java) to access VM’s. By using the wrong version you can cause instability issues and thus bad things to happen.
This is not just a problem with Proxmox either, there are a few other programs and apps that behave poorly with this version of Java, notably for me, Minecraft. Apparently newer versions of Ubuntu have shipped with the OpenJDK version as their default version and in this post I will discuss how to use to the Sun Java 6 version.
Switch to the appropriate directory, in my case I used my home directory and either punch these commands in or copy/past them to get get Ubuntu to see the correct repos.
Once this script goes through and does its thing you should have access to the old sun-java6 repos. So to install the correct pieces for Proxmox use apt-get to install the appropriate packages.
Now you should have a much more stable experience using Proxmox and the console to take a look at your VM’s! I can’t take the credit for this but I can ease the burden for anybody that comes across this post.
