none
VPN to guest machines

    Question

  • I want to VPN over the Internet into some 2012 R2 host servers as well as guest VM's using Windows software configuration to do this as opposed to a hardware/router based VPN.  Some of the 2012s are Core, the others GUI. Some of the VM's are XP and others are Windows 7. As far as the remote computers connecting via VPN they will be XP and Windows 7.  At the end of the process I would want to copy files back and forth between the remote hosts/their guest VM's and the computers that are connecting to the VPN across the Internet.

    I have had no problems VPN'ng into workstations that were physical XP's and Windows 7. However once I have virtualized them I can't seem to get in.  I can TS into them as VM's but not VPN.  I think the issue is that the VM is on top of a virtual NIC and part of a virtual switch/network instead of physical. 

    Assume I have one virtual NIC on my VM.  Assume I have two NIC's on the host - one I want exposed to the external world via a physical firewall and one that I want to keep internal - not exposed to the Internet. Also assume I do not want the host to be a DC or belong to any domain. Finally assume my static IP is 11.22.33.44.  And for the case of simplicity let us assume that my server OS is 2012. What IPs should I use for the virtual NIC in the VM, the two in the host?  What security modifications should I make in 2012 firewall rules? What ports should I open on the physical firewall?

    Would the virtual networks feature that came out in 2008 R2 and has been expanded on in 2012 be of use here?

    Thursday, October 17, 2013 6:13 AM

Answers

  • Hi arlesterc,

    There's quite a lot to this question, but there's also some fundamental design choices that it sounds like you might be misunderstanding, so it might pay to start there. Alternatively, I could just be misunderstanding the scenario you're trying to illustrate, in which case just correct me as we go.

    First, I'm making an assumption that the servers you're trying to reach are all part of the same environment, i.e. not for different customers on different public IP ranges.

    Secondly, I'm going to assume that there is indeed some form of hardware firewall in between the customer environment and the Internet. If there's not, please let us know.

    So, moving along...

    It's not normal to VPN into each and every destination host. VPN connections are usually made between the client and one server or device that is dedicated to hosting the VPN server function. From there, your traffic routes from your client, through the VPN tunnel, comes out on the other side and finally reaches the desired host.

    The VPN server typically will have two NICs: one internal-facing NIC and one connected to the DMZ and configured with a publicly routable IP address.

    The operating system doesn't really change this paradigm. The design applies just as readily to devices or Linux/Unix hosts as it does to Windows, so the operating system really has no influence on this.

    One thing the operating system can dictate is which authentication and encryption protocols you have access to, most commonly specified when you choose the type of VPN tunnel you want to create. Because you've said there will be Windows XP clients, you'd ideally want to be using an L2TP/IPsec VPN type, or if you want to go for something easier, you'd be looking at PPTP, though I would strongly recommend against this.

    In terms of virtual versus physical, it doesn't really matter: both will work assuming any devices (i.e. getting back to my previous assumption about firewalls) in between are configured correctly. Normally, you would have the VPN server - be that physical or virtual, connected to your DMZ environment. It's not quite as normal to find people having set up a VPN server via port forwarding (i.e. if the VPN server is behind a NAT device). The Windows XP or 7 client is then configured to create a VPN connection to this publicly routable IP address.

    Once the client has connected, your client is issued with an internally routable IP address and you can directly access the hosts inside the network - again, assuming any firewalls and potentially even the VPN server itself is configured to allow that.

    With respect to the firewall rules, there's two things to consider with this kind of deployment:

    1. The VPN server needs to allow the relevant ports and protocols to pass through to it. If you're using a Windows 2012 server as the VPN server, it will automatically add the relevant firewall exceptions when you add the Network Policy Server role and relevant service role(s).
    2. The firewalls on the destination hosts - again, assuming they're Windows hosts, need to allow relevant traffic to originate from the IP range assigned to VPN clients. This may not be a problem for you as I personally haven't seen too many people or places locked down the firewall rule scopes to that degree (though I personally do, which is why I mention it).

    Focusing on your example IP address of 11.22.33.44, this would ideally be the publicly routable IP address of the VPN server. It would also be the address which you would configure your client to point to.

    If you are interested in using a port forwarding configuration, have a read of this: http://support.microsoft.com/kb/233256/en-au.

    If you need to know which ports and protocols are involved with things like L2TP/IPsec and PPTP, have a read of this (under Routing and Remote Access): http://support.microsoft.com/kb/832017/en-au#method44.

    Cheers,
    Lain

    Thursday, October 17, 2013 7:04 AM
  • Hi,

    The problem you're going to face is that every destination host you expect to reach through establishing a VPN tunnel to it will need to have a public IP assigned to it. You can still use port forwarding in this configuration, but it's a terrible waste of public IPs, hence my mentioning that when it comes to VPN design, you typically have just the one VPN server through which you then access all of the resources behind it in the internal network.

    The reason you'll here the terminology "VPN tunnel" is because by design, you are meant to establish one tunnel through which you access everything you want.

    Multiple clients connecting to one VPN server is quite normal, but having clients VPN into multiple VPN servers serving the one environment is not.

    Once you have established the VPN connection to your VPN server, you can map drives and establish Remote Desktop connections to internally-hosted destination hosts to your heart's content - again, assuming there's no firewall issues on the destination host or policy rules on the VPN server precluding that.

    Cheers,
    Lain

    Thursday, October 17, 2013 7:21 AM
  • Yes, you can (assuming we're talking about Windows Server guests). Although it would make no sense in every measureable way, you can still do it.

    I'm not going to go into depth on the topic as there's too many design variables, but what I will point out again is it has nothing to do with the virtualisation vendor or version. VMware, Hyper-V, XenApp - they can all do it (assuming the platform is even reasonably current).

    Decide on whether you're going to use port forwarding (PAT) or routing as that will determine where all your public IPs are going to be located (the hardware appliance or the guest respectively).

    After that, you simply have to figure out your software strategy, i.e. whether you want to use the NPS role, third party VPN software, etc. The bottom line is you need something to act as the VPN server while your external guests act as the VPN client.

    Suffice to say that if you have some kind of firewall or even router with security rules, you'll have to create a rule/rules to allow the inbound VPN protocols and ports to connect to each of those public IPs (regardless of whether you're using PAT or routing).

    If you're using public IPs on the guests, you'd be best to create a new virtual switch to which the IP range belongs. If you don't have a contiguous block of IPs you can allocate to the virtual environment in the form of a virtual switch, then that would normally dictate that you use a PAT, in which case your VMs will simply have internal IPs.

    There's nothing normal about this scenario meaning there's bound to be more I've not thought about yet, but those above are certainly the key points you need to design around.

    Cheers,
    Lain

    Tuesday, October 22, 2013 4:04 AM

All replies

  • Hi arlesterc,

    There's quite a lot to this question, but there's also some fundamental design choices that it sounds like you might be misunderstanding, so it might pay to start there. Alternatively, I could just be misunderstanding the scenario you're trying to illustrate, in which case just correct me as we go.

    First, I'm making an assumption that the servers you're trying to reach are all part of the same environment, i.e. not for different customers on different public IP ranges.

    Secondly, I'm going to assume that there is indeed some form of hardware firewall in between the customer environment and the Internet. If there's not, please let us know.

    So, moving along...

    It's not normal to VPN into each and every destination host. VPN connections are usually made between the client and one server or device that is dedicated to hosting the VPN server function. From there, your traffic routes from your client, through the VPN tunnel, comes out on the other side and finally reaches the desired host.

    The VPN server typically will have two NICs: one internal-facing NIC and one connected to the DMZ and configured with a publicly routable IP address.

    The operating system doesn't really change this paradigm. The design applies just as readily to devices or Linux/Unix hosts as it does to Windows, so the operating system really has no influence on this.

    One thing the operating system can dictate is which authentication and encryption protocols you have access to, most commonly specified when you choose the type of VPN tunnel you want to create. Because you've said there will be Windows XP clients, you'd ideally want to be using an L2TP/IPsec VPN type, or if you want to go for something easier, you'd be looking at PPTP, though I would strongly recommend against this.

    In terms of virtual versus physical, it doesn't really matter: both will work assuming any devices (i.e. getting back to my previous assumption about firewalls) in between are configured correctly. Normally, you would have the VPN server - be that physical or virtual, connected to your DMZ environment. It's not quite as normal to find people having set up a VPN server via port forwarding (i.e. if the VPN server is behind a NAT device). The Windows XP or 7 client is then configured to create a VPN connection to this publicly routable IP address.

    Once the client has connected, your client is issued with an internally routable IP address and you can directly access the hosts inside the network - again, assuming any firewalls and potentially even the VPN server itself is configured to allow that.

    With respect to the firewall rules, there's two things to consider with this kind of deployment:

    1. The VPN server needs to allow the relevant ports and protocols to pass through to it. If you're using a Windows 2012 server as the VPN server, it will automatically add the relevant firewall exceptions when you add the Network Policy Server role and relevant service role(s).
    2. The firewalls on the destination hosts - again, assuming they're Windows hosts, need to allow relevant traffic to originate from the IP range assigned to VPN clients. This may not be a problem for you as I personally haven't seen too many people or places locked down the firewall rule scopes to that degree (though I personally do, which is why I mention it).

    Focusing on your example IP address of 11.22.33.44, this would ideally be the publicly routable IP address of the VPN server. It would also be the address which you would configure your client to point to.

    If you are interested in using a port forwarding configuration, have a read of this: http://support.microsoft.com/kb/233256/en-au.

    If you need to know which ports and protocols are involved with things like L2TP/IPsec and PPTP, have a read of this (under Routing and Remote Access): http://support.microsoft.com/kb/832017/en-au#method44.

    Cheers,
    Lain

    Thursday, October 17, 2013 7:04 AM
  • Thanks for the quick response with all the info.  If it is impossible to directly VPN into a guest VM as I have described that's fine but if it is possible - whether advisable or not - I want to directly VPN into a guest VM. For instance I may want to map a drive to one of the folders on the guest VM and copy to my local PC across the Internet. I did this regularly when my Windows XP and Windows 7 were physical.  If it is at all possible I would like to know what I have to do to achieve that. If the networking setup I described as my desired one will not do the trick then I am open to anything that will do the trick. Thanks in advance for any further attention to this issue.
    Thursday, October 17, 2013 7:10 AM
  • Hi,

    The problem you're going to face is that every destination host you expect to reach through establishing a VPN tunnel to it will need to have a public IP assigned to it. You can still use port forwarding in this configuration, but it's a terrible waste of public IPs, hence my mentioning that when it comes to VPN design, you typically have just the one VPN server through which you then access all of the resources behind it in the internal network.

    The reason you'll here the terminology "VPN tunnel" is because by design, you are meant to establish one tunnel through which you access everything you want.

    Multiple clients connecting to one VPN server is quite normal, but having clients VPN into multiple VPN servers serving the one environment is not.

    Once you have established the VPN connection to your VPN server, you can map drives and establish Remote Desktop connections to internally-hosted destination hosts to your heart's content - again, assuming there's no firewall issues on the destination host or policy rules on the VPN server precluding that.

    Cheers,
    Lain

    Thursday, October 17, 2013 7:21 AM
  • Hi,

    I would like to check if you need further assistance.

    Thanks.


    Alex Lv

    Tuesday, October 22, 2013 1:49 AM
  • Thanks for the feedback.

    I think the point is being missed here. Can I or can I not VPN into a VM? Again whether it's advisable or not - is it technically possible?

    Here is the scenario I laid out.

    "Assume I have one virtual NIC on my VM.  Assume I have two NIC's on the host - one I want exposed to the external world via a physical firewall and one that I want to keep internal - not exposed to the Internet. Also assume I do not want the host to be a DC or belong to any domain. Finally assume my static IP is 11.22.33.44.  And for the case of simplicity let us assume that my server OS is 2012. What IPs should I use for the virtual NIC in the VM, the two in the host?  What security modifications should I make in 2012 firewall rules? What ports should I open on the physical firewall?

    Would the virtual networks feature that came out in 2008 R2 and has been expanded on in 2012 be of use here?"

    I don't care about misusing Public IP's, I don't care what is the common way of doing things, etc.  The question is whether there is some way I can do the above or is it not technically doable? Can I or can I not VPN into a single VM?  If so how do I do it - I need to be provided with working specs so that I know I am doing what is at least in theory is correct.

    Tuesday, October 22, 2013 3:21 AM
  • Yes, you can (assuming we're talking about Windows Server guests). Although it would make no sense in every measureable way, you can still do it.

    I'm not going to go into depth on the topic as there's too many design variables, but what I will point out again is it has nothing to do with the virtualisation vendor or version. VMware, Hyper-V, XenApp - they can all do it (assuming the platform is even reasonably current).

    Decide on whether you're going to use port forwarding (PAT) or routing as that will determine where all your public IPs are going to be located (the hardware appliance or the guest respectively).

    After that, you simply have to figure out your software strategy, i.e. whether you want to use the NPS role, third party VPN software, etc. The bottom line is you need something to act as the VPN server while your external guests act as the VPN client.

    Suffice to say that if you have some kind of firewall or even router with security rules, you'll have to create a rule/rules to allow the inbound VPN protocols and ports to connect to each of those public IPs (regardless of whether you're using PAT or routing).

    If you're using public IPs on the guests, you'd be best to create a new virtual switch to which the IP range belongs. If you don't have a contiguous block of IPs you can allocate to the virtual environment in the form of a virtual switch, then that would normally dictate that you use a PAT, in which case your VMs will simply have internal IPs.

    There's nothing normal about this scenario meaning there's bound to be more I've not thought about yet, but those above are certainly the key points you need to design around.

    Cheers,
    Lain

    Tuesday, October 22, 2013 4:04 AM