Geen internet meer zodra VPN verbinding wordt ingeschakeld

[koffieboontje]

Heren,

Ik werk al 3 jaar deels vanuit huis. Er is destijds een VPN verbinding gemaakt tussen mij en de zaak.
Ik maak gebruikt van Astaro VPN Client.
Al 3 jaar lang werkt dit probleemloos. Echter na mijn vakantie had ik ineens geen internet meer zodra ik verbinding maakte met de Astaro VPN Client.

Het duurde even voordat ik constateerde waar het aan lag. Na een reset van de modem en meerdere keren de pc gereset te hebben had ik elke keer gewoon netjes internet. Echter het moment dat de Astaro VPN client verbinding heeft gemaakt met de zaak is mijn eigen internet niet meer bruikbaar en geeft hij bij elke site aan “Pagina kan niet worden weergegeven”.

Echter rechts onderin op de balk waar je de status van je netwerk adapter ziet komt er geen kruis in of iets dergelijks. Het moment dat ik de verbinding met de Astaro VPN adapter verbreek heb ik letterlijk binnen 1 seconde weer gewoon internet.

Nu heb ik zelf ook nog een Laptop welke ik soms in het weekend of op vakantie gebruik om wel eens in te loggen naar de zaak, ook hier exact hetzelfde probleem. Zodra de Astaro VPN client wordt ingeschakeld heb ik geen internet meer.

Mijn specs:

PC: i5 processor, 16GB RAM, SSD schijf etc. draaiende op windows 7
VPN Client: Astaro
Browsers: Mozilla Firefox, Internet explorer en Chrome
Internet: UPC 120Mbit

Ik ben hier al een volle week mee bezig. Aantal facts op een rijtje:

• Lokaal IP adres van modem/router al aangepast van 192.168.1.1 naar 193.168.1.1
• ICT bedrijf van de zaak heeft al 2x mijn pc overgenomen en diverse zaken geprobeerd. Ook bij Astaro ipv open VPN instellingen internet explorer instellingen geprobeerd.
• ICT bedrijf had exact zelfde probleem gister dat ze bij het inloggen naar de zaak geen internet meer hadden.
• Gister eind van de dag heeft dit bedrijf op de server op de zaak wat gewijzigd in de routing van de firewall. Hierna hadden ze na testen internet, echter neemt hij dan de zeer trage verbinding over van de zaak. Aan IP adres te zien heb ik dan ook een KPN IP-adres via www.speedtest.net en www.watismijnip.nl. Zodra ik de Astaro VPN client stop zet en naar beide van deze sites gaan heb ik wel mijn eigen UPC IP-adres. Via KPN heb ik ook maar 0,50 Mbit terwijl ik met UPC mijn gebruikelijke ± 116Mbit haal.
• Op de een of andere manier neemt hij dus zodra ik verbinding heb de internetinstellingen over van de VPN, dit heb ik nu dus al de hele week en hiervoor 3 jaar lang niet
• Laptop vanmorgen afgegeven bij ons ICT bedrijf, zij hebben ook UPC, bij inloggen via de Astaro hadden hun wel direct hun eigen internet.
• Heb 2 netwerkadapters, de gewone LAN1 waar mijn UPC bekabeld op aan zit gesloten. Bij eigenschappen staat gedeelde verbinding gewoon uit, zoals het hoort. IP adressen, DNS etc, automatisch toegewezen. De LAN2 is een virtuele netwerkadapter, die Astaro VPN Client, ook hier alles automatisch toegewezen en ook geen gedeelde internet verbinding aangevinkt.
• Astaro VPN client al meerdere malen gede-installeerd en opnieuw geïnstalleerd met de juiste instellingen en configuratie.
• AVAST antivirus realtime schilden + firewall tijdelijk uitgeschakeld en dan getest, zelfde resultaat.

Wij komen er dus niet meer aan uit.

Nu is eigenlijk mijn vraag, kan het zo zijn dat UPC op de een of andere manier in onze vakantie iets in hun routing ofzo heeft veranderd waardoor ik nu niet tegelijk meer een VPN verbinding open kan hebben staan en mijn eigen internet behoud? Er is helemaal niets gewijzigd in mijn modem/router/adapter/netwerk instellingen.

Snap er dus helemaal niets van. Volgens de ICT mannen lag het in eerste instantie aan de server op de zaak. Daar hebben ze dus wel het een en ander aangepast omdat ze er zelf ook last van hadden. Echter bij het testen van mijn laptop bij het ICT bedrijf werkt het nu dus wel, terwijl mijn PC thuis dus nog steeds geen internet heeft zodra ik verbonden ben met Astaro.

Naar mijn idee heb ik alles geprobeerd wat ik kon doen.
Ik weet dus nu ook niet meer of het probleem lokaal bij mij zit, bij UPC of op de server van de zaak.
Het eerste lijkt mij uitgesloten omdat ik het probleem zowel op mijn pc heb als via wifi op de laptop. (en voor mijn vakantie dus alles prima werkte)

Hoop dat jullie een verlossende tip kunnen geven!

Alvast bedankt voor alle moeite.

[Oogje]

Ergens zit een optie of je al het lokale verkeer via de VPN wil laten lopen, of dat je toch nog je eigen gateway ook kan gebruiken.
Lijkt erop dat nu het eerste gebeurd.

* Oogje weet het niet meer precies...

edit:

This issue may occur if you configure the VPN connection to use the default gateway on the remote network. This setting overrides the default gateway settings that you specify in your Transmission Control Protocol/Internet Protocol (TCP/IP) settings

En dat kan volgens mij aan de client & serverkant ingesteld worden.

[ Voor 42% gewijzigd door Oogje op 31-07-2013 13:57 ]

[LlamaLoco]

1. Verander je ip-adres heel snel terug naar 192.168.x.x of 10.x.x.x of 172.16.x.x
Je gebruikt nu een public IP aan de binnenkant waardoor dat stukje internet voor jou nooit te bereiken zal zijn.

edit: Universiteit van Luxemburg kun jij niet meer heen:
inetnum: 193.168.1.0 - 193.168.1.255
netname: CU-CB-NET
descr: Universite du Luxembourg
org: ORG-UdL4-RIPE
country: LU


2. de Routing van UPC heeft hier niets mee te maken m.i. de routing op je laptop wel.
Check de routering met route print. Bij 0.0.0.0 (het hele internet) moet de gateway je eigen UPC modem zijn. Na het opzetten van de VPN zal dit veranderen in een adres binnen je bedrijfsnetwerk. Over het algemeen kun je in je VPN client regelen dat hij dat niet moet doen voor 0.0.0.0.
Routering kun je aanpassen met route add en route delete.

Succes

[ Voor 15% gewijzigd door LlamaLoco op 31-07-2013 14:00 . Reden: toevoegen Whois ]

[KillerAce_NL]

Yep, de verkeerde gateway wordt gebruik, kun je ergens aanvinken geloof ik.

[koffieboontje]

LlamaLoco schreef op woensdag 31 juli 2013 @ 13:56:
1. Verander je ip-adres heel snel terug naar 192.168.x.x of 10.x.x.x of 172.16.x.x
Je gebruikt nu een public IP aan de binnenkant waardoor dat stukje internet voor jou nooit te bereiken zal zijn.

2. de Routeing van UPC heeft hier niets mee te maken m.i. de routing op je laptop wel.
Check de routering met route print. Bij 0.0.0.0 (het hele internet) moet de gateway je eigen UPC modem zijn. Na het opzetten van de VPN zal dit veranderen in een adres binnen je bedrijfsnetwerk. Over het algemeen kun je in je VPN client regelen dat hij dat niet moet doen voor 0.0.0.0.
Routering kun je aanpassen met route add en route delete.

IP adres heb ik daarna ook direct weer aangepast terug naar 192.168.1.1. Ik had ook al vermoeden dat dit absoluut geen resultaat zou opleveren, maarja dit heeft dat ICT bedrijf gedaan op afstand. Zouden zij dan toch ook moeten weten zou je zeggen....

Maar die Gateway aanpassen kan ik niet zelf lokaal op eigen pc toch? Hiermee bedoel je toch de Gateway instellingen van de server waarop ik met de Astaro VPN inlog?

Maar al zou dit zo zijn, hoe kan het dan zijn dat het ICT bedrijf vanochtend getest heeft met de laptop en dat deze het toen wel probleemloos deed: VPN verbinding met de zaak met behoud van eigen internet (UPC) ?

Ik ben nu nog op de zaak. Kan vanavond pas thuis testen of het dan wel werkt. Maar heb mijn vriendin vanuit huis zojuist al laten proberen met de vaste pc, en dat werkt nog steeds niet

[DaLass]

Ja, kun je wel zelf aanpassen. Voor je VPN verbinding is een netwerkadapter aangemaakt. Bij de eigenschappen van het TCP-IP protocol kun je bij "geavanceerd" dit vinkje uitzetten.

"Standaard gateway in dit netwerk gebruiken"

[koffieboontje]

DaLass schreef op woensdag 31 juli 2013 @ 14:33:
Ja, kun je wel zelf aanpassen. Voor je VPN verbinding is een netwerkadapter aangemaakt. Bij de eigenschappen van het TCP-IP protocol kun je bij "geavanceerd" dit vinkje uitzetten.

"Standaard gateway in dit netwerk gebruiken"

Die staan beide uitgevinkt. Zowel op laptop als vaste pc.
Daar was ik verder ook niet aangeweest.
Althans neem aan dat jullie dit bedoelde?

[ Voor 5% gewijzigd door koffieboontje op 31-07-2013 15:57 ]

[Oogje]

Volgens mij moet je dat in je VPN client regelen...niet bij de NIC die de VPN gebruikt.

[koffieboontje]

Oogje schreef op woensdag 31 juli 2013 @ 16:09:
Volgens mij moet je dat in je VPN client regelen...niet bij de NIC die de VPN gebruikt.

Ik kan daar verder weinig aan wijzigen....
Daar is ook niets aan veranderd de afgelopen dagen of weken

[Oogje]

Aan de serverkant ook niets gewijzigd?

[koffieboontje]

Oogje schreef op woensdag 31 juli 2013 @ 18:58:
Aan de serverkant ook niets gewijzigd?

Nope volgens de ICT afdeling niet, maar dat weet ik zelf dus nooit 100% zeker in 4 weken afwezigheid.
Ben inmiddels thuis, was vanmiddag op de zaak. Maar hier thuis zit ik nu op de laptop.
Als ik verbinding maak met Astaro heb ik geen eigen internet meer. Hij neemt dan het internet over van de zaak. UPC IP wordt dan veranderd in het KPN IP... snap er echt niets van. Heb dit nog nooit gehad.

Woon zelf in Helmond, ICT bedrijf voor onze zaak zit in Voorthuizen, zij zelf hebben ook UPC en daar getest, ze zijden dat het werkte, alhoewel ik nu echt ga twijfelen. Bij ons op de zaak hebben ze een KPN lijntje van niks (ligt geen kabel of niets, dit terzijde). Dus ligt het nu toch aan UPC of iets in mijn router/modem instellingen? Ook daar ben ik helemaal niet aangeweest....

[koffieboontje]

Als ik ook naar de log kijk van de Astaro VPN Client zie is deze als volgt:

Wed Jul 31 19:09:38 2013 OpenVPN 2.1.1 i686-pc-cygwin [SSL] [LZO2] built on May 7 2010
Wed Jul 31 19:09:44 2013 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Wed Jul 31 19:09:44 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Wed Jul 31 19:09:44 2013 LZO compression initialized
Wed Jul 31 19:09:44 2013 Control Channel MTU parms [ L:1556 D:140 EF:40 EB:0 ET:0 EL:0 ]
Wed Jul 31 19:09:44 2013 Data Channel MTU parms [ L:1556 D:1450 EF:56 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Jul 31 19:09:44 2013 Local Options hash (VER=V4): '619088b2'
Wed Jul 31 19:09:44 2013 Expected Remote Options hash (VER=V4): 'a4f12474'
Wed Jul 31 19:09:44 2013 Attempting to establish TCP connection with 188xxxxxxxx
Wed Jul 31 19:09:44 2013 TCP connection established with 188xxxxxxxx
Wed Jul 31 19:09:44 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Jul 31 19:09:44 2013 TCPv4_CLIENT link local: [undef]
Wed Jul 31 19:09:44 2013 TCPv4_CLIENT link remote: xxxxxxxxxx
Wed Jul 31 19:09:44 2013 TLS: Initial packet from 188.xxxxxxxxx, sid=57e01109 f411e89b
Wed Jul 31 19:09:44 2013 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Jul 31 19:09:45 2013 VERIFY OK: depth=1, /C=nl/L=Voorthuizen/O=Veenhuizen/CN=Veenhuizen_VPN_CA/emailAddress=mccxxxxx@xxxxxxx
Wed Jul 31 19:09:45 2013 VERIFY X509NAME OK: /C=nl/L=Voorthuizen/O=Veenhuizen/CN=Astaro/emailAddress=mccxxxxx@xxxxxxx
Wed Jul 31 19:09:45 2013 VERIFY OK: depth=0, /C=nl/L=Voorthuizen/O=Veenhuizen/CN=Astaro/emailAddress=mccxxxxx@xxxxxxx
Wed Jul 31 19:09:47 2013 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Wed Jul 31 19:09:47 2013 Data Channel Encrypt: Using 128 bit message hash 'MD5' for HMAC authentication
Wed Jul 31 19:09:47 2013 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Wed Jul 31 19:09:47 2013 Data Channel Decrypt: Using 128 bit message hash 'MD5' for HMAC authentication
Wed Jul 31 19:09:47 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Wed Jul 31 19:09:47 2013 [Astaro] Peer Connection Initiated with 188.xxxxxxxx
Wed Jul 31 19:09:49 2013 SENT CONTROL [Astaro]: 'PUSH_REQUEST' (status=1)
Wed Jul 31 19:09:49 2013 PUSH: Received control message: 'PUSH_REPLY,route remote_host 255.255.255.255 net_gateway,redirect-gateway def1,dhcp-option DNS 192.168.xxxxx,route 10.242.2.1,topology net30,ping 10,ping-restart 120,ifconfig 10.242.xxxxx 10.242.xxxxx'
Wed Jul 31 19:09:49 2013 OPTIONS IMPORT: timers and/or timeouts modified
Wed Jul 31 19:09:49 2013 OPTIONS IMPORT: --ifconfig/up options modified
Wed Jul 31 19:09:49 2013 OPTIONS IMPORT: route options modified
Wed Jul 31 19:09:49 2013 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Jul 31 19:09:49 2013 ROUTE default_gateway=192.168.1.1
Wed Jul 31 19:09:50 2013 TAP-WIN32 device [LAN-verbinding 2] opened: \\.\Global\{5C8709B1-6F79-4573-BB55-062732C945A4}.tap
Wed Jul 31 19:09:50 2013 TAP-Win32 Driver Version 9.6
Wed Jul 31 19:09:50 2013 TAP-Win32 MTU=1500
Wed Jul 31 19:09:50 2013 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.242.2.6/255.255.255.252 on interface {5C8709B1-6F79-4573-BB55-062732C945A4} [DHCP-serv: 10.242.2.5, lease-time: 31536000]
Wed Jul 31 19:09:50 2013 Successful ARP Flush on interface [14] {5C8709B1-6F79-4573-BB55-062732C945A4}
Wed Jul 31 19:09:54 2013 TEST ROUTES: 3/3 succeeded len=2 ret=1 a=0 u/d=up
Wed Jul 31 19:09:54 2013 C:\WINDOWS\system32\route.exe ADD 188.204.xxxxxxx9 MASK 255.255.255.255 192.168.1.1
Wed Jul 31 19:09:54 2013 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed Jul 31 19:09:54 2013 Route addition via IPAPI succeeded [adaptive]
Wed Jul 31 19:09:54 2013 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.242.xxxxx
Wed Jul 31 19:09:54 2013 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed Jul 31 19:09:54 2013 Route addition via IPAPI succeeded [adaptive]
Wed Jul 31 19:09:54 2013 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.242.xxxxx
Wed Jul 31 19:09:54 2013 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed Jul 31 19:09:54 2013 Route addition via IPAPI succeeded [adaptive]
Wed Jul 31 19:09:54 2013 C:\WINDOWS\system32\route.exe ADD 188.204.xxxxxx MASK 255.255.255.255 192.168.1.1
Wed Jul 31 19:09:54 2013 ROUTE: route addition failed using CreateIpForwardEntry: Het object bestaat al. [status=5010 if_index=10]
Wed Jul 31 19:09:54 2013 Route addition via IPAPI failed [adaptive]
Wed Jul 31 19:09:54 2013 Route addition fallback to route.exe
Wed Jul 31 19:09:54 2013 C:\WINDOWS\system32\route.exe ADD 10.242.xxxxx MASK 255.255.255.255 10.242.2.5
Wed Jul 31 19:09:54 2013 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Wed Jul 31 19:09:54 2013 Route addition via IPAPI succeeded [adaptive]
Wed Jul 31 19:09:54 2013 Initialization Sequence Completed

Ik denk dat het misgaat bij de regel die ik dikgedrukt gemarkeerd heb. Normaliter hoort deze log ook vele malen korter te zijn als ik inlog.
Hopelijk heb je iets aan deze log waarmee jullie verder kunnen?

Heb ook die route print gedaan. Als ik de VPN client uitschakel en dan een route print doe en deze naast de route print leg met de VPN client ingeschakeld zie wel een verschil. De routing van degene waarvan VPN is ingeschakeld is veel langer ook. Hebben jullie hier eventueel nog wat aan? Neem aan dat ik niet al die gegevens hiervan in een forum moet zetten met al die IP adressen etc?

[Oogje]

Doe eens een route print als je niet geconnect bent? Zie je dan 188.204.x.x ook nog staan?
De opdrachtregel voor de dikgedrukte is degene die de dikgedrukte regel veroorzaakt.

[ Voor 32% gewijzigd door Oogje op 31-07-2013 20:10 ]

[koffieboontje]

Oogje schreef op woensdag 31 juli 2013 @ 20:09:
Doe eens een route print als je niet geconnect bent? Zie je dan 188.204.x.x ook nog staan?
De opdrachtregel voor de dikgedrukte is degene die de dikgedrukte regel veroorzaakt.

Nope, niet te bekennen. Zowel niet in de interfacelijst als in de IPv4 routetabel als in de IPv6 routetabel.
Als ik wel geconnect ben met Astaro VPN client en dan route print doe zie ik in de IPv4 routetabel wel de 188.204.x.x staan.

Overigens als ik dan naar ip gegevens ga is mijn ip ook 188.204.x.x
*Provider: kpn.net
*Hostname: static.kpn.net
*Socket: 63993

Als ik niet geconnect ben, binnen 1 seconden refresh en is mijn ip ineens weer 62.163.x.x
*Provider: chello.nl
*Hostname: a1xxxx3.upc-a.chello.nl
*Socket: 51301

Normaliter als ik verbonden ben met de VPN behoor ik mijn eigen IP te behouden van mijn eigen internet.

[KillerAce_NL]

Nee bij deze rule gaat het fout:
Wed Jul 31 19:09:54 2013 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.242.xxxxx
Hij gooit dus alles via 10.242

[alt-92]

Ze hebben split tunneling uitgeschakeld op de VPN appliance vermoedelijk.

[koffieboontje]

Ik heb zojuist nog wat dingen zelf getest en daarmee dus uitgesloten.

Ik heb thuis namelijk ook nog een andere provider. Heb ook nog een KPN modem welke uitsluitend voor mijn telefoon VPN verbinding wordt gebruikt.

Heb nu mijn UPC modem geheel uitgeschakeld en er even tussenuit. KPN modem aangesloten en nu ook eens getest.

Ook hier zelfde resultaat, waarmee ik dus eigenlijk al uitsluit:
• Dat het aan UPC ligt
• Dat het in de instellingen van mijn eigen modem zou zitten
• Dat het aan mijn PC of laptop ligt

Als ik GEEN verbinding heb met Astaro:

• IPadress: 188.x.x.161
• Provider: kpn.net
• Hostname: static.kpn.net
• Socket: 49352

Als ik WEL verbinding heb met Astaro:

• IPadress: 188.x.x.129
• Provider: kpn.net
• Hostname: static.kpn.net
• Socket: 58028

Dus ook met het aansluiten van de KPN modem behoud ik dus niet mijn eigen IP.
Op de laptop, idem dito.

Hij neemt nog steeds gewoon het internet van de VPN over.

Daarom snap ik er helemaal niets van dat ze mijn laptop hebben getest woensdag en dat het werkte. (Dat je dus zodra je verbonden was je eigen internet IP behield)

Wat ik nu zelf denk is dat ze dan misschien wel getest hebben, maar met hun eigen admin gebruikersnaam en wachtwoord zijn ingelogd op de server via Astaro VPN client. Maar dat het dus gewoon aan mijn gebruikersinstellingen op de server ligt. Een andere reden kan ik niet meer bedenken.
Heb nu een aantal zaken uitgesloten.

Ik wilde nu ook nog gaan testen bij mijn pa of ma, wonen ook beide in Helmond, hebben beide UPC. Wilde daar eens de Astaro VPN client opzetten en testen of ie daar ook het internet van de VPN overneemt. Maar eigenlijk heb ik het antwoord al doordat ik nu dus een geheel andere modem met andere provider (KPN) getest heb.

Ligt het dan nog steeds aan de routing of is het nu echt een bepaalde instelling op mijn gebruikersnaam op de server?

[KillerAce_NL]

Ken de astaro niet, maar het is gewoon een routing issue. Alleen je werk range dient over de vpn gerouteerd te worden, niet alles (zoals in de 0.0.0.0 rule staat).

[Oogje]

KillerAce_NL schreef op vrijdag 02 augustus 2013 @ 10:23:
Ken de astaro niet, maar het is gewoon een routing issue. Alleen je werk range dient over de vpn gerouteerd te worden, niet alles (zoals in de 0.0.0.0 rule staat).

Denk ik ook, misschien dat het nog aan de user kan liggen of die setting opgelegd wordt of niet vanuit de VPN-server?
Dat zou de laatste post van TS verklaren.

[koffieboontje]

Heren,

na ruim 1½ week verder is het probleem nu opgelost. Had nog wat zaken getest op een andere pc. Maar hier idem hetzelfde verhaal. Dus uitgesloten dat het aan mijn pc of UPC provider zou liggen.

Ze hebben nu wederom alles doorgenomen op de server. Details heb ik niet, wel naar gevraagd maar kreeg enkel te horen dat het in de Firewall instellingen op de server lag. De regels in de firewall over welk gedeelte van het netwerk onder welke voorwaarden over welke adapter moesten gaan, zijn nu wat instellingen gewijzigd. Er stond iets veranderd in waarvan ze niet weten hoe dit heeft kunnen gebeuren.

Blijft vaag, maar hij werkt nu wel weer gelukkig.
Misschien hebben jullie wel bijgedragen aan de oplossing maar zullen ze dat niet toegeven, kan ook nog ;-)

Evengoed dank voor jullie moeite.
Kan er wat mij betreft een slotje op mocht er niemand verder wat in te brengen hebben of op/aanmerkingen hebben

[Oogje]

koffieboontje schreef op maandag 12 augustus 2013 @ 16:43:
Heren,

na ruim 1½ week verder is het probleem nu opgelost. Had nog wat zaken getest op een andere pc. Maar hier idem hetzelfde verhaal. Dus uitgesloten dat het aan mijn pc of UPC provider zou liggen.

Ze hebben nu wederom alles doorgenomen op de server. Details heb ik niet, wel naar gevraagd maar kreeg enkel te horen dat het in de Firewall instellingen op de server lag. De regels in de firewall over welk gedeelte van het netwerk onder welke voorwaarden over welke adapter moesten gaan, zijn nu wat instellingen gewijzigd. Er stond iets veranderd in waarvan ze niet weten hoe dit heeft kunnen gebeuren.

Blijft vaag, maar hij werkt nu wel weer gelukkig.
Misschien hebben jullie wel bijgedragen aan de oplossing maar zullen ze dat niet toegeven, kan ook nog ;-)

Evengoed dank voor jullie moeite.
Kan er wat mij betreft een slotje op mocht er niemand verder wat in te brengen hebben of op/aanmerkingen hebben

Tis niet vaag, ze houden het vaag. Ik denk dat als je naar je logging kijkt dat de regel die Killeracenl aanhaalt niet meer bestaat

[koffieboontje]

@Oogje, de logging is nu als volgt:

Mon Aug 12 15:15:51 2013 OpenVPN 2.1.1 i686-pc-cygwin [SSL] [LZO2] built on May 7 2010
Mon Aug 12 15:15:57 2013 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Mon Aug 12 15:15:57 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Mon Aug 12 15:15:57 2013 LZO compression initialized
Mon Aug 12 15:15:57 2013 Control Channel MTU parms [ L:1556 D:140 EF:40 EB:0 ET:0 EL:0 ]
Mon Aug 12 15:15:57 2013 Data Channel MTU parms [ L:1556 D:1450 EF:56 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Aug 12 15:15:57 2013 Local Options hash (VER=V4): '619088b2'
Mon Aug 12 15:15:57 2013 Expected Remote Options hash (VER=V4): 'a4f12474'
Mon Aug 12 15:15:57 2013 Attempting to establish TCP connection with 188.xxx.xxx.129:8831
Mon Aug 12 15:15:57 2013 TCP connection established with 188.xxx.xxx.129:8831
Mon Aug 12 15:15:57 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Aug 12 15:15:57 2013 TCPv4_CLIENT link local: [undef]
Mon Aug 12 15:15:57 2013 TCPv4_CLIENT link remote: 188.xxx.xxx.129:8831
Mon Aug 12 15:15:57 2013 TLS: Initial packet from 188.xxx.xxx.129:8831, sid=c7c5f3f4 3261ca18
Mon Aug 12 15:15:57 2013 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Aug 12 15:15:58 2013 VERIFY OK: depth=1, /C=nl/L=Voorthuizen/O=Veenhuizen/CN=Veenhuizen_VPN_CA/emailAddress=mcxxxx@veenhuxxx
Mon Aug 12 15:15:58 2013 VERIFY X509NAME OK: /C=nl/L=Voorthuizen/O=Veenhuizen/CN=Astaro/emailAddress=mcxxxx@veenhuxxx
Mon Aug 12 15:15:58 2013 VERIFY OK: depth=0, /C=nl/L=Voorthuizen/O=Veenhuizen/CN=Astaro/emailAddress=mcxxxx@veenhuxxx
Mon Aug 12 15:16:00 2013 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Mon Aug 12 15:16:00 2013 Data Channel Encrypt: Using 128 bit message hash 'MD5' for HMAC authentication
Mon Aug 12 15:16:00 2013 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Mon Aug 12 15:16:00 2013 Data Channel Decrypt: Using 128 bit message hash 'MD5' for HMAC authentication
Mon Aug 12 15:16:00 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Aug 12 15:16:00 2013 [Astaro] Peer Connection Initiated with 188.xxx.xxx.129:8831
Mon Aug 12 15:16:02 2013 SENT CONTROL [Astaro]: 'PUSH_REQUEST' (status=1)
Mon Aug 12 15:16:02 2013 PUSH: Received control message: 'PUSH_REPLY,route remote_host 255.255.255.255 net_gateway,route 192.168.100.0 255.255.255.0,route 10.xxx.x.1,topology net30,ping 10,ping-restart 120,ifconfig 10.xxx.x.6 10.xxx.x.5'
Mon Aug 12 15:16:02 2013 OPTIONS IMPORT: timers and/or timeouts modified
Mon Aug 12 15:16:02 2013 OPTIONS IMPORT: --ifconfig/up options modified
Mon Aug 12 15:16:02 2013 OPTIONS IMPORT: route options modified
Mon Aug 12 15:16:02 2013 ROUTE default_gateway=192.168.1.1
Mon Aug 12 15:16:02 2013 TAP-WIN32 device [LAN-verbinding 2] opened: \\.\Global\{CA360D6D-2CD1-40D2-9152-20114CFFFC66}.tap
Mon Aug 12 15:16:02 2013 TAP-Win32 Driver Version 9.6
Mon Aug 12 15:16:02 2013 TAP-Win32 MTU=1500
Mon Aug 12 15:16:02 2013 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.242.2.6/255.255.255.252 on interface {CA360D6D-2CD1-40D2-9152-20114CFFFC66} [DHCP-serv: 10.242.2.5, lease-time: 31536000]
Mon Aug 12 15:16:02 2013 Successful ARP Flush on interface [15] {CA360D6D-2CD1-40D2-9152-20114CFFFC66}
Mon Aug 12 15:16:06 2013 TEST ROUTES: 3/3 succeeded len=3 ret=1 a=0 u/d=up
Mon Aug 12 15:16:06 2013 C:\WINDOWS\system32\route.exe ADD 188.xxx.xxx.129 MASK 255.255.255.255 192.168.1.1
Mon Aug 12 15:16:06 2013 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=10 and dwForwardType=4
Mon Aug 12 15:16:06 2013 Route addition via IPAPI succeeded [adaptive]
Mon Aug 12 15:16:06 2013 C:\WINDOWS\system32\route.exe ADD 192.168.100.0 MASK 255.255.255.0 10.242.2.5
Mon Aug 12 15:16:06 2013 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Mon Aug 12 15:16:06 2013 Route addition via IPAPI succeeded [adaptive]
Mon Aug 12 15:16:06 2013 C:\WINDOWS\system32\route.exe ADD 10.242.2.1 MASK 255.255.255.255 10.242.2.5
Mon Aug 12 15:16:06 2013 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Mon Aug 12 15:16:06 2013 Route addition via IPAPI succeeded [adaptive]
Mon Aug 12 15:16:06 2013 Initialization Sequence Completed

De log is wel heel anders als die vorige. Mij zegt dit niets. Wellicht kunnen jullie nu aan de log zien wat er eventueel nog is veranderd....?

[Oogje]

Yup, zoals al door meerdere mensen in dit topic "voorspeld" is de regel dat al je verkeer over de VPN wordt gerouteert niet meer aanwezig:

Deze is dat:
C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.242.xxxxx

[koffieboontje]

Oogje schreef op maandag 12 augustus 2013 @ 17:26:
Yup, zoals al door meerdere mensen in dit topic "voorspeld" is de regel dat al je verkeer over de VPN wordt gerouteert niet meer aanwezig:

Deze is dat:
C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.242.xxxxx

Nice! :-)

Weer wat geleerd. Thanks voor de info nog in ieder geval en je moeite!

[Oogje]

En jij bedankt voor het terugkoppelen