none
Can't reach server thru VPN

    Question

  • Problem with VPN access to server. Something I've got wrong here and don't know what. 
    * Server 2012 up to date. It's in the main office.
    * Main office ip 192.168.5.0/24.
    * Main office dns & dhcp by server
    * Branch office ip .10.0/24
    * Branch office dns & dhcp by router
    * ipsec vpn between routers connects
    Problem: From Branch I can reach Main workstations and printers by ip so I know vpn and address issues are not the problem. But when I try to reach the server it can't see it. Can't ping, see shares, reach its web page, or use RDP. I'm trying to reach the server by ip too, not by name. From Main stations to server I can do all of those. Tried test turning off server firewall, no difference. Tried a test opening RDP port to server and could access it from a Branch workstation using RDP to Main outside ip, so that works. Just not through the VPN using the server's lan ip.

    Looked at a bunch of similar posts here but each seem a little different case.

    What dumb thing am I missing? Thanks.


    Tuesday, November 07, 2017 5:23 PM

Answers

  • The firewall on server may be blocking ICMPv4 Also you mentioned Main office ip 192.168.5.0/24, but appears to be /16 according to mask used.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    • Marked as answer by Njem Monday, November 13, 2017 8:47 PM
    Wednesday, November 08, 2017 8:12 PM

All replies

  • Installing RRAS / VPN role on a domain controller causes no end to confusion for active directory / DNS, better option to install VPN on a member server.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Tuesday, November 07, 2017 5:34 PM
  • Thanks but VPN is not installed on server. VPN is router to router. Which makes my problem all the more confusing, because as noted, I can get to Main workstations from Branch but not to server.
    Tuesday, November 07, 2017 6:35 PM
  • Ok, after connecting VPN I'd do an ipconfig /all and confirm you're getting the correct gateway and dns server assigned to VPN connection.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Tuesday, November 07, 2017 7:00 PM
  • There is no assignment for vpn. For stations on the Branch side they just get their lan ip and dns & gateway from the router. They have no additional assignment for VPN persona. In past router to router vpns that has not been needed, and is true in this case too since I can get to workstations and printers across the vpn by ip. The ONLY thing I can't get to is the server.

    Tuesday, November 07, 2017 8:01 PM
  • Please run;

    ipconfig /all >C:\dc.txt

    ipconfig /all >C:\client.txt

    ipconfig /all >C:\server.txt

    then put three files up on OneDrive and share a link here.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.



    Tuesday, November 07, 2017 8:02 PM
  • All the Main systems are busy but here is the ipconfig for server (and dc, there is only one) and for a workstation on the Branch side.

    =======Server==============

    Windows IP Configuration

       Host Name . . . . . . . . . . . . : server17
       Primary Dns Suffix  . . . . . . . : Bennett.local
       Node Type . . . . . . . . . . . . : Hybrid
       IP Routing Enabled. . . . . . . . : No
       WINS Proxy Enabled. . . . . . . . : No
       DNS Suffix Search List. . . . . . : Bennett.local

    Ethernet adapter NIC2:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : 
       Description . . . . . . . . . . . : Broadcom NetXtreme Gigabit Ethernet #2
       Physical Address. . . . . . . . . : 50-9A-4C-61-0E-3B
       DHCP Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes

    Ethernet adapter NIC1:

       Connection-specific DNS Suffix  . : 
       Description . . . . . . . . . . . : Broadcom NetXtreme Gigabit Ethernet
       Physical Address. . . . . . . . . : 50-9A-4C-61-0E-3A
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv4 Address. . . . . . . . . . . : 192.168.5.2(Preferred) 
       Subnet Mask . . . . . . . . . . . : 255.255.0.0
       Default Gateway . . . . . . . . . : 192.168.5.1
       DNS Servers . . . . . . . . . . . : 127.0.0.1
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Tunnel adapter isatap.{18D9D1AE-1EEA-4AA1-92F5-9D67BE80C720}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : 
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter isatap.{146ADB8B-1936-4B29-ADD9-BFFA287C152A}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : 
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    =========Branch Workstation===============


    Windows IP Configuration

       Host Name . . . . . . . . . . . . : TC14
       Primary Dns Suffix  . . . . . . . : 
       Node Type . . . . . . . . . . . . : Hybrid
       IP Routing Enabled. . . . . . . . : No
       WINS Proxy Enabled. . . . . . . . : No
       DNS Suffix Search List. . . . . . : DLink

    Ethernet adapter Local Area Connection 3:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : 
       Description . . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection
       Physical Address. . . . . . . . . : 5C-26-0A-55-BA-2F
       DHCP Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes

    Wireless LAN adapter Wireless Network Connection 5:

       Connection-specific DNS Suffix  . : DLink
       Description . . . . . . . . . . . : Intel(R) Centrino(R) Ultimate-N 6300 AGN
       Physical Address. . . . . . . . . : 00-24-D7-B2-82-54
       DHCP Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes
       IPv4 Address. . . . . . . . . . . : 192.168.10.110(Preferred) 
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Lease Obtained. . . . . . . . . . : Tuesday, November 07, 2017 13:57:30
       Lease Expires . . . . . . . . . . : Wednesday, November 08, 2017 13:57:29
       Default Gateway . . . . . . . . . : 192.168.10.1
       DHCP Server . . . . . . . . . . . : 192.168.10.1
       DNS Servers . . . . . . . . . . . : 192.168.10.1
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Tunnel adapter isatap.Home:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : 
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter isatap.{47DE6588-97CA-481F-801D-29D3B095A2B0}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : 
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter Reusable ISATAP Interface {247C734E-8291-490C-8669-A37A18EBF9EC}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : 
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter #3
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter Local Area Connection* 11:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : 
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter #4
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter Reusable ISATAP Interface {E61C3398-A6F3-4851-9FC4-39316D977C28}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : 
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter #5
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter Teredo Tunneling Pseudo-Interface:

       Connection-specific DNS Suffix  . : 
       Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv6 Address. . . . . . . . . . . : 2001:0:5cf2:8c44:3427:13a9:3f57:f591(Preferred) 
       Link-local IPv6 Address . . . . . : fe80::3427:13a9:3f57:f591%12(Preferred) 
       Default Gateway . . . . . . . . . : ::
       NetBIOS over Tcpip. . . . . . . . : Disabled

    Tunnel adapter isatap.DLink:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : DLink
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter #6
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tunnel adapter isatap.{3CF6E877-C2E1-408D-8A38-C34C0B3253D2}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . : 
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter #7
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

    Tuesday, November 07, 2017 9:05 PM
  • DC should also have own address (192.168.5.2) listed for DNS. All domain members / clients should have the static address of DC listed for DNS and no others such as router or public DNS

     

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Tuesday, November 07, 2017 9:09 PM
  • That's true on the Main office side. Everything points to DC/server, including the server itself. For the Branch office systems they all get dns from router so they point to it. (They're not on the domain.) That's probably okay because nothing on the Main side needs to access anything on the Branch side. The vpn is strictly for Branch stations to reach the server (the one thing it won't do).
    Tuesday, November 07, 2017 9:34 PM
  • vpn is strictly for Branch stations to reach the server (the one thing it won't do).

    Assuming firewalls will allow; I'd try to tracert the problematic ip address to see where you lose it.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.


    Tuesday, November 07, 2017 9:55 PM
  • Here's tracert from a Branch workstation to a Main printer (.99) and to the server (.2). Pinging the server from other stations within the Main office works so the server does respond to ping. It seems to lose it after the router ("DSR" .10.1) but going to the printer it completes, to the server, not. The router of course should know where to route since it's the routers that have the vpn established, and indeed that works pinging the printer. 

    I have very similar arrangements in other places which work. You can see why this one has me confused. Thanks for your help.

    ===to a printer===
    Tracing route to 192.168.5.99 over a maximum of 30 hops

      1    <1 ms    <1 ms    <1 ms  DSR-250 [192.168.10.1]
      2     *        *        *     Request timed out.
      3    44 ms    49 ms    39 ms  192.168.5.99

    Trace complete.

    ===to the server===

    Tracing route to 192.168.5.2 over a maximum of 3 hops

      1    <1 ms    <1 ms    <1 ms  DSR-250 [192.168.10.1]
      2     *        *        *     Request timed out.
      3     *        *        *     Request timed out.

    Trace complete.


    • Edited by Njem Wednesday, November 08, 2017 7:41 PM
    Wednesday, November 08, 2017 7:40 PM
  • The firewall on server may be blocking ICMPv4 Also you mentioned Main office ip 192.168.5.0/24, but appears to be /16 according to mask used.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    • Marked as answer by Njem Monday, November 13, 2017 8:47 PM
    Wednesday, November 08, 2017 8:12 PM
  • You're right about the mask because at one point as a debug test I opened the mask wider on one or both ends. Need to put that back.

    Shouldn't be a firewall issue since I tested turning it off at one point. That is the firewall in the server.

    Another option I was hoping to not have to do because I need to interrupt people's work, is to put both sides on the same IP range, then tell the router vpn to use a split tunnel which, as I understand it, would know that for instance Branch side would use 5.10-5.99 and Main side would use 5.100-5.199. Does that make any sense to you as being any help? Like I say, my set up as is has worked elsehwere.


    • Edited by Njem Wednesday, November 08, 2017 10:07 PM
    Wednesday, November 08, 2017 9:42 PM
  • tracert in other direction?

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Wednesday, November 08, 2017 10:41 PM
  • Tracert from Main server to Branch router gets out to the ISP then fails.

    traceroute to 192.168.10.1 (192.168.10.1), 10 hops max, 40 byte packets
     1  159-118-232-217.cpe.cableone.net (159.118.232.217)  2.121 ms  3.593 ms  4.173 ms
     2  * * *


    Tracert from Main server to a station in Branch office says unreachable.

    Tracing route to 192.168.10.25 over a maximum of 30 hops

      1  server17.Bennett.local [192.168.5.2]  reports: Destination host unreachable.


    Both routers are fetching a fixed IP from modems that are in bridged mode. Both go to ISP Cableone which I use all the time and they don't block things.

    I would wonder if communication back out of Main to Branch was failing but as noted I can get to the web page of a printer in Main from Branch. Just not to server.

    The Main router can ping from its diagnostic page to both the server and the printer, so router-to-inside items works.

    Thursday, November 09, 2017 3:24 AM
  • I'd try to get in touch with who ever setup the routing for help.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Thursday, November 09, 2017 3:26 AM
  • That would be me. I have emailed the manufacturer for ideas. Problem is I've gotten the exact same results from two sets of routers that are of two different brands. VPN connects, some signs of function like reaching the printer. Only thing that won't respond is the server. 
    Thursday, November 09, 2017 4:26 PM
  • That would be me. I have emailed the manufacturer for ideas. 

    Might also ask in manufacturer forums for help.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Thursday, November 09, 2017 4:28 PM
  • Is there any policy or other way the server can know the access is coming from outside its lan range and so reject all contact? Actually I guess I don't know what IP the server sees these requests coming from. The Branch workstation IP? Or if the router translates that into a local IP. But then the server responds to RDP requests from the internet if I open that port. As noted, turning off the server firewall doesn't change it. So it's something else. There's got to be some reason the server is the only system in Main that refuses to be accessed from Branch.
    Friday, November 10, 2017 5:10 PM
  •  some reason the server is the only system in Main that refuses to be accessed from Branch.

    Did you also try to RDP?

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Friday, November 10, 2017 5:14 PM
  • Ping, accessing shares, RDP, and the server web page are all accessible by stations in Main but not from Branch. The server can be reached by RDP from outside, internet locations if I forward that port.
    Friday, November 10, 2017 9:34 PM
  • all accessible by stations in Main but not from Branch.

    That's what I was asking. It's either a blocking or routing issue.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Friday, November 10, 2017 9:37 PM
  • Right, but only a problem to the server. Nothing blocking or failing to route Branch access to other Main stations. 

    In the past there was Network Access Protection which would block access by systems that weren't deemed acceptable. That's not on by default in server 2012 r2, and I've checked that the service is not running. But is there anything similar, any policy or whatever, that the server would not respond to ping or anything else if the source doesn't meet some criteria? Which maybe across the VPN it can't verify some criteria? Or maybe that if the source is from some other lan range it won't respond?

    Friday, November 10, 2017 11:21 PM
  • maybe that if the source is from some other lan range it won't respond?

    You may be able to do that via the firewall. If the server has a single interface on LAN then it would not know source was from "outside" From what you've described the hardware is doing the NAT

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Friday, November 10, 2017 11:28 PM
  • I used a packet sniffer to see if the requests were even getting to the server. They are. A ping from 192.168.10.102, but no packets back to that address at all. Same thing if I try rdp or web access. So server is getting it but just #&$*ing refuses to respond. Gotta be some setting that tells it not to. 

    I'm working on it now from a remote site by forwarding rdp port and using rdp to manage it, so it will respond to outside requests, but not from Branch via vpn.

    Friday, November 10, 2017 11:47 PM
  • so it will respond to outside requests, but not from Branch via vpn.

    If server is listening and responding to RDP (3389) on the single network interface then it would not matter where it is coming from. Sounds like you have already verified this by RDPing via internet to server. Sounds like the VPN routing is wrong. Beyond that I couldn't say. I'd suggest bringing someone in knowledgeable with the hardware.

     

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Saturday, November 11, 2017 12:08 AM
  • Yea! Finally got it. 5 oclock friday. One part hardware problem, two parts me. The original routers wouldn't do it, which is what got me started trying things. One thing I tried was widening the mask to 255.255.0.0. A later change was to go to two different routers of a different brand. Those work. You pointed out the mask not being as expected. In my going between many screens I went back to the router page to check the mask and it was fine. But that's not where the mask was wrong. It was wrong in the server. Changed that and it works. Thanks for your help.

    Saturday, November 11, 2017 12:11 AM
  • It was wrong in the server. 

    Yes, that's what i saw from the ipconfig /all output you provided.

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Saturday, November 11, 2017 12:14 AM
  • A follow up question. Actually I don't understand why that fixed it. Yes, the mask for the server's nic was not what it should be (when it was 255.255.0.0) and it didn't agree with the mask used in the routers or that the stations got from dhcp. Bad form and a definite error, but don't see how it should stop the server from responding. The server is at .5.2. The stations across the vpn I was trying to access it from are at .10.x. I would think to the server, with that 16-bit mask, .10.x would just look like another point on the lan in its range. As noted, the server was receiving the packets with requests from stations across the vpn but didn't respond to them. Put it's mask back to 24-bit and it responds. Doesn't make sense to me.
    Monday, November 13, 2017 8:46 PM
  • Read through the troubleshooting section here.

    https://support.microsoft.com/en-us/help/164015/understanding-tcp-ip-addressing-and-subnetting-basics

     

     



    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows Server] Datacenter Management

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights.

    Monday, November 13, 2017 9:03 PM
  • Thanks. Restates the common information on network ranges. Still leaves me wondering why the server would care and not respond to .10.x address when they are within its mask vs when they are outside its mask. Apparently something deep in the code of Windows Server that may have no clear explanation.
    Tuesday, November 14, 2017 2:11 AM