I've done something very simple. Or so I thought…
I have setup VPN client access in TMG (or ISA, they're pretty alike). I created a group called VPN in AD, added that as allowed VPN users in TMG, setup a IP scope for VPN clients (192.168.6.0-192.168.6.255) and added network rules routing between VPN Clients and the Internal network on TMG (192.168.5.0-192.168.5.255). I also added an Allow all rule between VPN Clients and the Internal network in firewall policies.
To my problem: I connected to this network from a client running Windows 7 using PPTP connection (which is also set in TMG). I am able to login without errors, but when I try to contact any server on the Internal network, I get no response. So naturally I did a lot of troubleshooting (there was nothing showing up in the logs on TMG, no Denied Access anywhere) without success..
Later, I tried connecting the VPN using my mobile phone, and used a RDP client on my phone to contact a server on the Internal network. That worked!
I tried another Windows 7 workstation at another physical location, and using that I could not even login to the VPN.
Yet another workstation at another physical location, and I can login AND access the Internal network.
What could be causing these discrepancies? Why would it work from some places, but not from others, and with different errors?
Thanks in advance!
Best Answer
You may be having multiple problems here. One likely stems from the GRE traffic actually getting to the VPN server, and the other is probably an IP routing problem.
Problems with PPTP typically result from NAT devices or firewalls handling the GRE packets that contain the encapsulated PPP traffic.
Typically I sniff traffic at the VPN server and the client when I'm troubleshooting PPTP problems. That way I can observe that the GRE traffic really is flowing between the client and the server. Your issue with the machine that "could not even login to the VPN" is likely a problem with GRE forwarding or NAT of the GRE packets.
The issue with a "connected" client not being able to access network resources is typically a routing problem. Have a look at the "connected" client's routing table and see how packets bound for the remote LAN are going to be routed. Typically this isn't an issue if the default "Use default gateway on remote network" option is ticked in the client's "Advanced" TCP/IP properties, but if you've disabled that then you may need to explicitly add a route after the client connects to get the traffic routed to the remote LAN instead of the Internet. (Versions of Windows prior to Windows 7 add a "classful" route to the remote network when the "Use default gateway on remote network" option is unticked. Windows 7 is the first version of Windows that permits you to turn off that behavior, too.)