locked
NAP_VPN_stepbystep breaks in real world RRS feed

  • Question

  • So my question... Is there any documentation on setting up the VPN server to be protected by a firewall on a DMZ or isolated VLAN with the VPN Client connecting remotely via the outside interface and actually having access to internal devices?
    Preferrably a CISCO PIX/ASA due to Microsoft being such partners with Cisco.

    The instructions for the NAP_VPN_stepbystep works great in the controlled lab environment that is described in the document.

    The network scenario is designed to have routing configured that the client has full IP connectivity to the internal network with no limitations post NAP enforcement.

    When the "VPN" interface is configured and launched on the client1, the policies are enforced via the NPS server and the health checks are run and all is golden.
    Did I mention that the VPN server has software routing between the internal and internet subnets because there is an interface in each network.... how conveniant...

    *****THIS IS WHERE IT BREAKS DOWN!!!

    In the real world, there is no guaranteed physical connectivity from the VPN client home computer to the same subnet that is on the VPN servers internet interface. In fact, the only interface that should be enabled on the VPN server in the real world should be one interface that is either in a DMZ or an isolated internal VLAN.
    Also, in most all network infrastructures, there is a security boundry protecting the internal network with a firewall.

    I personally have a Cisco PIX in my lab and extended the network scenario to add that PIX device as a test to mimic a classic remote access solution.
    With just a few modifications to the NAP_VPN_stepbystep.doc to place the client outside the PIX with the VPN server on the inside, the VPN client computer registers itself and runs health checks and is OK.

    But.... any devices that are on the internal interface subnet ie.. file server, DC, NPS are absolutely INACCESSIBLE from the VPN client experience.
    This was not the case in the controlled VPN_NAP_stepbystep instructions. The only reason why the client1 was able to access the internal devices after NAP enforcement policies were run on the network that was outlined in the stepbystep document, was because the client1 could ALREADY access those servers due to the way the network was created.
    In other words, the network scenario was already stacked in favor of success

    I dont know if anyone has actually made the VPN_NAP_stepbystep solution work the way it would be configured in 99% of most networks of today. I would think that most networks would have a Cisco firewall or other third party firewall solution and that Microsoft would have at least some documentation on that type of scenario.

    thanks,
    Saturday, September 8, 2007 5:47 PM

Answers

  • Hi,

     

    I'm just following up on this issue FYI to the forum. There was a static route missing from one device. When this was added, the VPN configuration works as expected.

     

    -Greg

    Thursday, September 13, 2007 11:12 PM

All replies

  • Hi,

     

    There will be additional information about non-test-lab scenarios in the NAP design and deployment guides, which will be available later this year. The step by step guide is only intended to demonstrate the basic functionality on a lab environment with a minimum number of servers. This is noted in the document above the scenario overview.

     

    I agree that the VPN server's external interface is typically located in a subnet with access protected by a firewall (i.e. a DMZ). This subnet normally contains several resources that are accessible by Internet clients, with traffic restrictions controlled by firewall filters as you noted. This could be added to the lab by replacing hub1 with a device capable of IP filtering. Is this where you placed the PIX?.

     

    I'm not sure what you mean when you indicate that the VPN client in the step by step guide could already access the internal subnet (prior to activating the VPN session). This should not be the case. Have you configured the VPN server as a default gateway on the VPN client? The test lab client machine does not include use of a default gateway, which restricts internal access of the client until it connects via the VPN interface.

     

    In your modified setup, how are you checking connectivity to other internal resources after forming the VPN connection?

     

    -Greg

    Saturday, September 8, 2007 7:25 PM
  • Hi Greg,

    Thanks for your reply.

    The answer to question 1: I have a Cisco 2801 router with two interfaces. One is connected on a subnet with the Microsoft Client1 Vista machine. The other is connected to the "Outside" interface of my PIX. I have static and default routes configured on the Cisco 2801 router as best practices for internet facing routers. The PIX is configured with a static translation to have one of the block of internet IP addresses point to the VPN server IP address. The physical location of the VPN server in on a DMZ. I am only using one interface on the VPN server. I have another Cisco 2651 router that is connected between the PIX inside interface on a private network. I have a Cisco 3548 switch connected to the Cisco 2651 router. I have the NPS server on the internal Cisco 3548 switch along with the DC. All internal routing is configured with OSPF and all networks are advertised.
    The above is a simple network infrastructure that should be representative to most network solutions for security.

    The answer to question 2: The client can ping the translated IP address of the VPN server from the outside, so I know the routing and PIX are configured properly. The client can make a VPN connection via the translated IP address (not the real IP address on the DMZ) of the VPN server. The client gets registered on the domain and status "connected", so I know that the communications between the DMZ and the NPS server is working and the policies are applied,, ie.. the RADIUS client (VPN1) is talking to the RADIUS server.

    My take as it seems right now, is that all communications are between the CLIENT1 and the VPN server for the client experience. The reason why the client is successful in getting NAP enforcement policies is because the RADIUS client configured on the VPN server is proxing to NPS. I have setup the client setup to have full access.  No quarantine is taking place.

    Right now, when I try to ping or map a drive from the CLIENT1 machine in connected status to any device on the internal network, there is absolutely no communication taking place. I know there has to be communication taking place between the client and the NPS server, because policies are being applied. So I think the VPN server is the only physical machine that is able to talk to the internal network.
    The way it is setup now, the real interface on the CLIENT1 has no default gateway, and the VPN interface is not getting a default gateway either.
    I have tried creating a static route on the CLIENT1 with no success. I also have no NAT for any traffic coming from the inside network pointing to the IP address range that the client computers are getting.
    I also cannot ping the IP address of the CLIENT1 machine from the internal network,, i.e DC1.

    So is there some kind of routing taking place that I need to look at on the VPN1 server that is some kind of a proxy for the VPN clients?

    thanks,

    Saturday, September 8, 2007 8:16 PM
  • Hi,

     

    If I am reading your setup correctly, it looks like this:

     

    (NPS)-[3548sw]-[2651rtr]-[PIXnat]-[2801rtr]-(Client)
                  |                          |
               (DC)                    (VPN)

     

    Please tell me if this is correct. Since the client can successfully establish a VPN connection, I assume routing is OK. I wonder a little whether the PIX is applying any packet filters to VPN traffic. Is this possible?

     

    Keep in mind that just because policies are applied to the client, it does not mean that there is direct communication occurring between NPS and the client. You were correct when you said that the client communicates only with VPN1, and VPN1 in turn communicates with NPS. That's normal. With the simple lab setup, the client machine will have access to DC1 and NPS1 because it is on the same subnet.

     

    The inability to map drives and ping can be caused by a firewall issue. A tool you can try to test connectivity is rpcping, which usually is not blocked by the firewall. For example:

     

    rpcping -s 192.168.0.2

     

    A successful response will read "Completed 1 calls..."

     

    If this doesn't work, I think there may be an issue getting through the PIX or the 2651.

     

    -Greg

     

    Edit: Looking at the setup again (if I have it represented correctly), it looks like the connectivity problem may be due to the the NPS and DC being connected to a separate interface on the 2651 than VPN clients. No traffic would cross the 2651 in this scenario. Perhaps I have your setup wrong - let me know.

    Saturday, September 8, 2007 9:34 PM
  • Hi Greg,

    Yes the network is setup as you diagrammed.

    Here is the output of the rpcping.
    I made modifications to the IP address scheme. The NPS server is 10.2.1.207

    Exception 1722 <0x0000006BA>
     Number of records is : 4
     ProcessID is 696
     System Time is: 9/8/2007 21:46:36:227
     Generating component is 8
     Status is 0x6BA, 1722
     Detection location is 1442
     Flags is 0
     NumberOfParameters is 1
     Unicode string: 10.2.1.207
     ProcessID is 696
     System Time is: 9/8/2007 21:46:36:227
     Generating component is 8
     Status is 0x45D, 1237
     Detection location is 313
     Flags is 0
     NumberOfParameters is 0
     ProcessID is 696
     System Time is: 9/8/2007 21:46:36:227
     Generating component is 8
     Status is 0x274C, 10060
     Detection location is 311
     Flags is 0
     NumberOfParameters is 3
     Pointer val: 0x0
     Pointer val: 0x0
     ProcessID is 696
     System Time is: 9/8/2007 21:46:36:227
     Generating component is 8
     Status is 0x274C, 10060
     Detection location is 318
     Flags is 0
     NumberOfParameters is 0

    So does this mean that there is an IP filter of some kind that is preventing communication from the CLIENT to the internal network and vice-versa?

    Thanks,




    Saturday, September 8, 2007 10:40 PM
  • Hi,

     

    What is the client IP address? If it is on the 10.2.1.X subnet, then it won't cross the 2651 to reach the switch and any servers connected to the switch, because it will believe these addresses are local. If it is on another subnet, does route print show that the client knows how to get to 10.2.1.X?

     

    -Greg

     

    Saturday, September 8, 2007 11:11 PM
  • Hi Greg,

    Here is the IP address scheme.  (this is test lab)
                                                  10.10.251.0/24
                                                        *INSIDE*

                                                             |                                                               

    10.2.1.207/24 (NPS)-[3548sw]-[2651rtr]-[PIXnat]-64.3.196.192/27 *OUTSIDE*-[2801rtr]-(Client) - (can only ping router int
                          |                     |                  |                                                            |               and VPN translated)
                       (DC)          10.2.1.0/24       (VPN)                                             192.168.10.0/24

              10.2.1.201/24                      10.206.180.0/26                                         *INTERNET*
                                                               *DMZ*

    1). The IP Pool on VPN is 192.168.50.1-192.168.50.254
    2). Client IP address 192.168.10.100 > Router 192.168.10.1
    3). Static translation on PIX is dmz,outside 64.3.196.195 10.206.180.3 (Client VPN connection to 64.3.196.195) works OK.
    4). access lists are to allow all IP to cross outside interface to dmz for host 64.3.196.195
    5). lower security dmz access list allow IP traffic to pass from 10.206.180.3 to hosts on inside
    6). NAT exemption from inside to 192.168.50.0/24

    Note:* I have used different RFC1918 address blocks for the IP pool all with same result on the client not being able to ping internal devices once the VPN connection is made. The client has two IP addresses after connection is made, one for the IP pool and one for the physical interface. 
    I would think that with the NAT exemption statement on the PIX, that communication would occur between the inside and the client because the VPN tunnel (correct me if I am wrong about tunnel) is basically an extention to the inside network.

    Thanks,

                                    
    Sunday, September 9, 2007 12:10 AM
  • Greg,

    The tabs got a little off center on the diagram.

    You will have to move over to right just a bit.

    Thanks,

    Sunday, September 9, 2007 12:16 AM
  • Hi,

     

    It's an interesting setup. I think we might do better to exchange a few emails and troubleshoot the setup that way. If you can, please send a diagram of your setup to me in email.

     

    My email address is greglin@online.microsoft.com <-- remove the "online." to actually get my email address.

     

    Thanks,

    -Greg

    Sunday, September 9, 2007 3:36 AM
  • Greg,

     

    The diagram is sent.

    You should have it in your inbox email.

    I sent a visio as a zip file, so hopefully your email system did not quarantine it.

     

    Thanks,

     

    Tuesday, September 11, 2007 5:10 PM
  • Hi,

     

    I got it - thanks for sending this. I'll be looking it over today and reply with my questions and suggestions.

     

    -Greg

    Tuesday, September 11, 2007 5:22 PM
  • Hi,

     

    I'm just following up on this issue FYI to the forum. There was a static route missing from one device. When this was added, the VPN configuration works as expected.

     

    -Greg

    Thursday, September 13, 2007 11:12 PM