Summary #

This article walks you through some basic troubleshooting steps for the Home-To-School/Office VPN feature.  This article assumes that you are authenticated and connected to the VPN already (the icon in the System Tray has green “monitors” on it if you’re connected), and you’re having problems connecting to devices on the remote LAN.  If you’re not connected yet, or are having problems connecting, see Problems Connecting To The VPN.

More Information #

First, check that the VPN client got an IP address.  Depending on your configuration, you’ll have an IP address like 192.168.229.x, 172.29.229.x, or 10.229.229.x.  You find out your VPN address on Windows by going to a command prompt and typing “ipconfig”, or on a Mac by going to a terminal window and typing “ifconfig”.  You should see an interface listed there with an IP address in one of the three valid ranges.  For this example, we’ll assume you got an IP address of 192.168.229.5

Next, you need to test basic connectivity through the VPN to the SecureSchool appliance.  For this example, we’re going to use 192.168.100.253 as the LAN address of the appliance.  To ping the LAN address, at the command prompt, type “ping 192.168.100.253”.  You should get answers back.  If you didn’t, there could be a few things wrong:

• The school’s network could use the same subnet as the home network.  For example, if the home network were 192.168.100.x and the school network is 192.168.100.x, the home PC running the VPN client won’t know what traffic is for it’s local/home network, and what’s for the school network.  This commonly happens if the school has an ip range that includes 192.168.0.x or 192.168.1.x, since that is the most common default subnet on routers.  If there is a conflict, then one of the networks must change their IP subnet.  If the school/office subnet includes 192.168.0.x or 192.168.1.x, you may want to consider changing it because most of your home users will be using that range.
• If you the computer running the VPN client is running Windows Vista or Windows 7, then the client is probably not running as Administrator.  The instructions on how to do this are included in the instructions on how to setup the client.
• There could be a firewall running on your computer, preventing access through the VPN.  Turn off all firewalls, one by one, until you find the culprit, then change it to allow access.

Once you’ve proven connectivity through the VPN to the SecureSchool appliance, now test through to your server.  For this example, we’re going to use 192.168.100.1 as our server.  At the command prompt, type “ping 192.169.100.1”.  You should get answers back from your server.  If you didn’t:

• The server may have a firewall on it, and may be blocking pings from your VPN connection since that subnet is foreign to it.  Try disabling the firewall(s) on the server one at time until you find the one that’s blocking the connection.
• The server may not have a correct default gateway.  The default gateway needs to know how to get to the VPN subnet.  If the default gateway is SecureSchool (as it typically is on a flat network without internal routers), it will work fine.  If you have internal routers, they all need to eventually point to SecureSchool as the default gateway.  For example, if you have “Router B” connected to “Router A”, and “Router A” connected to SecureSchool, “Router B” needs to have it’s default gateway pointed to “Router A”, and “Router A” needs to have it’s default gateway pointed to “SecureSchool”.
• SecureSchool may have the “Deny By Default” rule turned on.  If this is the case, you need to create rules to allow your LAN subnet(s) to connect to the VPN subnet.
• SecureSchool may not have a static route for the subnet the server is on (if it’s on a different subnet then SecureSchool).  You can view your static routes on SecureSchool by going to “Setup” -> “Static Routes”.  If there is not a route there for the subnet you’re trying to get to, you’ll need to add it.  After you make this change (and commit and restart the services on SecureSchool), you’ll have to disconnect and reconnect to the VPN before you try again.

Now we’ve proven that the VPN client can ping the server by IP address.  The last step to prove that the VPN is working correctly is to ping the server by name.  For this example, we’re going to use “fileserver.network.internal” as the server we’re trying to connect to.  At the command prompt, type “ping fileserver.network.internal”.  You should get answers back from it (192.168.100.1).  If you didn’t:

• You may not have the “Domain Specific Name Servers” setup in SecureSchool.  This tells SecureSchool what DNS servers to talk to for which DNS domains.  To set these up, go to “Setup” -> “Domain Specific Name Servers”, and add entries for your domain(s), listing up to 4 DNS servers for each domain.  After you make this change (and commit and restart the services on SecureSchool), you’ll have to disconnect and reconnect to the VPN before you try again.

After you’ve verified that you can ping the target server by name, then you’ve validated that the VPN is fully functional.  At this point, if you’re having problems connecting to a particular service on the server or machine you’ve been testing to, then you need to check the settings of that service to see if it limits connections from certain IP addresses/subnets, or if it’s even running at all.