none
Difficult with VPN on Server 2008 Standard R2

    Question

  • I've been looking all over the internet to find an answer to this question and I often stumble across people asking pretty much the same thing (quite often here on TechNet), but the end result is always the same. Responders either misunderstand the question (and run off on tangents) or the thread simple dies. That could potentially happen here as well, but I'll try and be as specific about the problem as possible.

    I have a Server 2008 Standard R2 machine set up as IP address 192.168.2.239 on the local network. Various other computers (all Windows XP) are connected to the same LAN and have various other addresses in the 192.168.2.x range.

    Everything works fine when there is no one connected to the VPN server. All of the WinXP machines can ping the server (using it's hard-coded IP address) and get back the expected responses:

    PING 192.168.2.239

    They can also connect to the shares on the server using either the machine's assigned name of TS2 or its IP address of 192.168.2.239.

    From an outside network (completed isolated from the LAN operating on 192.168.2.x) I make a PPTP VPN connection to the server and I log in using the administrator username and password to ensure that the connection has complete access to the server. This connection is established without issue. From the connected client I can successfully ping any of the WinXP computers connected to the 192.168.2.x LAN. I can also use Windows Explorer to connect with any of the shares available on those WinXP boxes. So far the VPN seems to be working exactly as expected.

    However, what I cannot do is "see" the server at all. If I ping its IP address of 192.168.2.239 I get a timeout. If I attempt to connect to any of the shares on the server (using its hard-coded IP address) I also get a timeout. I went to the server and I executed IPCONFIG to find out what other IP addresses it had been assigned as a result of the VPN connection, but none of those IP addresses can be pinged either.

    Now this is usually where the answers go off on an unrelated tangent. If the problem was solely to do with the computer than connected via the VPN I might be inclined to focus on possible issues with the connection. HOWEVER this is not the case.

    Now that I've made this connection all of the WinXP computers on the LAN can NO LONGER SEE the server. If I type PING 192.168.2.239 on any computer on the LAN I get a timeout. If I try to connect to any of the server's shares (using 192.168.2.239) I get a timeout.

    And here's the kicker: If I DISCONNECT the VPN connection the PROBLEM with local machines being unable to access the server PERSISTS indefinitely until I log onto the server locally and disable the Routing and Remote Access. When I do that everything returns to normal. I can even re-enable Routing and Remote Access and everything continues to work until another VPN connection is made.

    Now while it might seem as though the server computer has become completely invisible, I can still connect a VPN client to it through the 192.168.2.239 address over and over again, meaning that at least some of the ports do actually still work.

    Things I've tried:

    - I shutdown the Windows Firewall on the server computer.

    - I completely removed and re-installed Routing and Remote Access.

    - I reconfigured Routing and Remote Access in as many different ways as I could conceive of (that still allowed a successful PPTP connection).

    - I connected to the VPN through as many different outside networks as I could gain access to.

    None of these things have made a difference whatsoever.

    The KEY problem here is the loss of access to the server by computers connected to it locally through the router. Clearly something is changing inside of the server when a VPN connection is made, but that something doesn't go away just because the connection is closed.

    I'm really getting to my wits end on this one and I'm hoping that someone out there has seen this before and knows how to get around it.

    Wednesday, December 21, 2011 7:34 PM

All replies

  • Now that is a question! Thorough and descriptive. Are there any other server roles configured on the server? Are you sure there are no IP adddress conflicts like the DHCP assigns addresses for VPN clients or a static range of IP addresses is overlapping? Please post an ipconfig /all from the server and from the vpn client while connected.


    MCTS - Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Thursday, December 22, 2011 12:07 AM
  • Now that is a question! Thorough and descriptive. Are there any other server roles configured on the server? Are you sure there are no IP adddress conflicts like the DHCP assigns addresses for VPN clients or a static range of IP addresses is overlapping? Please post an ipconfig /all from the server and from the vpn client while connected.


    MCTS - Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    There are no other roles configured on the server. It's primary purpose is to act as a home for SQL Server 2008 and to offer backed-up storage for the office.

    As for the IP addresses, I went through every possible configuration with them. I tried using various hard-coded IP addresses (where the client told the server what address it wanted), I had the VPN server hand out addressed in a fixed range that I ensured were unique, and I allowed the DHCP to assign the addresses. I tried using addresses in the 192.168.2.x range, as well as those chosen in other ranges, but nothing changed the behavior of the server. I also checked all of the IP addressed assigned to each computer on the LAN, but there were no conflicts.

    In fact, even if I tried to connect to the VPN and it failed (for example I mis-typed the password) that was all it took to cause this issue to spring to life. The moment the VPN server was activated for the first time by a request (successful or not) I would loose access to the server on each of the computers on the LAN. Only disabling Routing and Remote Access would restore access.

    Since typing my original post I have come across stuff on the internet that discusses a very similar issue when DoD is used. However, in this situation no mention of other computers on the LAN loosing access to the server is made. The solutions recommended for this problem involve the creation of static routes on both servers, owing to the fact that Server 2008 does not create these routes by default (whereas previous versions of Server apparently did). I've tried to find ways to translate this solution for normal VPN client connections, but I can't find any static routes that fix the inability for a machine on the LAN to "see" the server once a VPN connection is initially made.

    • Edited by Steve Punter Thursday, December 22, 2011 12:45 AM
    Thursday, December 22, 2011 12:44 AM
  • Hi Steve Punter,

     

    Thanks for posting here.

     

    From the client side, can we ping the RRAS server external interface after VPN connection established?

    Meanwhile, could you please post the ipconfig /all and route print result from both RRAS server and client side first. Also, use the tracert or pathping command to determine where the packets stop routing.

     

    In addition, we can also following the below Microsoft articles to troubleshooting this issue:

     

    Cannot reach beyond the RRAS server from VPN clients?

    http://blogs.technet.com/b/rrasblog/archive/2006/02/09/cannot-reach-beyond-the-rras-server-from-vpn-clients.aspx

     

    VPN clients are unable to access resources beyond the VPN server

    http://technet.microsoft.com/en-us/library/cc732558(WS.10).aspx#BKMK_8

     

    How to troubleshoot TCP/IP connectivity

    http://support.microsoft.com/kb/314067

     

     

    Best Regards,

    Aiden

    Tuesday, December 27, 2011 2:23 AM
    Moderator
  • Steve,

    Curious, what other links, threads, etc, have you found on this? I'd like to see them, in addition to not wanting to duplicate efforts or responses.

    Also, in addition to Aiden and Marius' responses, I've seen this before. It could be either due to the routing table, or binding order, or both. This is probably why it works after you disable RRAS.

    As far as it's blocking internal access to the server itself when VPN clients are connected, that may be a RRAS policy, routing table, or interface binding order. Does the binding order show "Remote Access Connections" listed at the bottom of the list? (In Network Connections where the NICs are listed, ADvanced menu, Advanced Settings, Adapters and Binding order).

    Regarding the routing table, due to RRAS, it becomes a multihomed server and each interface may change it.

    Also, may not be totally relevant, but may affect other things - Remember, any machine registers into DNS, and RRAS will register into DNS IPs provided to connected RRAS clients, which may be unwanted IPs in DNS. If it's configured to use DHCP (if it is, hopefully you've configured a DHCP relay Agent), then it will pull blocks of 10 IPs from DHCP at a time for RRAS connections. Usually to alleviate these sort of issues is to devote the machine just for RRAS without anything else on it. Depending on the number of expected concurrent users, possibly even a low end machine sitting in the closet can be used for this role.

     

    Curious, how did you configure RRAS?

    • Set for LAN and Demand Dialing routing?
    • Is IPv6 Router optionenabled?
    • Broadcast Name Resolution enabled?

    Run a route print from the server while RRAS is disabled, while RRAS is enabled with no clients, and with a client connected. Let's compare them.

    Ace

     

     

     


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn
    Tuesday, December 27, 2011 8:30 PM
  • Hi Steve Punter,

     

    Thanks for posting here.

     

    From the client side, can we ping the RRAS server external interface after VPN connection established?

    Meanwhile, could you please post the ipconfig /all and route print result from both RRAS server and client side first. Also, use the tracert or pathping command to determine where the packets stop routing.

     

    In addition, we can also following the below Microsoft articles to troubleshooting this issue:

     

    Cannot reach beyond the RRAS server from VPN clients?

    http://blogs.technet.com/b/rrasblog/archive/2006/02/09/cannot-reach-beyond-the-rras-server-from-vpn-clients.aspx

     

    VPN clients are unable to access resources beyond the VPN server

    http://technet.microsoft.com/en-us/library/cc732558(WS.10).aspx#BKMK_8

     

    How to troubleshoot TCP/IP connectivity

    http://support.microsoft.com/kb/314067

     

     

    Best Regards,

    Aiden

    The problem is that the only computer that can PING the RRAS server at all is the RRAS server (when logged in locally). None of the other computers physically connected to the LAN can ping the RRAS, nor can the user logged on through its VPN. Even after the VPN user logs out this issue remains, even though everything worked fine up the point where the VPN user logged in (or as I have noted, even when the ATTEMPT to log in, but fail).

    I'm not in a position to try your other suggests at this very moment, but I will do so as soon as I can and I'll post the results here.

    Concerning the links, I greatly appreciate the effort you went to posting them for me, but you seem to be missing the PRIMARY POINT here, which has nothing to do with VPN really, only that its existence, and an ATTEMPT to connect to it, creates a problem on the LAN. Specially, no computer on the local LAN can PING the RRAS server immediately after a computer even ATTEMPTS to connect through the VPN and this problem remains until the Routing and Remote Access is shutdown.

    Wednesday, December 28, 2011 1:33 AM
  • Steve,

    Curious, what other links, threads, etc, have you found on this? I'd like to see them, in addition to not wanting to duplicate efforts or responses.

    Also, in addition to Aiden and Marius' responses, I've seen this before. It could be either due to the routing table, or binding order, or both. This is probably why it works after you disable RRAS.

    As far as it's blocking internal access to the server itself when VPN clients are connected, that may be a RRAS policy, routing table, or interface binding order. Does the binding order show "Remote Access Connections" listed at the bottom of the list? (In Network Connections where the NICs are listed, ADvanced menu, Advanced Settings, Adapters and Binding order).

    Regarding the routing table, due to RRAS, it becomes a multihomed server and each interface may change it.

    Also, may not be totally relevant, but may affect other things - Remember, any machine registers into DNS, and RRAS will register into DNS IPs provided to connected RRAS clients, which may be unwanted IPs in DNS. If it's configured to use DHCP (if it is, hopefully you've configured a DHCP relay Agent), then it will pull blocks of 10 IPs from DHCP at a time for RRAS connections. Usually to alleviate these sort of issues is to devote the machine just for RRAS without anything else on it. Depending on the number of expected concurrent users, possibly even a low end machine sitting in the closet can be used for this role.

     

    Curious, how did you configure RRAS?

    • Set for LAN and Demand Dialing routing?
    • Is IPv6 Router optionenabled?
    • Broadcast Name Resolution enabled?

    Run a route print from the server while RRAS is disabled, while RRAS is enabled with no clients, and with a client connected. Let's compare them.

    Unfortunately I didn't record the various links I went through looking for information on this problem (if that's what you meant). My browser history isn't really a good source of this information because it's absolutely cram-packed with other links that have little or nothing to do with my research.

    Yes I did check the binding order, as this was one of the things I found while researching the problem. "Remote Access Connections" did indeed appear at the bottom of the list when I checked.

    Concerning DNS, doesn't that only affect name resolution? Perhaps I'm wrong, but I was under the impression that when a dotted decimal address is used, DNS is not involved, thus could not be a part of this problem. When I said that other computers on the LAN can't ping the RRAS server, I meant when they pinged it by its dotted decimal address, such as by typing PING 192.168.2.239. And yes, the RRAS server still has that address, because pinging itself still works.

    Well, the company does still OWN a copy of Windows Server 2000 which was replaced by Server 2008. It might be more than adequate to function solely as a VPN server. It looks like I might have to recommend they take this route, as it isn't very expensive (we could use existing retired hardware to run Server 2000). I just thought that it MADE SENSE to have the new server perform this role, and after wasting so many hours trying to get this to work I'd hoped I might finally find a solution to vindicate the time I've put into it.

    Wednesday, December 28, 2011 1:52 AM
  •  

    Unfortunately I didn't record the various links I went through looking for information on this problem (if that's what you meant). My browser history isn't really a good source of this information because it's absolutely cram-packed with other links that have little or nothing to do with my research.

    Yes I did check the binding order, as this was one of the things I found while researching the problem. "Remote Access Connections" did indeed appear at the bottom of the list when I checked.

    Concerning DNS, doesn't that only affect name resolution? Perhaps I'm wrong, but I was under the impression that when a dotted decimal address is used, DNS is not involved, thus could not be a part of this problem. When I said that other computers on the LAN can't ping the RRAS server, I meant when they pinged it by its dotted decimal address, such as by typing PING 192.168.2.239. And yes, the RRAS server still has that address, because pinging itself still works.

    Well, the company does still OWN a copy of Windows Server 2000 which was replaced by Server 2008. It might be more than adequate to function solely as a VPN server. It looks like I might have to recommend they take this route, as it isn't very expensive (we could use existing retired hardware to run Server 2000). I just thought that it MADE SENSE to have the new server perform this role, and after wasting so many hours trying to get this to work I'd hoped I might finally find a solution to vindicate the time I've put into it.


    Dotted decimal, meaning pinging by IP address, uses the routing table. Even if you ping by the FQDN, or a single name (uses the Search Suffix to construct an FQDN, then sends it to DNS to resolve), it still pings the IP. If not found, NetBIOS is the last resort.

    If no machine is able to ping by the FQDN or single name (as described) or IP, then it's a RRAS config, possibly the routing table, causing it.

    Did you get a change to compare the routing table (route print) as suggested?

    If you have a copy of Windows 2003 server, you maybe better off using that instead of 2000, that is if this can't be resolved.

    Sorry to hear it's taking all this time to resolve it. Maybe there is something we are both missing. You always have the option to call Microsoft Support to remote in to take a look. However, it's a one time charge of USD $259.00 plus tax, but they will take as long as needed for them to resolve it. Here's the link if you choose this option:
    http://support.microsoft.com/common/international.aspx?RDPATH=dm;en-us;select&target=assistance

    Ace


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn
    Wednesday, December 28, 2011 2:56 AM
  • So you have the RRAS server acting as a router/gateway for your network. Please post some information such as:

    • ipconfig /all from RRAS server and from a locally connected client.
    • ipconfig /all from vpn client.
    • ipconfig /all from local client after the issue occurs.
    • route print from server/local client before and after issue occurs.

    MCTS - Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Wednesday, December 28, 2011 11:09 AM
  • Here's the ROUTE PRINT from the server when it is functioning correctly (Remote and Remote Access is DISABLED):

     

     

     

    ===========================================================================

    Interface List

     12 ...84 2b 2b 59 fb 02 ...... Broadcom BCM5716C NetXtreme II GigE (NDIS V

    ient) #2

      1 ........................... Software Loopback Interface 1

     13 ...00 00 00 00 00 00 00 e0  isatap.{34463D6A-183B-4503-90E6-A5A651802D4

     10 ...02 00 54 55 4e 01 ...... Teredo Tunneling Pseudo-Interface

    ===========================================================================

     

    IPv4 Route Table

    ===========================================================================

    Active Routes:

    Network Destination        Netmask          Gateway       Interface  Metric

              0.0.0.0          0.0.0.0      192.168.2.1    192.168.2.239    276

            127.0.0.0        255.0.0.0         On-link         127.0.0.1    306

            127.0.0.1  255.255.255.255         On-link         127.0.0.1    306

      127.255.255.255  255.255.255.255         On-link         127.0.0.1    306

          192.168.2.0    255.255.255.0         On-link     192.168.2.239    276

        192.168.2.239  255.255.255.255         On-link     192.168.2.239    276

        192.168.2.255  255.255.255.255         On-link     192.168.2.239    276

            224.0.0.0        240.0.0.0         On-link         127.0.0.1    306

            224.0.0.0        240.0.0.0         On-link     192.168.2.239    276

      255.255.255.255  255.255.255.255         On-link         127.0.0.1    306

      255.255.255.255  255.255.255.255         On-link     192.168.2.239    276

    ===========================================================================

    Persistent Routes:

      Network Address          Netmask  Gateway Address  Metric

              0.0.0.0          0.0.0.0      192.168.2.1  Default

              0.0.0.0          0.0.0.0      192.168.2.1  Default

    ===========================================================================

     

    IPv6 Route Table

    ===========================================================================

    Active Routes:

     If Metric Network Destination      Gateway

     10     18 ::/0                     On-link

      1    306 ::1/128                  On-link

     10     18 2001::/32                On-link

     10    266 2001:0:4137:9e76:1c5e:2bdc:3f57:fd10/128

                                        On-link

     12    276 fe80::/64                On-link

     10    266 fe80::/64                On-link

     10    266 fe80::1c5e:2bdc:3f57:fd10/128

                                        On-link

     12    276 fe80::d556:702c:da61:8c5e/128

                                        On-link

      1    306 ff00::/8                 On-link

     10    266 ff00::/8                 On-link

     12    276 ff00::/8                 On-link

    ===========================================================================

    Persistent Routes:

      None

     

     

     

    Here it is again after Routing and Remote Access is ENABLED, a VPN connection has been made, and the problem has surfaced:

     

     

    ===========================================================================

    Interface List

     12 ...84 2b 2b 59 fb 02 ...... Broadcom BCM5716C NetXtreme II GigE (NDIS V

    ient) #2

      1 ........................... Software Loopback Interface 1

     13 ...00 00 00 00 00 00 00 e0  isatap.{34463D6A-183B-4503-90E6-A5A651802D4

     10 ...02 00 54 55 4e 01 ...... Teredo Tunneling Pseudo-Interface

    ===========================================================================

     

    IPv4 Route Table

    ===========================================================================

    Active Routes:

    Network Destination        Netmask          Gateway       Interface  Metric

              0.0.0.0          0.0.0.0      192.168.2.1    192.168.2.239    276

            127.0.0.0        255.0.0.0         On-link         127.0.0.1    306

            127.0.0.1  255.255.255.255         On-link         127.0.0.1    306

      127.255.255.255  255.255.255.255         On-link         127.0.0.1    306

          192.168.2.0    255.255.255.0         On-link     192.168.2.239    276

        192.168.2.239  255.255.255.255         On-link     192.168.2.239    276

        192.168.2.255  255.255.255.255         On-link     192.168.2.239    276

            224.0.0.0        240.0.0.0         On-link         127.0.0.1    306

            224.0.0.0        240.0.0.0         On-link     192.168.2.239    276

      255.255.255.255  255.255.255.255         On-link         127.0.0.1    306

      255.255.255.255  255.255.255.255         On-link     192.168.2.239    276

    ===========================================================================

    Persistent Routes:

      Network Address          Netmask  Gateway Address  Metric

              0.0.0.0          0.0.0.0      192.168.2.1  Default

              0.0.0.0          0.0.0.0      192.168.2.1  Default

    ===========================================================================

     

    IPv6 Route Table

    ===========================================================================

    Active Routes:

     If Metric Network Destination      Gateway

     10     18 ::/0                     On-link

      1    306 ::1/128                  On-link

     10     18 2001::/32                On-link

     10    266 2001:0:4137:9e76:1c5e:2bdc:3f57:fd10/128

                                        On-link

     12    276 fe80::/64                On-link

     10    266 fe80::/64                On-link

     10    266 fe80::1c5e:2bdc:3f57:fd10/128

                                        On-link

     12    276 fe80::d556:702c:da61:8c5e/128

                                        On-link

      1    306 ff00::/8                 On-link

     10    266 ff00::/8                 On-link

     12    276 ff00::/8                 On-link

    ===========================================================================

    Persistent Routes:

      None

     

     

    I don't see any differences, but I might have missed something.

    As for Server 2000 vs Server 2003, the company ALREADY OWNS the license to Server 2000, which means there is no cost involved. If they have to switch to Server 2003 to run the RRAS server it would cost them a chunk of change to buy the license (assuming Microsoft still sells one for that version).

    I have considered paying the $259 to open a support issue with Microsoft. I kind of wish I'd done it earlier, because then it would have actually cost the company less to solve this problem that it appears to have cost them now. However, I never entered this thinking it would be such a difficult problem to solve.

    Thursday, December 29, 2011 6:05 PM
  • So you have the RRAS server acting as a router/gateway for your network. Please post some information such as:

    • ipconfig /all from RRAS server and from a locally connected client.
    • ipconfig /all from vpn client.
    • ipconfig /all from local client after the issue occurs.
    • route print from server/local client before and after issue occurs.

    MCTS - Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Here's IPCONFIG /ALL from the server when Routing and Remote Access is DISABLED:

     

       Host Name . . . . . . . . . . . . : TS2

       Primary Dns Suffix  . . . . . . . :

       Node Type . . . . . . . . . . . . : Unknown

       IP Routing Enabled. . . . . . . . : No

       WINS Proxy Enabled. . . . . . . . : No

     

    Ethernet adapter Local Area Connection 2:

     

       Connection-specific DNS Suffix  . :

       Description . . . . . . . . . . . : Broadcom BCM5716C NetXtreme II GigE (NDIS

     VBD Client) #2

       Physical Address. . . . . . . . . : 84-2B-2B-59-FB-02

       DHCP Enabled. . . . . . . . . . . : No

       Autoconfiguration Enabled . . . . : Yes

       Link-local IPv6 Address . . . . . : fe80::d556:702c:da61:8c5e%12(Preferred)

       IPv4 Address. . . . . . . . . . . : 192.168.2.239(Preferred)

       Subnet Mask . . . . . . . . . . . : 255.255.255.0

       Default Gateway . . . . . . . . . : 192.168.2.1

       DHCPv6 IAID . . . . . . . . . . . : 293874475

       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-3C-84-77-84-2B-2B-59-FB-01

     

       DNS Servers . . . . . . . . . . . : 8.8.8.8

       NetBIOS over Tcpip. . . . . . . . : Disabled

     

    Tunnel adapter Local Area Connection* 8:

     

       Media State . . . . . . . . . . . : Media disconnected

       Connection-specific DNS Suffix  . :

       Description . . . . . . . . . . . : isatap.{34463D6A-183B-4503-90E6-A5A651802

    D42}

       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

       DHCP Enabled. . . . . . . . . . . : No

       Autoconfiguration Enabled . . . . : Yes

     

    Tunnel adapter Local Area Connection* 9:

     

       Connection-specific DNS Suffix  . :

       Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface

       Physical Address. . . . . . . . . : 02-00-54-55-4E-01

       DHCP Enabled. . . . . . . . . . . : No

       Autoconfiguration Enabled . . . . : Yes

       IPv6 Address. . . . . . . . . . . : 2001:0:4137:9e76:1c5e:2bdc:3f57:fd10(Pref

    erred)

       Link-local IPv6 Address . . . . . : fe80::1c5e:2bdc:3f57:fd10%10(Preferred)

       Default Gateway . . . . . . . . . : ::

       NetBIOS over Tcpip. . . . . . . . : Disabled

    Here is again when Routing and Remote Access is ENABLED, a VPN connection is attempted, and the problem had surfaced:

     

    Windows IP Configuration

     

       Host Name . . . . . . . . . . . . : TS2

       Primary Dns Suffix  . . . . . . . :

       Node Type . . . . . . . . . . . . : Unknown

       IP Routing Enabled. . . . . . . . : Yes

       WINS Proxy Enabled. . . . . . . . : No

     

    Ethernet adapter Local Area Connection 2:

     

       Connection-specific DNS Suffix  . :

       Description . . . . . . . . . . . : Broadcom BCM5716C NetXtreme II GigE (NDIS

     VBD Client) #2

       Physical Address. . . . . . . . . : 84-2B-2B-59-FB-02

       DHCP Enabled. . . . . . . . . . . : No

       Autoconfiguration Enabled . . . . : Yes

       Link-local IPv6 Address . . . . . : fe80::d556:702c:da61:8c5e%12(Preferred)

       IPv4 Address. . . . . . . . . . . : 192.168.2.239(Preferred)

       Subnet Mask . . . . . . . . . . . : 255.255.255.0

       Default Gateway . . . . . . . . . : 192.168.2.1

       DHCPv6 IAID . . . . . . . . . . . : 293874475

       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-3C-84-77-84-2B-2B-59-FB-01

     

       DNS Servers . . . . . . . . . . . : 8.8.8.8

       NetBIOS over Tcpip. . . . . . . . : Disabled

     

    Tunnel adapter Local Area Connection* 8:

     

       Media State . . . . . . . . . . . : Media disconnected

       Connection-specific DNS Suffix  . :

       Description . . . . . . . . . . . : isatap.{34463D6A-183B-4503-90E6-A5A651802

    D42}

       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

       DHCP Enabled. . . . . . . . . . . : No

       Autoconfiguration Enabled . . . . : Yes

     

    Tunnel adapter Local Area Connection* 9:

     

       Connection-specific DNS Suffix  . :

       Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface

       Physical Address. . . . . . . . . : 02-00-54-55-4E-01

       DHCP Enabled. . . . . . . . . . . : No

       Autoconfiguration Enabled . . . . : Yes

       IPv6 Address. . . . . . . . . . . : 2001:0:4137:9e76:1c5e:2bdc:3f57:fd10(Pref

    erred)

       Link-local IPv6 Address . . . . . : fe80::1c5e:2bdc:3f57:fd10%10(Preferred)

       Default Gateway . . . . . . . . . : ::

       NetBIOS over Tcpip. . . . . . . . : Disabled

     

     

    Now here's the IPCONFIG /ALL from a computer on the LAN that is able to ping the server BEFORE Routing and Remote Access is enabled, but not afterwards:

     

    Windows IP Configuration

     

       Host Name . . . . . . . . . . . . : TS2

       Primary Dns Suffix  . . . . . . . :

       Node Type . . . . . . . . . . . . : Unknown

       IP Routing Enabled. . . . . . . . : Yes

       WINS Proxy Enabled. . . . . . . . : No

     

    Ethernet adapter Local Area Connection 2:

     

       Connection-specific DNS Suffix  . :

       Description . . . . . . . . . . . : Broadcom BCM5716C NetXtreme II GigE (NDIS

     VBD Client) #2

       Physical Address. . . . . . . . . : 84-2B-2B-59-FB-02

       DHCP Enabled. . . . . . . . . . . : No

       Autoconfiguration Enabled . . . . : Yes

       Link-local IPv6 Address . . . . . : fe80::d556:702c:da61:8c5e%12(Preferred)

       IPv4 Address. . . . . . . . . . . : 192.168.2.239(Preferred)

       Subnet Mask . . . . . . . . . . . : 255.255.255.0

       Default Gateway . . . . . . . . . : 192.168.2.1

       DHCPv6 IAID . . . . . . . . . . . : 293874475

       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-3C-84-77-84-2B-2B-59-FB-01

     

       DNS Servers . . . . . . . . . . . : 8.8.8.8

       NetBIOS over Tcpip. . . . . . . . : Disabled

     

    Tunnel adapter Local Area Connection* 8:

     

       Media State . . . . . . . . . . . : Media disconnected

       Connection-specific DNS Suffix  . :

       Description . . . . . . . . . . . : isatap.{34463D6A-183B-4503-90E6-A5A651802

    D42}

       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0

       DHCP Enabled. . . . . . . . . . . : No

       Autoconfiguration Enabled . . . . : Yes

     

    Tunnel adapter Local Area Connection* 9:

     

       Connection-specific DNS Suffix  . :

       Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface

       Physical Address. . . . . . . . . : 02-00-54-55-4E-01

       DHCP Enabled. . . . . . . . . . . : No

       Autoconfiguration Enabled . . . . : Yes

       IPv6 Address. . . . . . . . . . . : 2001:0:4137:9e76:1c5e:2bdc:3f57:fd10(Pref

    erred)

       Link-local IPv6 Address . . . . . : fe80::1c5e:2bdc:3f57:fd10%10(Preferred)

       Default Gateway . . . . . . . . . : ::

       NetBIOS over Tcpip. . . . . . . . : Disabled

     

    For ROUTE PRINT, see my previous reply.

    As previously noted, the VPN client is not relevant in this, because it doesn't even have to connect. Quite often the problem will rear its ugly head the moment Routing and Remote Access is enabled (not VPN connection is necessary), though not always.

    Thursday, December 29, 2011 6:14 PM
  •  

    I don't see any differences, but I might have missed something.

    As for Server 2000 vs Server 2003, the company ALREADY OWNS the license to Server 2000, which means there is no cost involved. If they have to switch to Server 2003 to run the RRAS server it would cost them a chunk of change to buy the license (assuming Microsoft still sells one for that version).

    I have considered paying the $259 to open a support issue with Microsoft. I kind of wish I'd done it earlier, because then it would have actually cost the company less to solve this problem that it appears to have cost them now. However, I never entered this thinking it would be such a difficult problem to solve.


    I'm not seeing any difference other than IP Routing being enabled, which is expected. However, I'm curious why the double 0.0.0.0 persistent route in the before and after tables. I think that may be causing it?

    If you look in RRAS console, expand IPv4, Static Routes, does an additional route show up?

    I just looked at a 2008 R2 installation route print with RRAS with a single NIC and it only shows one 0.0.0.0 route, which is the default route.

    Usually you can run a route delete 0.0.0.0 to remove a route, but since the two are identical, I'm not sure if it will take it.

    What do you see in the reg in this location? Do you see one or two entries? If two, remove one of them. Full pic can be seen at:
    https://public.blu.livefilestore.com/y1p1al1E5-uV8UzyrOL1c3CQxjAVmQjDZlFK0x2228v_zOpnsNhte5V-yvDqSm_0DGYuzNt47gg9oO9961MSBSYhw/Route%20default%200.0.0.0%20registry%20entry.jpg?psid=1


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn
    Thursday, December 29, 2011 6:42 PM
  • The ipconfig you provided for the client is the same as the server's. Please provide the info from the client before and after the issue.

    Also I am not certain about this (Ace plese correct me if I'm wrong) but I remember reading something like:

    "When both IPv4 and IPv6 are enabled, the Next Generation TCP/IP stack prefers the use of IPv6. For example, if a Domain Name System (DNS) Name Query Response message contains a list of both IPv6 and IPv4 addresses, the Next Generation TCP/IP stack will attempt to communicate over IPv6 first, subject to the address selection rules that are defined in RFC 3484. For more information, see Source and Destination Address Selection for IPv6, the February 2006 The Cable Guy article."

    Have you tried disableing the IPv6 stack on both server and client, at least for testing porpuses? Can you please try and tell me what happens?

     

    Thank you.


    MCTS - Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Thursday, December 29, 2011 7:02 PM
  • The ipconfig you provided for the client is the same as the server's. Please provide the info from the client before and after the issue.

    Also I am not certain about this (Ace plese correct me if I'm wrong) but I remember reading something like:

    "When both IPv4 and IPv6 are enabled, the Next Generation TCP/IP stack prefers the use of IPv6. For example, if a Domain Name System (DNS) Name Query Response message contains a list of both IPv6 and IPv4 addresses, the Next Generation TCP/IP stack will attempt to communicate over IPv6 first, subject to the address selection rules that are defined in RFC 3484. For more information, see Source and Destination Address Selection for IPv6, the February 2006 The Cable Guy article."

    Have you tried disableing the IPv6 stack on both server and client, at least for testing porpuses? Can you please try and tell me what happens?

     

    Thank you.


    MCTS - Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Oops! That was my mistake. I must have had something left over in the clipboard when I pasted that response. Here's what I should have pasted:

     

    Windows IP Configuration

            Host Name . . . . . . . . . . . . : SteveD630

            Primary Dns Suffix  . . . . . . . :

            Node Type . . . . . . . . . . . . : Hybrid

            IP Routing Enabled. . . . . . . . : No

            WINS Proxy Enabled. . . . . . . . : No

            DNS Suffix Search List. . . . . . : phub.net.cable.rogers.com

     

    Ethernet adapter LAN Connection:

     

            Connection-specific DNS Suffix  . : phub.net.cable.rogers.com

            Description . . . . . . . . . . . : Broadcom NetXtreme 57xx Gigabit Controller

            Physical Address. . . . . . . . . : 00-1C-23-22-6A-56

            Dhcp Enabled. . . . . . . . . . . : Yes

            Autoconfiguration Enabled . . . . : Yes

            IP Address. . . . . . . . . . . . : 192.168.2.103

            Subnet Mask . . . . . . . . . . . : 255.255.255.0

            Default Gateway . . . . . . . . . : 192.168.2.1

            DHCP Server . . . . . . . . . . . : 192.168.2.1

            DNS Servers . . . . . . . . . . . : 8.8.8.8

            Primary WINS Server . . . . . . . : 192.168.1.235

            Lease Obtained. . . . . . . . . . : January 3, 2012 10:34:26

            Lease Expires . . . . . . . . . . : January 4, 2012 10:34:26

     

    Tuesday, January 03, 2012 5:41 PM
  • I'm not seeing any difference other than IP Routing being enabled, which is expected. However, I'm curious why the double 0.0.0.0 persistent route in the before and after tables. I think that may be causing it?

    If you look in RRAS console, expand IPv4, Static Routes, does an additional route show up?

    I just looked at a 2008 R2 installation route print with RRAS with a single NIC and it only shows one 0.0.0.0 route, which is the default route.

    Usually you can run a route delete 0.0.0.0 to remove a route, but since the two are identical, I'm not sure if it will take it.

    What do you see in the reg in this location? Do you see one or two entries? If two, remove one of them. Full pic can be seen at:
    https://public.blu.livefilestore.com/y1p1al1E5-uV8UzyrOL1c3CQxjAVmQjDZlFK0x2228v_zOpnsNhte5V-yvDqSm_0DGYuzNt47gg9oO9961MSBSYhw/Route%20default%200.0.0.0%20registry%20entry.jpg?psid=1

    I only see one entry in that location of my registry (just as you showed in the supplied screen capture).
    Tuesday, January 03, 2012 5:46 PM
  • Curious, why are you using 8.8.8.8? Is this is an Active Directory infrastructure?

     


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn
    Tuesday, January 03, 2012 6:15 PM
  • From the suffix it is a "rogers phub". So that means it is not an active directory domain. Does the DNS from the ISP accept updates? I think not...but are they cached somehow?

    http://www.dslreports.com/faq/10758


    MCTS - Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Tuesday, January 03, 2012 6:22 PM
  • Good point, Marius. Either way,the issue comes back to duplicate default gateways, and the inability for an internal machine to connect to the server once a VPN connection is established.

    Sometimes the obvious doesn't materialize for us to figure out what is going on. Maybe a better suggestion is to contact Microsoft support to get this resolved. For a one time charge of USD $259.00 plus tax, they will take all the time in the world to remote in and fix it for you. Here's the link to get you started in case you choose the option:

    http://support.microsoft.com/common/international.aspx?RDPATH=dm;en-us;select&target=assistance

    Ace

     


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn
    Tuesday, January 03, 2012 6:42 PM
  • One more thought, how about disabling the "Use default gateway on remote network" setting on the VPN client connection? Does that allow you to connect to your server from other internal machines?

     


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn
    Thursday, January 05, 2012 5:49 AM
  • One more thought, how about disabling the "Use default gateway on remote network" setting on the VPN client connection? Does that allow you to connect to your server from other internal machines?

     


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn
    I thank you for the advice, but once again I must reiterate that this is NOT A CLIENT ISSUE. It's the server that messes up. As I noted, the issue sometimes rears its head when I activate Routing and Remote Access EVER BEFORE a single client even tries to connect. Subsequently we can discount ANY issues with the clients.
    Thursday, January 05, 2012 8:39 PM
  • From the suffix it is a "rogers phub". So that means it is not an active directory domain. Does the DNS from the ISP accept updates? I think not...but are they cached somehow?

    http://www.dslreports.com/faq/10758


    MCTS - Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    No, it isn't an Active Directory Domain. The DNS (if you didn't recognize it) belongs to Google. Besides, does this have anything to do with local computers pinging other local computer using dotted decimal addresses? As an experiment I setup a computer on the LAN with NO DNS. I couldn't resolve any names of course, but I could still ping by address, which seems to suggest that DNS is not used when an IP address is used.
    Thursday, January 05, 2012 8:42 PM
  • Curious, why are you using 8.8.8.8? Is this is an Active Directory infrastructure?

     


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn
    No, this isn't an Active Directory Domain. 8.8.8.8 is a DNS provided by Google, which can be used in lieu of any DNS servers provided your the ISP. I've tried using the DNS provided by the ISP, but it doesn't make any difference.
    Thursday, January 05, 2012 8:44 PM
  • Good point, Marius. Either way,the issue comes back to duplicate default gateways, and the inability for an internal machine to connect to the server once a VPN connection is established.

    Sometimes the obvious doesn't materialize for us to figure out what is going on. Maybe a better suggestion is to contact Microsoft support to get this resolved. For a one time charge of USD $259.00 plus tax, they will take all the time in the world to remote in and fix it for you. Here's the link to get you started in case you choose the option:

    http://support.microsoft.com/common/international.aspx?RDPATH=dm;en-us;select&target=assistance

    Ace

     


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn
    Thanks for the link. As I noted in a previous message I had given some thought to taking this route. It certainly looks like this may be my ONLY solution to this puzzle.
    Thursday, January 05, 2012 8:45 PM
  • Hello Steve,

    This is the first time I've heard about this rogers phub, but I will catch up on that eventually...

    So you say it is something with the RAS server. Now lets try to better isolate the problem.

    Is it related to the Operating system? I understand you reinstalled the role so that is excluded from start.

    Maybe you can deploy a hyperV VM, reinstall 2008r2 and reconfigure it following the step by step guides from MS. Have you tried wireshark to see what happens to traffic after the issue takes place?

    Is it related to the physical machine, maybe the NICs? Try replacing them temporarily. (we have to eliminate all possible poits of failure,right?)

    Is the replacement of the RAS server with a regular router for ec an Linksys/Cisco RV042 an viable option?

    The last option as Ace suggested, call Microsoft support and hopefully they may resolve the issue which I must say its a very strange one (but I am sure there is something we are missing). 

    I really hope you are not annoyed about the previous postings but please understand that I am doing my best help you.

     


    MCTS - Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Thursday, January 05, 2012 9:26 PM
  • I thank you for the advice, but once again I must reiterate that this is NOT A CLIENT ISSUE. It's the server that messes up. As I noted, the issue sometimes rears its head when I activate Routing and Remote Access EVER BEFORE a single client even tries to connect. Subsequently we can discount ANY issues with the clients.

    Steve,

    I realize that. The reason I suggested this is because if the client is using the remote gateway for internet access (by that checkbox being checked), it changes the routing table on the RRAS server, which may contributing or causing the issue. Here's someone that had the same problem, and his fix was disabling this setting on the client side:

    Lost Internet on computer after VPN is established
    http://forums.techarena.in/small-business-server/889332.htm

    It's something to test....

     

    Another thing to look at, are RRAS' IP Filters, making sure they are disabled.

    Routing Issues with VPN:
    http://www.chicagotech.net/routingissuesonvpn.htm

    Can't Ping External Network Adapter After Configuring RRAS as a VPN Server
    http://www.chicagotech.net/vpnasrouter.htm

     

    Also, here's something I found, below. Have you called Microsoft yet on this? If you have, I'm curious what they told you, because apparently you're not the only one having this problem.

    RRAS IP Filters in Windows 2008 R2
    http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/8d9aea6d-a00d-4cf4-94ef-2d8e9d7d7ab5/

    From the last link posted above:"
    I just got off the phone with MS. So here's the deal. Apparently, R2 closes all the external ports other than those related to the VPN, in my case PPTP, with RRAS running as I have it configured. Creating static port maps back to the internal interface "works" but has a very high rate of packet loss making it useless. These are known issues with R2 and they have no plans to fix it any time soon. They have no work-around for me and suggested I go back to R1 or get another server to run the other services and only run RRAS on that system."
    "No KB article was provided. He wasn't very forthcoming about any details at all. Just that there were changes made to RRAS in R2 and they have been getting calls about them causing problems. Unfortunately, not enough calls to warrant a fix and that I should switch back to R1 or separate the roles to different systems. With a lack of operating budget, we're going back to R1 with the same configuration."

    Ace


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn
    Thursday, January 05, 2012 10:29 PM