none
Client Remoti con Active Directory connessi con IPSEC VPN RRS feed

  • Domanda

  • Salve,

    devo sostituire la VPN OpenVPN Bridged tra due sedi con quella IPSEC utilizzando due firewall Fortigate (80C, 100A).

    Nella sede centrale abbiamo un AD Windows Server 2003 (a breve cercherò di passare a quella Win 2K8 R2) e nella sede remota solo dei client Windows, alcuni joinati con AD, altri no. Con OpenVPN funziona tutto benissimo, se non per un  problema di performance dato dalle appliances virtuali utilizzati (Endian Firewall 2.1.2), non ottimizzate per XenServer 6.

    Non sono molto esperto in VPN IPSec, ma so che crea non pochi problemi a sharing CIFS/SMB e connessioni con AD. Per questo motivo un bel pò di anni fa decisi di adottare anche con OpenVPN un'interfaccia virtuale TAP (bridged) a discapito di quella TUN (Routed).

    In particolare, con fortigate ho la possibilità di creare due tipi di VPN IPSec: Policy Based, Route Based.

    La prima supporta L2TP-over-IPsec, mentre invece la seconda GRE-over-IPsec.

    Potete darmi qualche consiglio su che tipologia è meglio utilizzare?

    Grazie 1K

    mercoledì 17 luglio 2013 10:45

Risposte

Tutte le risposte

  • Ciao io utilizzando i fortinet ho sempre utilizzato L2tp-over-IPSEC ed ho collegato una sede centrale ad un remote office tramite  isp fastweb ovviamente con ip pubblici totalmente nattati.

    Saluti

    mercoledì 17 luglio 2013 13:18
  • Si, nel tuo caso è meglio implementare una VPN bridged (ovvero che non utilizza un NAT) in modo da non avere problemi di port forwarding, ecc... Con i tuoi firewall dovresti quindi adottare una VPN policy-based poichè le VPN route-based (come dice il nome stesso) supportano solo modalità con NAT. Con i tuoi apparati la modalità bridged si dovrebbe chiamare "Transparent Mode".

    Trovi ulteriori informazioni sulla scelta tra le due qui:

    http://docs.fortinet.com/fgt/archives/3.0/techdocs/FortiGate_IPSec_VPN_User_Guide_01-30005-0065-20081015.pdf (pagina 16)

    Qui trovi invece delle informazioni generiche sui protocolli utilizzati per le VPN:

    http://www.cisco.com/en/US/tech/tk583/tk372/technologies_tech_note09186a00800946ba.shtml

    mercoledì 17 luglio 2013 14:03
    Moderatore
  • Ciao io utilizzando i fortinet ho sempre utilizzato L2tp-over-IPSEC ed ho collegato una sede centrale ad un remote office tramite  isp fastweb ovviamente con ip pubblici totalmente nattati.

    Saluti


    Ma tra le sedi funzionano protocolli come CIFS/SMB, auth AD, et simila del mondo Windows???
    mercoledì 17 luglio 2013 15:30
  • Si, nel tuo caso è meglio implementare una VPN bridged (ovvero che non utilizza un NAT) in modo da non avere problemi di port forwarding, ecc... Con i tuoi firewall dovresti quindi adottare una VPN policy-based poichè le VPN route-based (come dice il nome stesso) supportano solo modalità con NAT. Con i tuoi apparati la modalità bridged si dovrebbe chiamare "Transparent Mode".

    Trovi ulteriori informazioni sulla scelta tra le due qui:

    http://docs.fortinet.com/fgt/archives/3.0/techdocs/FortiGate_IPSec_VPN_User_Guide_01-30005-0065-20081015.pdf (pagina 16)

    Qui trovi invece delle informazioni generiche sui protocolli utilizzati per le VPN:

    http://www.cisco.com/en/US/tech/tk583/tk372/technologies_tech_note09186a00800946ba.shtml

    I due firewall farenno da Nattatori (non so se ho detto bene).

    Al momento sono riuscito a fare una routed based e proverò a far parlare i client da una parte all'altra con i vari protocolli CIFS/SMB su AD.

    Se la cosa non dovesse funzionare diciamo che ho in serbo un piano B: fare due vpn server su xen basati su distribuzioni standard, quindi pienamente virtualizzabili su XEN e nattarle con i due fortigate, in modo da dare più performance almeno sul traffico non VPN.

    mercoledì 17 luglio 2013 15:35
  • Forse non mi ero spiegato bene nel mio messaggio precedente. Con una VPN routed ti complichi molto la vita perché di norma le comunicazioni passano tutte attraverso un NAT, quindi teoricamente dai client dell'altra sede i sistemi presenti nella sede centrale risulteranno "mascherati". Puoi sempre tentare di configurare active directory per l'utilizzo di una porta statica e poi eseguire il forward ma a mio parere non vale la pena e rischi solo di avere problemi.

    Forse questa pagina potrà fare maggiore chiarezza: http://technet.microsoft.com/it-it/library/dd772723(v=ws.10).aspx

    Quindi a mio parere dovresti implementare semplicemente una VPN in "Transparent Mode" in modo da non avere problemi di questo tipo.


    mercoledì 17 luglio 2013 15:50
    Moderatore
  • Forse non mi ero spiegato bene nel mio messaggio precedente. Con una VPN routed ti complichi molto la vita perché di norma le comunicazioni passano tutte attraverso un NAT, quindi teoricamente dai client dell'altra sede i sistemi presenti nella sede centrale risulteranno "mascherati". Puoi sempre tentare di configurare active directory per l'utilizzo di una porta statica e poi eseguire il forward ma a mio parere non vale la pena e rischi solo di avere problemi.

    Forse questa pagina potrà fare maggiore chiarezza: http://technet.microsoft.com/it-it/library/dd772723(v=ws.10).aspx

    Quindi a mio parere dovresti implementare semplicemente una VPN in "Transparent Mode" in modo da non avere problemi di questo tipo.


    Allora, vorrei spiegarmi meglio, perchè forse questi termini li st confondendo tra quelli usuali e quelli dei Fortigate.

    Attualmente la mia configurazione è questa:

    Sede 1

    [ADS, PCs, Devices, Servers]  <-- (nat) 192.168.2.0/24 (lan) --> FG1 (IP PUB) <-- (route) --> Router

     <-- x.y.2.58 (lan) --> [Endian Firewall OpenVPN Server] <-- (nat) x.y.4.10 (dmz) --> FG1 (IP PUB)  

    Sede 2

    [PCs, Devices] -- (nat) x.y.0.0/24 --> [Endian Firewall, OpenVPN Client] <-- (nat, pnat) x.y.4.10 --> Router

    Tra sede 1 e sede 2 c'è una VPN bridged, ma tra subnet diverse (192.168.2.0/24 e 192.168.0.0/24). Infatti ho dovuto fare sui due Endian delle route statiche verso le subnet. Però gli share, ad1 mi sembra che abbiano sempre funzionato cmq. Diciamo che è impossibile joinare dalla rete '0' sull'AD della rete '2'.

    La situazione che voglio realizzare è la seguente:

    Sede 1

    [ADS, PCs, Devices, Servers]  <-- (nat) 192.168.2.0/24 --> FG1 (IP PUB) IPSec VPN <-- (route) --> Router

    Sede 2

    [PCs, Devices]  <-- (nat) 192.168.0.0/24 --> FG2 (IP PUB) IPSec VPN <-- (route) --> Router

    FG1 e FG2 non sono e non potranno essere in Transparent Mode per tante ragioni più organizzative che tecniche: su FG1 si appoggiano le comunicazioni di tutta la sede principale e quindi non può essere toccato.

    Il natting, credo che avviene solo dalle lan verso l'esterno, infatti nelle policy per far vedere le due lan nel tunnel non ho dovuto scegliere l'opzione di nat. Le due reti si vedono attraverso due semplici static route sugli FG. Il ping funziona.

    La mia domanda era, visto che nella configurazione IPSEC degli FG sono supportati sia L2TP che GRE, quale mi sarebbe convenuto scegliere per agevolare il traffico generlamente windows.

    In effetti preferisco che tutto il traffico passi liberamente tra le due reti anzichè scegliere granularmente le singole policy, però in ambito windows non so se è cosa buona o no.


    mercoledì 17 luglio 2013 23:21
  • Ora credo di aver capito meglio la tua situazione, comunque in realtà per Windows è indifferente se utilizzi un tunnel L2TP oppure un GRE all'interno della connessione IPSec, ovvero non è quello che può causarti problemi nelle comunicazioni (entrambi sono in grado di incapsulare quel tipo di traffico). In ogni caso solitamente si tende a preferire L2TP over IPSec.

    La cosa a cui devi prestare attenzione è invece il routing tra le sottoreti e l'azione del NAT.

    Ti consiglio la lettura di queste pagine:

    http://blogs.technet.com/b/ad/archive/2009/04/22/dcs-and-network-address-translation.aspx

    http://www.microsoft.com/en-us/download/details.aspx?id=16797

    giovedì 18 luglio 2013 15:47
    Moderatore
  • Ora credo di aver capito meglio la tua situazione, comunque in realtà per Windows è indifferente se utilizzi un tunnel L2TP oppure un GRE all'interno della connessione IPSec, ovvero non è quello che può causarti problemi nelle comunicazioni (entrambi sono in grado di incapsulare quel tipo di traffico). In ogni caso solitamente si tende a preferire L2TP over IPSec.

    La cosa a cui devi prestare attenzione è invece il routing tra le sottoreti e l'azione del NAT.

    Ti consiglio la lettura di queste pagine:

    http://blogs.technet.com/b/ad/archive/2009/04/22/dcs-and-network-address-translation.aspx

    http://www.microsoft.com/en-us/download/details.aspx?id=16797

    Capito.

    Ad ogni modo ho già affrontato il problema active directory in rete routata, alias (LAN <> DMZ), infatti ho dovuto abilitare un sacco di protocolli e come se non bastasse il traffico ICMP.

    Più che NAT su IPSEC credo si debba parlare di routing perchè non c'è mascheramente dell'IP.

    Io ho messo FG2 su una linea al momento scarica per provare e mi sembra funzionare con una IPSEC L2TP.

    Intanto ho notato una cosa per me strana: se faccio una traceroute tra le due LAN ottengo il seguente risultato:

    1) LAN (192.168.10.10) FG2 -> LAN FG1 (192.168.2.56)

    1 <1ms <1ms <1ms  192.168.10.1

    2 24ms 24ms 24ms X.X.X.X (IP PUBBLICO dell'Interfaccia WAN di FG1)

    3) 24ms 24ms 24ms 192.168.2.56

    ma come? faccio un hop sulla wan???? strano

    Non mi funziona il ping dalla LAN di FG1 verso la LAN di FG2 e non capisco il perchè:

    il ping inverso va che una bellezza.

    2) LAN (192.168.2.56) FG1 -> LAN FG2 (192.168.10.10)

    1 <1ms <1ms <1ms  192.168.2.150

    2 24ms 24ms 24ms X.X.X.X (IP PUBBLICO dell'Interfaccia WAN di FG2)

    3 richiesta scaduta

    ....

    30 richiesta scaduta

    C'è però qualcosa che non va: RDP funziona da entrambi i lati, mentre invece SMB funziona solo da FG2 verso FG1, perché????

    venerdì 19 luglio 2013 07:24
  • Il fatto che non funziona il ping da FG1 a FG2 mentre da FG2 a FG1 si, è indicativo. Infatti l'SMB funziona correttamente da FG2 a FG1 proprio perché in questo caso il routing viene eseguito correttamente.

    Il tracert conferma i dubbi sul collegamento da FG1 a FG2. Il fatto che funziona il protocollo RDP mi fa pensare che il problema possa essere dovuto semplicemente ad una qualche regola non perfettamente configurata sul traffico in entrata su FG2. Prova ad eseguire un controllo incrociato delle configurazioni.

    venerdì 19 luglio 2013 10:53
    Moderatore
  • Il fatto che non funziona il ping da FG1 a FG2 mentre da FG2 a FG1 si, è indicativo. Infatti l'SMB funziona correttamente da FG2 a FG1 proprio perché in questo caso il routing viene eseguito correttamente.

    Il tracert conferma i dubbi sul collegamento da FG1 a FG2. Il fatto che funziona il protocollo RDP mi fa pensare che il problema possa essere dovuto semplicemente ad una qualche regola non perfettamente configurata sul traffico in entrata su FG2. Prova ad eseguire un controllo incrociato delle configurazioni.

    Per fugare ogni dubbio su FG2 ho effettuato un hard reset (potevo farlo perchè scarico) e reimpostato tutto da 0. Ora, al 99% sono sicuro che non sia FG2 il problema.

    Purtroppo non posso fare la stessa cosa con FG1, perchè è online, ma sicuramente ci sarà un problema su questo firewall

    Ho incrociato le configurazioni, ma non ho cavato un ragno dal buco: gli echo non riescono ad arrivare a destinazione.

    forse è qualcosa nel routing, ma sembrerebbe essere tutto a posto.

    Ecco i test.

    TEST FG1 drection FG2 RESULT
    PING if 2.150 <      if 10.1   OK 
    PING if 2.150 < lan 10.10 OK 
    PING lan 2.0/24 > if 10.1   OK
    PING lan 2.0/24    lan 10.10  fails
    SMB/CIFS lan 2.0/24  < lan 10.10     OK
    SMB/CIFS lan 2.0/24    > lan 10.10 fails
    RDP lan 2.0/24    < lan 10.10 OK
    RDP lan 2.0/24  > lan 10.10 OK

                           

    diagnose vpn ike errors su FG2: limits.euthanized: 0 limits.blocked: 0 in.truncated: 0 in.giant: 0 in.baby: 0 in.baby.float: 0 out.fail: 0 iskamp.truncated: 0 iskamp.embryonic.connection.killed: 0 iskamp.embryonic.sa.killed: 0 iskamp.established.sa.killed: 0 iskamp.duplicate: 0 iskamp.unknown: 0 iskamp.remote-addr-mismatch: 0 iskamp.local-addr-mismatch: 0 iskamp.timeout.initiator: 0 iskamp.timeout.responder: 0 iskamp.retrans.recv.larval: 0 iskamp.retrans.recv.send: 0 iskamp.retrans.send: 0 iskamp.straggler: 0 quick.bad-status: 0 quick.duplicate-payload: 0 quick.not-encrypted: 0 quick.decryption.fail: 0 quick.retrans.recv.larval: 0 quick.retrans.recv.send: 0 quick.retrans.send: 0 info.truncated: 0 info.hash.missing: 0 info.hash.size: 0 info.hash.content: 0 ikev2.timeout.initiator: 0 ikev2.timeout.responder: 0 dpd.replay: 0 dpd.fail.old.hit: 0 dpd.fail.old.ignore: 0 dpd.fail.dynamic: 0 dpd.fail.port: 0 dpd.fail.unknown: 0 dpd.trigger.dynamic: 0 dpd.trigger.gateway: 0 dpd.trigger.port: 0 dpd.trigger.unknown: 0 mem.fail: 0 0 0

     

    diagnose vpn ike errorssu FG1

    limits.euthanized: 0
    limits.blocked: 0
    in.truncated: 0
    in.giant: 0
    in.baby: 0
    in.baby.float: 0
    out.fail: 0
    iskamp.truncated: 0
    iskamp.embryonic.connection.killed: 0
    iskamp.embryonic.sa.killed: 0
    iskamp.established.sa.killed: 0
    iskamp.duplicate: 0
    iskamp.unknown: 0
    iskamp.remote-addr-mismatch: 0
    iskamp.local-addr-mismatch: 0
    iskamp.timeout.initiator: 0
    iskamp.timeout.responder: 0
    iskamp.retrans.recv.larval: 0
    iskamp.retrans.recv.send: 0
    iskamp.retrans.send: 0
    iskamp.straggler: 0
    quick.bad-status: 0
    quick.duplicate-payload: 0
    quick.not-encrypted: 0
    quick.decryption.fail: 0
    quick.retrans.recv.larval: 0
    quick.retrans.recv.send: 0
    quick.retrans.send: 0
    info.truncated: 0
    info.hash.missing: 0
    info.hash.size: 0
    info.hash.content: 0
    ikev2.timeout.initiator: 0
    ikev2.timeout.responder: 0
    dpd.replay: 0
    dpd.fail.old.hit: 0
    dpd.fail.old.ignore: 0
    dpd.fail.dynamic: 0
    dpd.fail.port: 0
    dpd.fail.unknown: 0
    dpd.trigger.dynamic: 0
    dpd.trigger.gateway: 0
    dpd.trigger.port: 0
    dpd.trigger.unknown: 0
    mem.fail: 0 0 0

    venerdì 19 luglio 2013 12:40
  • Si, a questo punto potrebbe essere tranquillamente un problema di routing.
    In ogni caso è proprio un problema di configurazione dei firewall, non è un problema di solo traffico Windows.
    lunedì 22 luglio 2013 11:26
    Moderatore
  • diciamo che sto problema mi interessa poco per il momento, dato che funziona il contrario.

    L'unica mia preoccupazione è che ci sono due centrali asterisk nelle due sedi che hanno, tra di loro, una InterOffice (IAX2 port 4569/UDP) che passa per l'attuale tunnel OpenVPN bridgato. forse qui qualcosa potrbbe non funzionare.

    Sto provando a sentire anche Fortinet per avere supporto, ma al momento non ho notizie.

    Grazie comunque per l'aiuto e le delucidazioni.

    martedì 23 luglio 2013 13:25
  • Ciao,

    Nel frattempo, evidenzio i consigli sopra (potrebbero tornare utili per molti scenari simili).

    Saluti,


    Anca Popa Follow ForumTechNetIt on Twitter

    Microsoft offre questo servizio gratuitamente, per aiutare gli utenti e aumentare il database dei prodotti e delle tecnologie. Il contenuto viene fornito “così come è” e non comporta alcuna responsabilità da parte dell'azienda.

    mercoledì 24 luglio 2013 13:58
  • Stranamente il routing completo tra lan e tunnel si è messo a funzionare completamente, senza che facessi nulla: le policy erano già a posto.

    Da ieri ho anche messo il Fortigate100A in produzione presso la nostra sede periferica e oltre ad avere un tunnel VPN hardware ho riscontrato anche miglioramenti nelle performance rispetto all'allora firewall endian virtualizzato su XEN.

    Anche il VOIP su IAX2 non ha avuto problemi a funzionare.

    Grandioso.

    Grazie a tutti per i consigli e suggerimenti.

    • Contrassegnato come risposta Anca Popa martedì 6 agosto 2013 13:57
    martedì 6 agosto 2013 09:03