2

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 203.10.10.10 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:

Network Diagram

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.

QUESTION

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 203.10.10.10 11 10.17.255.255 255.255.255.255 On-link 203.10.10.10 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?

  • I like your question, it's a very clear and well-researched writeup! – Per von Zweigbergk Oct 2 '15 at 15:21
  • Thanks Per - I've spent more time than I care to remember scratching my head over this the last couple of days - figured I might as well throw everything I can into sharing the pain, haha. – Daniel Scott Oct 2 '15 at 15:43
1

You're kind of fighting against the natural tendencies of how source IP address selection works when trying to do this. So why not just change your design up a little bit for it to flow more naturally?

The problem is that source IP address selection is done prior to the decision to push traffic down the tunnel. That means that it'll choose to use the "public" IP address as the source IP for any traffic originating through the tunnel.

On some OS:es, you can do fun things with routing, specifying source addresses on a route for host-originated traffic. I can't find anything like that on Windows though.

However, given your network design, I think the simplest way of solving this problem is to stop fighting with RFC1918 addresses on the server side, and just go ahead and set up a tunnel with SA's between your public ip 203.10.10.10 and the private IP addresses 10.16.0.0/15.

The clients would then address the server as 203.10.10.10 rather than 192.168.70.1, and everything else would hopefully just magically fall into place. That way, source IP selection will already pick an appropriate address that will work.

You can keep the old ipsec policy in place during a transition period, so that your clients may address the server either with the old RFC1918 address or with the new public address, while your DNS cache expires (assuming you're using DNS for this - if not, it's a good idea). After a transition period, the address 192.168.70.1 has no function any more.

The other option is to explicitly choose the source IP address when initiating connections from your server - which may be possible if it's custom software you've written yourself, but that's kinda hairy.

Finally, that loopback adapter idea is promising, it's odd that it shows up as "media disconnected" though. That sounds like a problem with the loopback adapter itself rather than with the idea though.

  • Hi again Per, Thanks for the suggestion. As you've probably guessed, I'm very new to IPSec VPNs - the thought had never occurred to me to use the public IP as the endpoint "inside" the tunnel too - but it definitely makes sense to do it that way in this case (as it will never be necessary to route traffic anywhere beyond the server). It'll be a few days before I can have the team at the other end make the config changes, so if you think there's some merit in the virtual adapter idea I might see if I can find a driver that doesn't tell windows it has no 'physical' connectivity ... – Daniel Scott Oct 2 '15 at 15:48
  • ... Any suggestions on what might be a good virtual adapter to try - or whether there's something out there available to download? – Daniel Scott Oct 2 '15 at 15:59
  • @DanielScott The Microsoft Loopback Adapter should do the job just fine, according to the instructions on technet.microsoft.com/en-us/library/cc708322(v=ws.10).aspx - the Loopback Adapter showing up as "Media Disconnected" should probably be a seperate question though. – Per von Zweigbergk Oct 2 '15 at 16:25
  • Hi Per, I've carried on playing with the other virtual driver I've got - even setting manual metrics on each of the two interfaces to favour the virtual one, but no dice. Incidentally the issue I'm having is exactly the one at social.technet.microsoft.com/Forums/windows/en-US/… - the first ping tries to go out to 10.16.0.x via the virtual interface and it reports "destination host unreachable" - then Windows falls back to the default route. I suspect this could be common to all drivers. – Daniel Scott Oct 2 '15 at 16:40
  • I think you may need to enable IP forwarding for this to work - as per the instructions on technet.microsoft.com/en-us/library/ff687814(v=ws.10).aspx - this is because basically, you're first routing the packet to yourself over loopback (as a hack to get the source IP right) and then you want to forward that packet down your tunnel. Does that help if you enable that? – Per von Zweigbergk Oct 2 '15 at 16:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.