I was asked to find out how to spare an engineer the trip to his customer abroad only to do a five minute's upload job to a device that was talking TCP/IP. The device was on a subnet that had a VPN site-to-site connection to his office, however, the device did not have a routing entry making it aware of the subnet on the other side of the VPN tunnel.
Because of limitations to the device, configuring the needed routing entry into the device was not an option, even if we were able to telnet into the device from a Remote Desktop session on a Windows computer on the same subnet.
Solution: The solution was to create a simple PPTP VPN dial-in access on that Windows computer, so that the engineer's computer could receive an IP from the same IP pool as the device he wanted to control. Yes, it meant creating a PPTP VPN tunnel back through the established site-to-site VPN tunnel, but it would work.
Caveat: Only trouble was, it didn't. Setting up a simple Routing and Remote Access server in Windows Server 2003 is a simple task, still, it just did not work. What I found after scratching my head pretty sore was that the firewall in the site-to-site VPN device on my side (the one responsible for the "outer" tunnel) was blocking all traffic that did not originate from my subnet. The PPTP GRE protocol packets from the remote site did not look like they were talking to established traffic from my side, and hence was blocked, effectively blocking the creation of the PPTP tunnel within the site-to-site tunnel. To make it work, I had to open the firewall on the site-to-site device to allow full traffic flow while running the PPTP tunnel.
After that it worked, but was quite slow, probably due to the double encrypted, double tunneled packets.