This will definitely be dependent on the VPN client you use.
At our site we use 2003 server with RRAS for VPN connections and I had similar issues that I resolved by making a custom VPN "connectoid" using the microsoft CMAK (connection manager administration kit)
I used this guide while creating the client http://www.isaserver.org/tutorials/work-around-VPN-clients-split-DNS.html
It helped me to get clients to connect, use DNS servers at the office for name resolution but also allows all internet destined traffic to use the local gateway properly.
Your issues, if they are like mine, have to do with 2 things.
VPN connections are low on the bind order for DNS in windows by default. This means that it will favor your local LAN DNS servers over your VPN connections servers unless you tell windows to favor your VPN connection over the others.
Dns resolution isn't working properly because no DNS suffix is specified for the VPN connection. Even if you are looking at the right DNS servers, if no search suffix is configured for that link the machine will fail to convert the name "server" to "server.domain.com" when performing a lookup. unless you reference everything using fqdn, which I have never seen in practice, this could be a show-stopper as well.
Hopefully the guide for the 2003 CMAK kit and this information will help you to get the nortel client working in your environment.
HOWEVER, another option for these networks is to use a gateway that can do IPsec with your main site so that users aren't required to connect using individual VPN connections while they are at any of your sites. PFsense is a great BSD based firewall/router distro that has done an amazing job for me in the past. I've used PFsense in production to pipe 150+ users over an IPsec connection with a cisco device on the other end and it didn't even bat an eye.
Get back with more information if you think I have mis-understood your issue!
You could try using OpenVPN instead of Hamachi.
With OpenVPN, you can:
tunnel any IP subnetwork or virtual ethernet adapter over a single UDP or TCP port,
configure a scalable, load-balanced VPN server farm using one or more machines which can handle thousands of dynamic connections from incoming VPN clients,
use all of the encryption, authentication, and certification features of the OpenSSL library to protect your private network traffic as it transits the internet,
use any cipher, key size, or HMAC digest (for datagram integrity checking) supported by the OpenSSL library,
choose between static-key based conventional encryption or certificate-based public key encryption,
use static, pre-shared keys or TLS-based dynamic key exchange,
use real-time adaptive link compression and traffic-shaping to manage link bandwidth utilization,
tunnel networks whose public endpoints are dynamic such as DHCP or dial-in clients,
tunnel networks through connection-oriented stateful firewalls without having to use explicit firewall rules,
tunnel networks over NAT,
create secure ethernet bridges using virtual tap devices, and
control OpenVPN using a GUI on Windows or Mac OS X.
Best Answer
This is kind of jankety, but you could setup openvpn on your desktop at work. You would then connect the original home->work VPN and connect OpenVPN through it. You would then push a route from the work desktop to the home system so it could then route traffic appropriately directly to the server in the DC.
In the openvpn config, the route could be pushed to the home system like so:
push "route 12.34.56.78 255.255.255.255"
12.34.56.78 being the IP of the server in the DC
Alternatively, you could run an SSHD via cygwin or something on the work system and use that to tunnel the RDP connection through.