none
TMG 2010 - VPN klienti mají problém s přístupem ke zdrojům v interní síti

    Dotaz

  • Ahoj všem,

    mám takový menší problém.

    Nejprve konfigurace: TMG 2010 na Win 2008R2, rozsah vnitřní sítě 192.168.38.0/24. TMG slouží jako VPN server, VPN klienti mají svůj subnet 192.168.35.0/24.

    A teď ten problém: když se připojí VPN klient a chce přistoupit k jakémukoliv zdroji ve vnitřní síti (web, RDP, file share), tak při prvním pokusu vyhoří na timeoutu. Druhý pokus je úspěšný.

    Příklad: vytočím VPN a chci protokolem RDP přistoupit na libovolný server. Připojení se nezdaří (timeout). Jakmile ihned poté zkusím znovu navázat RDP připojení na tentýž server, vše je OK. Pokud bych mezi prvním a druhým pokusem nechal větší časový rozestup, (cca minuta a více), tak se nezdaří ani druhý pokus. Pokud před prvním pokusem pingnu FQDN nebo IP serveru, podaří se připojení RDP protokolem napoprvé.

    Analogicky možno aplikovat na weby běžící ve vnitřní síti a na přístup ke sdíleným prostředkům.

    Aby to nebylo tak jednoduché, není to 100% stav. Tento stav mám hlášen od několika kolegů. Já sám se do inkriminované sítě připojuji ze dvou různých lokalit (v každé z jiného PC). Z jedné lokality pozoruji výše uvedené chování, ze druhé vše funguje správně (napoprvé).

    Měl jsem podezření na DNS, ale překlady fungují správně (a rychle).

    Nyní usuzuji, že problém způsobuje TMG, ale netuším proč.

    Dokážete někdo poradit?


    BB

    25. dubna 2013 12:32

Odpovědi

  • Tak uz vim, kde je problem. Je to v routovani na VPN klientovi.

    VPN subnet je 192.168.35.0/24. Subnet lokalni site, ve ktere se nachazi stanice s VPN klientem je 192.168.0.0/16. Subnet cilove site, do ktere se pripojuji pres VPN tunel je pak 192.168.38.0/24.

    Reseni je asi jedine: pridat routovaci zaznam na cilovou VPN sit tak, aby rozhrani byla aktualni IP adresa VPN adapteru.

    Takze skript volany task schedulerem na zaklade udalosti vygenerovane vytocenim VPNky.

    Pokud by nekdo znal jine reseni, tak samozrejme privitam. Samozrejme krome precislovani subnetu. :o)


    BB

    2. května 2013 13:21

Všechny reakce

  • podívejte se v TMG na vlastnosti Internal sítě. Na záložce Addresses si zapamatujte co tam bylo (screenshot) a zkuste tam znovu pridat váš LAN interface. Změnilo se to?

    ondra.

    26. dubna 2013 7:00
  • 1. Mozna mi ukla zasadni informace, je to nova nebo starsi instalace (fungovalo to drive?)?

    2. Podivejte se na tento clanek, mohlo by to byt reseni

    http://www.edugeek.net/forums/internet-related-filtering-firewall/105308-tmg-2010-vpn-connection-problems.html

    M.

    26. dubna 2013 8:11
    Moderátor
  • Diky za reakce,

    dostal jsem se k tomu zase až dnes . . .

    ad Ondrej Sevecek): "podívejte se v TMG na vlastnosti Internal sítě. Na záložce Addresses si zapamatujte co tam bylo (screenshot) a zkuste tam znovu pridat váš LAN interface. Změnilo se to?" - na záložce Access byly tři subnety 192.168.36.0-192.168.36.255, 192.168.37.0-192.168.37.255 a 192.168.38.0-192.168.38.255. Když jsem je odebral a znovu přidal interni LAN adaptér, tak to změnil na 192.168.36.0-192.168.38.255. Nicméně problém pořád přetrvává.

    ad Milos Puchta): Je to nova instalace, vypada to, ze se to takto chova od zacatku. Ten clanek ukazuje na problem s DNS, ale preklady jsem overoval a funguji bez problemu.


    BB

    30. dubna 2013 7:33
  • hmmm, to je asi těžké takto radit. to byste se musel podívat nejspíš network monitorem. co já bych typoval je to, že TMG špatně posuzuje, jestli je ten cíl ve vnitřní síti, nebo není. Když máte firewall clienta, tak všechny DNS dotazy jdou vždycky na TMG, to je samo přepošle na DNS server a ze zjištěné IP adresy cíle se potom posuzuje, jestli je to vnitřní cíl, nebo je vnější. Pokud je vnitřní, firewall client na stanicích jde přímo, zatímco pro vnější cíle se pak chodí přes TMG.

    obecně nemám firewall clienta vůbec rád, protože to instaluje něco do WINSOCKu, koliduje to porůznu s firewally a antiviry třetích stran apod. A v podstatě to není moc potřeba. Na co to konkrétně potřebujete vy? Nešlo by to raději zrušit?

    ondra.

    30. dubna 2013 9:52
  • Si asi nerozumime. :o) Problem maji VPN klienti, ne firewall klienti.

    Network monitor uz jsem nasadil. Ale nezachytava komunikaci ve VPN tunelu. A z logu TMG v inkriminovany okamzik zadnou komunikaci nevyctu. Jde nejak nastavit Netmon, aby zachytaval i komunikaci uvnitr VPN tunelu (at uz na klientovi nebo na TMG serveru). Jestli to je stupidni dotaz, tak se omlouvam, resim ted jeste neco jineho, tak nemam cas hledat.


    BB

    30. dubna 2013 10:16
  • a proč já si celou dobu myslím, že jde o firewall clienta? :-) no nic :-)

    takže těžko říct. já bych to typoval na nějakou další prima chybku v TMGčku. Máte tam poslední SP a Cummulative Update? Tyhle věci nejsou normálně na Windows Update, musíte si je stáhnout ručně: http://support.microsoft.com/kb/2735208

    No a potom, ano, VPN pakety uvnitř tunelu uvidíte na klientovi v Network Monitor. Musíte si monitor pustit ale bohužel až po vytočení, potom bude zobrazovat na první stránce i ten VPN interface.

    onda.

    30. dubna 2013 10:23
  • Zajimave jeste je to, ze ne u vsech VPN klientu se problem projevuje.

    Diky za tip se SP a CU. Az se k tomu dostanu, tak zaktualizuji a dam vedet.

    Tak ted si fakt nejsem jisty, jestli jsem netmon spoustel pred nebo po vytoceni VPNky. Taky testnu.

    Prozatim diky


    BB

    30. dubna 2013 10:27
  • jeste me tak napadlo, ze TMG ma v Intrusion Prevention tzv. Flood Miitgation. To omezuje pocet soucasnych pripojeni tim, ze je to proste kiluje. Zkuste se na to podivat, jestli to treba neni tim, ze to proste usekne nejaka pripojeni prave kvuli tomuhle.

    ondra.

    30. dubna 2013 10:30
  • Tak jsem se tomu zase chvilku venoval a odchytil jsem si Netmonem komunikaci VPN tunelu na klientovi pri pokusu o pristup na web v lokalni siti, kam jsem pripojeny VPNkou. A ona tam zadna nebyla . . .

    Lepe receno byla, ale jenom na portu 53, kdy se ptal DNS serveru. Pro jistotu jsem zapnul logovani lokalniho firewallu, jestli to nahodou nezarizne on, ale take tam neni videt nic jineho ne DNS dotaz(y).

    Jakmile to skonci na timeoutu a ja se pokusim pripojit podruhe, tak to jede. Netmon a log firewallu komunikaci odchyti (zobrazi).

    Takze problem nebude na strane TMG, ale nekde na stanici s VPN klientem.

    Jeste jsem si vsimnul tri veci:

    1. PING (na FQDN) udela to, ze prvni pokus ze standardnich ctyr neprojde, dalsi pak ano.

    2. Kdyz se prvni pripojeni nezdari, tak druhe se vzdy podari. Ovsem jen pokud probehne v relativne kratkem case po prvnim (par vterin, maximalne minuta). Kdyz je prodleva mezi prvnim a druhym pripojenim delsi, druhe se opet nezdari.

    3. Nekdy (naprosto vyjimecne, odhadem tak v 1% pripadu) funguje pripojeni hned napoprve.


    BB


    2. května 2013 11:31
  • Tak uz vim, kde je problem. Je to v routovani na VPN klientovi.

    VPN subnet je 192.168.35.0/24. Subnet lokalni site, ve ktere se nachazi stanice s VPN klientem je 192.168.0.0/16. Subnet cilove site, do ktere se pripojuji pres VPN tunel je pak 192.168.38.0/24.

    Reseni je asi jedine: pridat routovaci zaznam na cilovou VPN sit tak, aby rozhrani byla aktualni IP adresa VPN adapteru.

    Takze skript volany task schedulerem na zaklade udalosti vygenerovane vytocenim VPNky.

    Pokud by nekdo znal jine reseni, tak samozrejme privitam. Samozrejme krome precislovani subnetu. :o)


    BB

    2. května 2013 13:21