Server 2012 R2 VPN Issue

scottay

Member
Reaction score
10
Location
Reno, NV
Hi all,

I'm fighting to get my VPN working the way I need it to at my office. I recently setup my home office, as well as have an employee going on maternity leave that will be working from home. I'm trying to get my VPN setup and am fighting with something that seems trivial, but I can't seem to find a solution. Hopefully you all can steer my in the right direction.

Setup:
ASA5505 at the edge of my network (NAT and ports setup to allow VPN).
Server 2012 R2 running as a guest under a Hyper-V host.
Guest OS is my domain controller, FTP server, file server, and now VPN server.
Guest OS has 2 NICs associated with it: a DMZ interface used for my FTP traffice, and the Internal Network interface for everything else (nothing but the VPN is public facing on this interface at the moment).

I setup the Routing and Remote Access piece using the "Custom" setup, and selected VPN. Not a whole lot of config there.

I setup the Remote Access part.

Long story short, I got it all setup and wasn't able to connect. I suspected the ASA was the issue, as I'm still getting familiar with how to configure NAT and Firewall rules. After a bunch of fishing and looking at logs I spotted the problem. The traffic was coming into the ASA and going to the correct interface on the server, but for some reason the server was sending the outbound packets through the DMZ interface. After disabling the DMZ interface, the VPN connected right up. For the past week and a half or so I've just been running in this configuration because I needed the VPN to work; however, I use the FTP to access troubleshooting tools (malware removal, net diag, etc) when out in the field. The FTP is tied to the DMZ interface, thus with that interface disabled I can't get to my FTP. I'm at a point where I need to get this working, so I need to figure out which component on the server is directing outbound VPN traffic out the DMZ interface instead of the same interface on which it came in (ie. the Internal interface). I suspect the Routing and Remote Access component, but after screwing with numerous settings and different configurations I still can't get my VPN to work unless I disable the DMZ all together.

Any ideas "who" is telling the outbound VPN traffic to flow out the DMZ??

Thanks!
 
What is the point of having two Virtual network cards and calling one of them a DMZ, when they both are on the same virtual machine? It makes more sense to have every service bound to one virtual network card and forward all your traffic into that. If you have two network cards in the machine then do they both have the same default gateway specified?

You might get it working by putting the same default gateway into both virtual network cards but I suggest the best answer is to consolidate down to just one network card
 
After rereading your post I wonder what IP addresses subnet masks and default gateways you have got on each network card . Can you post an IPconfig /all
 
It's not two virtual network cards. The physical server has 3 NICs. One for internal, one for the DMZ, and the other for other stuff I don't need to explain here. I have the DMZ interface bound to my FTP IIS site because I don't want that traffic getting mixed up with or compromising internal network. The Internal interface is for all of my local traffic (DC, file access, etc, etc). Now I want that interface to also handle my VPN, since this is the network I want the VPN to tie into.

Both NICs are on completely different subnets, and definitely do not share the same gateway.

I can't consolidate down to a single NIC because then there would be no separation between my IIS FTP and the internal network. Both are on different public IP's by design, as I want a clear distinct boundary between the two.

In response to your second post, here is an ipconfig (removed some unneeded stuff and publicly identifiable info)

Ethernet adapter Ethernet:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.1.5(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.5
127.0.0.1
NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter DMZ:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter #2
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.100.13(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.100.1

DNS Servers . . . . . . . . . . . : 8.8.8.8
NetBIOS over Tcpip. . . . . . . . : Enabled
 
What is the point in having a DMZ network for your server when the server is also connected to your LAN? If someone was able to gain access via the DMZ interface, they would have access to your server and possibly to the LAN network via the other interface on the server. The only benefit in having a machine in a DMZ zone is if it actually lies in a separate network than the rest of your more secure servers to where you can apply very strict access rules to and from. That way if it were compromised, it wouldn't directly affect more secure endpoints.

You can easily accomplish what you are trying to do with a single interface and using NAT/Port Forwarding on the ASA 5505. Just setup a nat rule to translate ftp traffic on your server to your public IP on same ports. Then I believe with the ASA you need to turn on ftp inspection in the security policy to enable PASV connections to work correctly.
 
https://support.microsoft.com/en-us/kb/157025

Logic still applies, multihomed servers with more than one default gateway is not a best practice

I still recommend getting server down to one nic. Very little benefit in keeping the ftp traffic off the lan broadcast domain.

If you need separation then chuck up a vm in the DMZ perhaps with one nic.

Another possibility is to use your firewall to terminate the VPN instead of 2012. This has the added benefit that you can vpn in and reboot 2012 vm without getting booted off vpn
 
Both valid points, thank you for your input.

I initially planned on terminating the VPN with the ASA, but in the past I've had DNS issues through a gateway VPN. Since these are home offices, setting up local DNS server or using "hack" (HOSTS file, etc) aren't ideal. I figured just using 2012 as the VPN host would allow us to easily tunnel into the environment, as well as reduce some of the "housekeeping" with a gateway VPN.

Regarding the points about the dual NICs into the 2012 box, I'm understanding the logic behind this. Instead of ripping everything apart and rebuilding, I think I'll just pip the FTP through the Internal interface and do away with the DMZ. My thought was using the DMZ interface would create a barrier between the FTP and my internal network; however, taking your posts into consideration, once the server is accessed, that barrier is gone. I still feel it's slightly better than not having it, but given my headaches (and more to come I'm sure with dual gateway), it's not worth it. If I feel it is, I'll spin up a dedicated FTP server strictly on the VPN.

Thank you both! Funny how we can overthink these things when we're stuck in the middle of it all =)
 
Having 2x NICs was "best practice" back in the days when letting a Windows server do VPN hosting was common. Matter of fact I think it was mandatory to have 2x NICs minimum (in older versions of Windows), else Windows would barf up an error when launching RRAS. I did lots of them that way back then. Talking back in the NT 4 days. These days I won't expose that service from a Windows box to the internet. The the reason was good for performance, and security. As you can lock down that external NIC with packet filters and routing.

I don't now if it's still the same on newer versions of Windows...guessing it is, but we used to go into network properties (ncpa.cpl) ...bring down advanced options in the top menu, and tickle the firing order of bindings to adapters. Pretty sure I used to un-bind server/workstation services from that external facing (DMZ in your case) NIC. Its been over 15 years since I used to bang these out....a little rusty I'll see about finding a guide. I "think" I would leave the gateway blank from that external NIC also...can't remember. I'll see if I can dig up some guides.

You doing PPTP or IPSec? I remember on the Cisco's back then...not only did you have to do the port forwarding, but you also had to tell them to allow GRE traffic (IP type 47...not port 47..but pass IP type 47). That's not your issue though if you have it working some of the time. You'd be getting a specific error from the VPN client when trying to log in.

There was some routing modification in RRAS that would be done when you ran through configuring RRAS. I'm pretty sure your issue is in there. Can you post screenies running through that?
 
Last edited:
Back
Top