次の方法で共有


Routing and Remote Access: "a connection to the remote computer could not be established"

Eccoci tornati online, con un particolare appuntamento estivo della rubrica “problemi di rete impossibili”.

Questo problema con Routing and Remote Access appartiene decisamente alla categoria, seppur la soluzione è “facile” ma è stato necessario sudare le proverbiali sette camicie per scoprirlo.

Dunque l’obiettivo è stabilire una connessione VPN site to site tra due server RRAS.

Se dal server “sorgente” configuriamo la connessione come Demand-Dial, questa fallisce con un errore strano:
”A connection to the remote computer could not be established. You might need to change the network settings for this connection."

 

image

 

Mentre la connessione VPN funziona perfettamente (con letteralmente gli stessi settings!) se creiamo una nuova connessione VPN client dal pannello di controllo. Il tutto indipendentemente dal protocollo PPTP o L2TP.

 

image

Se abilitiamo il RAS tracing (comando netsh ras set tracing * enabled ) possiamo capire esattamente che cosa sta succedendo.

 

RASMAN log

[2904] 07-08 14:09:35:072: Disconnect request on port: VPN2-9
[1596] 07-08 14:09:35:072: SendProtocolResultToRasman: msgid=10
[1596] 07-08 14:09:35:072: PROTOCOL_RES_Stopped. dwError=0x2d0
[1596] 07-08 14:09:35:072: setting error to 720
[1596] 07-08 14:09:35:072: DwProcessProtocolFailureMessage: disconnecting

L’errore sollevato è il 720.

Seguendo la documentazione ufficiale (http://support.microsoft.com/kb/923944/EN-US) capiamo che

720 = No PPP control protocols configured.

Questo ci indica evidentemente un problema con il PPP. Andando a verificare il log del PPP (che è sempre catturato dal RAS tracing) vediamo:

PPP log

[1596] 07-08 14:09:35:072: NotifyCaller(hPort=246, dwMsgId=3)
[1596] 07-08 14:09:35:072: FsmInit called for protocol = 8057, port = 246
[1596] 07-08 14:09:35:072: FsmInit for protocol = 8057 Configuration 0x982020a
[1596] 07-08 14:09:35:072: FsmInit for protocol = 8057 failed with error 717

PPP fallisce con 717 = No IP addresses are available in the static pool of Remote Access IP addresses

 

Questo problema si verifica indipendentemente dalla corretta configurazione dei Remote Access IP, ma dipende dal fatto che le due interfacce tra i due RRAS si devono configurare a vicenda.

 

La soluzione del problema prevede quindi che siano effettuate le tre seguenti configurazioni:

1) In fase di setup dell’interfaccia Demand-Dial DEVE essere configurato il checkbox per “Route IP packets on this interface” anche se non ci interesserà effettuare routing per subnet specifiche. In questo caso, ci basterà lasciare vuoto il campo “static routes” nella schermata successiva.

image

 

2) Anche all’altro capo della connessione, quindi sul server RRAS “destinazione”, deve essere configurata una interfaccia Demand-Dial gemella in direzione opposta!
Ciò non è invece necessario per la connessione “VPN client” che possiamo creare dal pannello di controllo, che abbiamo quindi visto funzionare indipendentemente.

3) Importantissimo
L’utenza che andiamo a configurare per la connessione Demand-Dial deve avere lo stesso esatto nome della connessione stessa!!

Questo è un requirement di RRAS:

The user account must exactly match the name of the corresponding demand-dial interface
http://technet.microsoft.com/en-us/library/ff687745(v=WS.10).aspx

Questa è la causa principale di tutti i problemi. Provare per credere!  
   
Nota finale: visto che siamo nel 2014 e il nostro Azure cloud sta ormai prendendo piede in larga scala, rispondo già alla domanda che a molti sarà venuta in mente.

NO, non è possibile configurare una VPN site-to-site tra il nostro RRAS e Azure in questo modo Sorriso (aggiornamento a luglio 2014)

Per la Site to Site VPN su Azure facciamo riferimento alla documentazione ufficiale MSDN

http://msdn.microsoft.com/en-us/library/azure/dn133795.aspx

Grazie a tutti e alla prossima!

Stefano Gagliardi
Sr. Support Engineer
Microsoft Enterprise Platform Support

Comments

  • Anonymous
    January 01, 2003
    thanks for sharing.