I've ran myself into a bit of a pickle

I've got a low spec'd web server on one side of the world ("cali1") with a single NIC running WS2003 with just the Windows Firewall. It is a domain controller, and the only domain controller of a domain I want this second server to join.
This second web server is pretty well spec'd ("manc1"). It has dual-NICs, two public Internet IP addresses, and runs Hyper-V under Window Server 2008. Presently it does nothing and is not a member of any domain. The single child Hyper-V partition likewise is standalone.
I want an arrangement such that the two servers can communicate with themselves, privately, 24/7; so that I can run DCPromo on manc1 so it joins cali1's domain. Clearly some kind of VPN is the solution.
This is where it gets complicated.
Am I after a Remote Access VPN, or a Site-to-Site VPN? Doing a RA VPN on cali1 requires lowering the Windows Firewall and thus opening the computer up to attacks (or at least, that's what the Wizard says). Doing an RA VPN on manc1 looks better (since I could put the RRAS service on a virtualised instance) but then with RA VPNs you'd need to instantiate it every time (and it might timeout and disconnect).
Site-to-Site sounds better, but it assumes you've got a private, inner network; then a perimeter network, and then a dedicated hardware firewall. And pretty much every guide or walkthrough I've seen so far for this strategy assumes the VPN server is dedicated to providing VPNs and doing not much else.
Is there a solution to this or should I cut my losses and create a new domain for manc1 to live in?