I have a situation identical to the question at IPSec VPN : Traffic not routing correctly (however I don't seem to be able to contact that user directly, nor can I place a comment on that question - and noone has ever answered).
I too have a Windows 2008 R2 server, with an IPSec VPN ending directly at the server.
The server has a single Network Interface, which has a public IP address on it (let's call it 18.104.22.168 for example).
I would like computers on a remote, private network (10.16.0.0/255.254.0.0) to be able to connect to that Windows server on a private IP address at the end of an IPSec tunnel that ends at that server (not at a router in front of the server).
Just as importantly (and this might be the sticking point) I need the server to be able to intiate a TCP connection to devices on the remote (10.16.0.0) network (e.g. to download an image over HTTP).
Here's what it looks like:
The private IP I've chosen for the server is 192.168.70.1/255.255.255.0 and the IPSec filters that establish the tunnel to the remote private network are for source/destinations 192.168.70.0/24 and 10.16.0.0/15.
If I ping an address on the remote network from the Windows server, with the source argument set, then I can establish the tunnel and the pings will work (i.e.
ping -S 192.168.70.1 10.16.0.1).
However, any "normal" traffic sent to a 10.16.x.x address (including pings without the source address forced to 192.168.70.1) is sent merrily off to the Internet via the default route and won't start or enter the tunnel.
Is a setup like this even possible? Or is it not possible to have the VPN endpoint itself send data up the tunnel, originating from one of its private addresses? (Is it always necessary for the VPN endpoint to be on a separate router to the device(s) sending data across the tunnel?)
How can I set up the Windows Server to ensure that all communications with the 10.16.0.0 network will originate from its private IP address.
The private address doesn't have to be 192.168.70.1 - another subnet could be chosen if necessary (I say this because I've read that, all other things being equal, Windows vista and up will use the origin IP that most closely matches the destination - so perhaps using a 10.X.X.X ip for the server's private address would help?)
I can't test that easily however, since the other end of this VPN tunnel is not under my control - and I'd need to have the network engineers at the other end make configuration changes if I choose to change the 192.168.70.1 address.
EXTRA INFO: WHAT I'VE TRIED SO FAR
I've tried two methods of setting that private IP address up (on the Windows server) in an attempt to get packets to route correctly and satisfy the IPSec rules that establish the tunnel.
Private address on the main interface
With the 192.168.70.1 address added to the main network interface (in addition to the public IP), it does not seem possible to define any routes to 10.16.0.0 that would cause windows to use 192.168.70.1 as a source address. Any traffic destined for the default gateway will end up with the public IP as a source.
If there's some magic available route-wise on Windows that I don't know about I'd love to hear about it! However, the command:
route add 10.16.0.0 mask 255.254.0.0 192.168.70.1
will result in routes being added as follows (it picks up the public IP on that same interface to use as the source/on-link gateway).
10.16.0.0 255.254.0.0 On-link 22.214.171.124 11
10.17.255.255 255.255.255.255 On-link 126.96.36.199 266
Private address on a second virtual adapter
I tried adding a virtual network adapter to the server - firstly with the Microsoft Loopback Adapter device. The Loopback device showed up in the list of network connections as having it's "media disconnected". Seeing that the virtual NIC had no connectivity, Windows then just fell back to sending traffic out through the default route anyway (with the public source address).
I then tried with a different virtual device driver - the TAP Virtual Adapter driveer that comes with OpenVPN. That driver allows you to force it into an "always connected" state. However, it seems after the first ping, Windows again figures out that there is no connectivity on that adapter and goes back to sending traffic out via the default gateway on the main (public) interface.
So, that's it ... any ideas?