2

We have the following configuration in place:

--LAN SIDE

Local Clients #N

Local Server A (DC + RRAS)

Local Server B (DC + RRAS)

Local Servers C...Z

---ROUTER/FIREWALL

--PUBLIC SIDE

Foreign Clients 1,2..,#N


Server A & B are both up to date (Aug '17) Windows Server 2016 Standard.

We have this issue on both Servers, so we're gonna take Server A as example for simplicity.

** RRAS configuration **:

Server A has just one nick, and it's configured as follows:

1Physical NIC

Ethernet IF: 192.168.12.41/255.255.255.0

Alias IF: 192.168.12.38/255.255.255.255 (This has been created by the RRAS server)

RRAS server (both PPTP and SSTP)'s ports are forwarded from their public IP to the Ethernet IF's IP by the router

Foreign Client's configuration:

local and foreign clients are all Windows 7 to Windows 10 professional, there are no further relevant informations but the provided ipconfig/nmap's output:

Issue representation

Foreign Clients can succesfully connect to the LAN through Server A's RRAS. But when they do, at the networking level, they can connect to anything BUT Server A. The problem was firstly noticed when one connected to Server A wasn't able to RDP to Server A. Then, we found that no services are rechable on Server A, but you can connect to any client and Servers B to Z.

If the connection is made the other way around (Foreign Client connects to Server B's RRAS) it will connect to anything in the LAN BUT Server B.

Both UDP and TCP ports are not reachable through the connected RRAS:

That's an nslookup from Foreign Client to Server A and B while connected to Server A:

c:\Users\user>nslookup site.customer.com 192.168.12.41
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  192.168.12.41

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Tempo scaduto per la richiesta a UnKnown

c:\Users\user>nslookup site.customer.com 192.168.12.42
Server:  moon.site.customer.com
Address:  192.168.12.42

Nome:    site.customer.com
Addresses:  192.168.12.41
          192.168.12.42

That's an ipconfig /all of Foreign Client after successful connection to Server A:

c:\Users\user>ipconfig /all
...
Scheda PPP CUSTOMER:

   Suffisso DNS specifico per connessione: site.customer.com
   Descrizione . . . . . . . . . . . . . : CUSTOMER
   Indirizzo fisico. . . . . . . . . . . :
   DHCP abilitato. . . . . . . . . . . . : No
   Configurazione automatica abilitata   : Sì
   Indirizzo IPv4. . . . . . . . . . . . : 192.168.12.143(Preferenziale)
   Subnet mask . . . . . . . . . . . . . : 255.255.255.255
   Gateway predefinito . . . . . . . . . :
   Server DNS . . . . . . . . . . . . .  : 192.168.12.42
                                           192.168.12.41
   NetBIOS su TCP/IP . . . . . . . . . . : Disattivato
...

That's a tracert to the ServerA.

c:\Users\user>tracert -w 100 sun.site.customer.com

Traccia instradamento verso sun.site.customer.com [192.168.12.41]
su un massimo di 30 punti di passaggio:

  1    16 ms     *       14 ms  192.168.12.38
  2    15 ms    15 ms    14 ms  192.168.12.41

Traccia completata.

That's tracert to the ServerB.

c:\Users\user>tracert -w 100 moon.site.customer.com

Traccia instradamento verso moon.site.customer.com [192.168.12.42]
su un massimo di 30 punti di passaggio:

  1     *       29 ms    26 ms  192.168.12.38
  2    23 ms    29 ms    31 ms  192.168.12.42

Traccia completata.

Nmap Server B:

c:\Users\user>nmap --unprivileged -P0 -F 192.168.12.42
Starting Nmap 7.60 ( https://nmap.org ) at 2017-08-29 17:54 ora legale Europa occidentale
Nmap scan report for moon.site.customer.com (192.168.12.42)
Host is up (1.1s latency).
Not shown: 89 closed ports
PORT     STATE SERVICE
53/tcp   open  domain
80/tcp   open  http
88/tcp   open  kerberos-sec
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
389/tcp  open  ldap
443/tcp  open  https
445/tcp  open  microsoft-ds
1433/tcp open  ms-sql-s
1723/tcp open  pptp
3389/tcp open  ms-wbt-server

Nmap done: 1 IP address (1 host up) scanned in 32.27 seconds

Nmap Server A:

c:\Users\user>nmap --unprivileged -e ppp0 -P0 -F 192.168.12.41
Starting Nmap 7.60 ( https://nmap.org ) at 2017-08-29 17:56 ora legale Europa occidentale
Nmap scan report for sun.site.customer.com (192.168.12.41)
Host is up.
All 100 scanned ports on sun.site.customer.com (192.168.12.41) are filtered

Nmap done: 1 IP address (1 host up) scanned in 46.63 seconds

As you can see name resolution is working fine, but tcp/udp connections to Server A will fail if connected to Server A's RRAS or will fail to Server B if connected to Server B's RRAS.

No RRAS nor any other service's on the Servers or Foreign clients shows anything relevant, and I think it's normal as we have a problem at the networking level here.

We actually found that for Foreign Clients, the second autocreated Internal IP of the RRAS has Server's A services published and reachable:

c:\Users\user>nmap --unprivileged -P0 -F 192.168.12.38
Starting Nmap 7.60 ( https://nmap.org ) at 2017-08-29 18:26 ora legale Europa occidentale
Nmap scan report for 192.168.12.38
Host is up (0.19s latency).
Not shown: 90 filtered ports
PORT     STATE SERVICE
21/tcp   open  ftp
80/tcp   open  http
88/tcp   open  kerberos-sec
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
389/tcp  open  ldap
443/tcp  open  https
445/tcp  open  microsoft-ds
1723/tcp open  pptp
3389/tcp open  ms-wbt-server

Nmap done: 1 IP address (1 host up) scanned in 38.33 seconds

Question: what can be done in order to diagnose and prevent this symptom?


Edit 1 in reply of @Mr.Raspberry request

route print executed on ServerA

192.168.12.128 and 192.168.12.79 are currently connected RRAS clients

C:\Users\Vincenzo>route print
===========================================================================
Elenco interfacce
 14...00 50 56 ac 63 1a ......vmxnet3 Ethernet Adapter
 30...........................RAS (Dial In) Interface
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 16...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
===========================================================================

IPv4 Tabella route
===========================================================================
Route attive:
     Indirizzo rete             Mask          Gateway     Interfaccia Metrica
          0.0.0.0          0.0.0.0     192.168.12.39    192.168.12.41    271
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      192.168.12.0    255.255.255.0         On-link     192.168.12.41    271
     192.168.12.79  255.255.255.255     192.168.12.79    192.168.12.38     42
    192.168.12.128  255.255.255.255    192.168.12.128    192.168.12.38     42
    192.168.12.38  255.255.255.255         On-link     192.168.12.38    297
    192.168.12.41  255.255.255.255         On-link     192.168.12.41    271
    192.168.12.255  255.255.255.255         On-link     192.168.12.41    271
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link     192.168.12.41    271
        224.0.0.0        240.0.0.0         On-link     192.168.12.38    297
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link     192.168.12.41    271
  255.255.255.255  255.255.255.255         On-link     192.168.12.38    297
===========================================================================
Route permanenti:
   Indirizzo rete             Mask   Indir. gateway Metrica
          0.0.0.0          0.0.0.0     192.168.12.39  Predefinito
===========================================================================
Deep Space
  • 43
  • 6
  • I've made some tests, it seems to be Microsoft RRAS common behavior. – Marco Sep 01 '17 at 13:50
  • Vincenzo is a friend of mine, I wasn't able to provide a solution for him. We both know that at least three best practices are violated here and that this is probably MS RRAS expected behavior, anyway we're stuck at the customer's request, they only have two Win Srv and they have to be both DC and RRAS. The only plausible solution here might be providing a second network card to both servers and configure a DMZ vlan to publish services. Maybe this would fix but as this would be a very expensive solution for us we are asking for other's experience about that before going on with such test. – Marco Sep 19 '17 at 13:25
  • Could you please share `route print` command output executed on Server A? – Mr. Raspberry Sep 19 '17 at 14:07
  • @Mr.Raspberry I've just edited the question adding the requested details. – Deep Space Sep 19 '17 at 17:26
  • Have you tried to disable any firewall services on Server A and B? – Mr Zach Sep 25 '17 at 13:25
  • Of course firewall already disabled – Marco Sep 25 '17 at 15:14

0 Answers0