If I understand your question, you are trying to do this:
Server A - Router A - VPN - Router B - Site B
You need Site B to be able to access Server A (which is a public IP) over the VPN, but you need the source address to look like it is coming from Site A?
You'll need to specify traffic going to Server A to go over the VPN on Router B. On Router A, you'll need to specify the return traffic to go over the VPN. Next, on Router A, you'll need to configure the NAT rule, to change the SRC IP of the traffic coming from Site B and going to Server A to an IP address that Server A will accept.
I figured this out on my own.
In order to route based on the FQDN, one may need to run a DNS server on the client capable of detecting when a VPN is active on that FQDN's WAN address. When it detects an active VPN connection, it could resolve the FQDN to the VPN tunnel address instead, so that applications (web browsers, etc.) would receive the VPN tunnel address instead of the WAN address of the server. Since that would pose issues for SSL certificates that show which IP addresses are valid, one would really need a VPN-aware network driver capable of automatically and transparently tunneling data from applications over the VPN tunnel. It could be done, but I don't know if such intelligent network drivers exist. According to this response to a bad answer, you CAN ROUTE BASED ON FQDN with the appropriate configuration as I suspected:
As for the issue of duplicate Server IPv4 addresses being assigned to different VPN servers in a Windows 7 client, this appears to be by design. In Windows Server 2008/2012 Routing and Remote Access Services (RRAS), the server utilizes an IPv4 router which can be configured to use a static address pool like so. This static pool will determine the Server IPv4 address on the client. Here I've set my second server to use 192.168.2.0/24 as its subnet, so it will receive a server IP of 192.168.2.1 on the Windows 7 client.
My user account on each VPN server is assigned a static IP address in the Dial-In tab of the user properties under computer management. This will become the client's IPv4 address on the VPN.
Finally, to ensure that file sharing traffic must originate from the server's VPN subnet only, the appropriate protocols/ports in the firewall can have their remote IP restricted to to the assigned subnet:
Now, on the client, I can connect to file shares over the internet through this VPN which requires no 3rd party software at all. I simply map a network drive to each of the server's VPN addresses (e.g. \\192.168.1.1\sharedfolder and \\192.168.2.1\sharedfolder\).
Unfortunately, we cannot use the FQDN such as \\my.server.com\sharedfolder\ because Windows is not smart enough to realize that having a VPN connected to that IP address implies all traffic on all ports to that address except the encrypted VPN packets themselves should be be routed through the VPN IP. A side of effect of not being able to use the FQDN for the file sharing path is that windows may not keep the connection alive and will assume that it can be reestablished quickly as a local address, when in reality it will idle out after a minute and then take 30 seconds to reestablish a connection to the shared folder. This can be resolved by setting a higher idle timeout in the registry. The default idle timeout for a network share defaults to 600 seconds (10 minutes). To keep the connection alive longer, add a DWORD registry value named "KeepConn" to the registry key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters", and give it a higher value (in seconds) such as 3600, which would be an hour. According to the link:
Increase the value of this entry if your application closes and opens
Universal Naming Convention (UNC) files on a server less frequently
than every 10 minutes. This decreases the number of reconnections to a
server.
UPDATE: I forgot to mention that although file sharing over VPN using purely built-in Windows 7 and Windows Server 2012 features, there is an extra step necessary for Windows Server 2008 because of some bug/feature where traffic on the SMB ports appear to be blocked on the default network adapter independently of the firewall. You must install the microsoft loopback adapter, which will then function identically to the default interface aside from allowing SMB traffic, so once you get it installed it should look like this. Then instead of connecting to the share on 192.168.1.1 (the Server's VPN address), you connect to 192.168.1.2, which is the loopback adapters address:
Instructions on how to install the loopback adapter can be found here: http://blogs.msdn.com/b/virtual_pc_guy/archive/2005/10/04/477195.aspx
Best Answer
This doesn't seem complicated...
Wouldn't a route for 72.233.89.196/29 on network A's router that uses the network B router as its next hop do the trick?
In this case your router is probably your firewall == vpn device == gateway.
What happens when you try this?