Beantwoord

VPN Passthrough

  • 26 april 2013
  • 63 reacties
  • 23039 keer bekeken

Reputatie 7
Mijn bedrijf vereist dat werkplekken thuis middels een IPSec VPN verbinding beveiligd worden voor toegang op het bedrijfsnetwerk. Deze VPN verbinding wordt vanuit het kantoor geïnitieerd naar een Cisco VPN Server die achter de router thuis (KPN TG789vn) geplaatst is.

Met behulp van port forwarding van TCP poort 443 of 60443 en UDP poorten 500 en 4500 wordt de VPN tunnel opgezet. Deze VPN tunnel wordt succesvol tot stand gebracht echter de laatste fase van het activeren van de tunnel is de verificatie van het LAN (thuis) door het versturen van een ping naar het interne adres van de Cisco VPN Server. Deze is niet succesvol omdat de router van KPN icmp requests blokkeert.

KPN: Kunnen jullie mijn router zo configureren dat icmp requests doorgelaten worden?

icon

Beste antwoord door wjb 7 september 2013, 16:31

Ook de ZTE H220N, die ik van KPN heb mogen ontvangen, bood geen oplossing voor het probleem.

Ik heb dus nu maar een eigen router (Cisco RV180W) ingezet om de internet verbinding met KPN te onderhouden. (Methode 1: http://netwerkje.com/eigen-router)

Als switch heb ik een Dell Powerconnect 2808 opgenomen om te zorgen dat de door KPN gebruikte VLAN's correct gerouteerd worden.

Deze switch is als onderstaand geconfigureerd:

Poort 1: Aangesloten op het Genexis glasvezel modem van KPN met de VLAN's 4, 6 en 7 tagged

Poort 2: Aangesloten op de WAN zijde van de eigen Cisco router met VLAN 6 untagged

Poort 3: Aangesloten op de router van KPN (Experia box V8) met VLAN 4 en 7 tagged

Poort 4: Aangesloten op de LAN zijde van de eigen Cisco router met VLAN 1 untagged

Poort 5-8: Geconfigureerd als LAN (VLAN 1 untagged) Deze poorten fungeren nu dus feitelijk als extra LAN poorten van de eigen router waarop dus ook PC's, Servers, netwerkschijven (NAS) etc. bekabeld aangesloten kunnen worden.

De KPN router wordt nu alleen nog maar gebruikt voor iTV (VLAN 4) en de telefoon (VLAN 7), internet (VLAN 6) wordt afgewikkeld via de eigen Cisco router.

Ik heb dan ook de WiFi op de KPN router uitgeschakeld, deze heeft toch geen zin meer.

Een nadeel aan deze oplossing is dat (wijzigingen in) de instellingen op de KPN router niet meer automatisch op de KPN router doorgevoerd worden.

Dus als er een stroomstoring is geweest (komt gelukkig niet vaker dan 1 keer per 2 jaar voor) of als KPN de instellingen van iTV of de telefoon aanpast, dan moet de KPN router eerst ook weer even aan het internet (VLAN 6) gehangen worden, zodat de instellingen weer geladen kunnen worden.

Dit doe ik door op poort 2 van de switch (eigen router) VLAN 6 te verwijderen en op poort 3 (KPN router) VLAN 6 tagged toe te voegen. Nadat vervolgens de instellingen op de KPN router weer geladen zijn draai ik deze wijzigingen weer terug.

Een voordeel van de oplossing is dat ik nu zelf het volledige beheer heb over wat er wel en niet toegestaan wordt in de firewall van de router en (en dat is nog wel het voornaamste) dat de problemen die ik ondervond nu verholpen zijn.

Mijn configuratie is nu dus zoals getoond op: http://netwerkje.com/switch-configuratie met als extra een verbinding tussen één van de LAN poorten van de eigen router en poort 4 van de switch.

Overigens kan je tegenwoordig (in ieder geval op de Experia box V8) alle LAN poorten gebruiken voor het aansluiten van TV's. Dit betekent dus dat de door KPN geleverde switch voor de distributie van iTV naar meerdere TV's kan komen te vervallen. (Gewoon direct op de Experia box aansluiten.)

Bekijk origineel

63 reacties

Reputatie 7
Badge +28
Beste wjb,

Allereerst mijn excuses voor de late reactie. Het was me niet bekend dat de 789 een pingverzoek blokkeert. Ik begrijp dat dit voor problemen zorgt, maar het is me niet duidelijk waarom de pingrequest nog nodig is als de VPN-verbinding al tot stand is gebracht. Ik heb zelf met de 789 geen problemen ondervonden met een VPN-verbinding, maar de technische details van deze verbinding zullen ongetwijfeld anders zijn geweest dan in jouw situatie.

Ik vermoed dat de enige goede optie is om een nieuw modem te sturen, het is niet mogelijk deze instelling te wijzigen in de TG789. Zou je in een privébericht je postcode, huisnummer en naam contractant kunnen sturen? Graag verneem ik ook welk abonnement je afneemt van KPN en of dit een zakelijk of consumentenabonnement betreft.

Met vriendelijke groet,

Joran

Reputatie 7
Beste Joran,

Misschien is het verstandig dat de KPN zich eens gaat verdiepen in de verschillende wijzen waarmee VPN verbindingen opgezet worden.

In dit geval betreft het een VPN verbinding op basis van Cisco QuickVPN waarbij de VPN server zich op het LAN (achter de KPN router) bevindt.

Wellicht is het jullie niet bekend dat een Cisco QuickVPN verbinding m.b.v. een ping naar het interne ip-adres van de VPN server controleert of de VPN succesvol tot stand kon worden gebracht.

Zonder succesvol ping request kan de VPN verbinding niet geactiveerd worden.

Verder geef je aan dat je zelf geen problemen hebt ondervonden met het opzetten van VPN verbindingen.

Ik kan me dat goed voorstellen, ook ik heb er meerdere operationeel via de KPN router.

Belangrijk hierbij is echter dat het hier een INKOMENDE VPN verbinding betreft op basis van Cisco QuickVPN.

Ik ben bang dat het versturen van een nieuw modem niet de juiste weg is zolang daar dezelfde firmware (KPN) op staat. De tg789 ondersteunt het wijzigen van deze instelling wel, maar de dichtgeknepen firmware van KPN blokkeert wellicht de wijziging van deze instelling.

De tg789 bevat gewoon een configureerbare firewall, maar KPN heeft de firmware zo laten aanpassen dat de firewall niet door de eindgebruiker aan te passen is.

Overigens wil ik jullie er graag op wijzen dat jullie (KPN) op basis van artikel 7.4a van de telecommunicatiewet sinds 1 januari 2013 verplicht zijn om alle door de klant gewenste communicatie opties mogelijk te laten zijn.

Dit houdt feitelijk in dat jullie verplicht zijn de eindgebruiker in staat te stellen ZELF de firewall op de router te beheren.

Ik heb dan ook een verzoek hiertoe bij de KPN klantenservice glasvezel ingedient echter tot op heden heb ik hierop geen reactie mogen ontvangen, wat ik de KPN kwalijk neem aangezien ik op andere later ingediende vragen wel antwoord heb ontvangen.

 

Een organisatie die zijn klanten respecteert reageert op elke vraag van de klant en niet selectief op de ene wel en op de andere niet.

 

Reputatie 7
Badge +28
Dag wjb,

Hoe het wettelijk zit weet ik niet. Ik heb het artikel doorgenomen maar kan op basis daarvan niet zeggen of je gelijk hebt of niet. Ik ben hier dan ook niet aangenomen op mijn juridische kennis. Ik zal dit navragen binnen de organisatie, want ik ben er wel benieuwd naar.

Op korte termijn ben je daar niet mee geholpen. Mijn aanbod om een ander modem te sturen staat nog. Het klopt dat er op elk modem aangepaste firmware zit. Dit verschilt per modem en fabrikant. De Arcadyan V8 en de ZTE hebben een hoop meer configuratieopties dan de TG789. Of een inkomende VPN-verbinding werkt is me niet bekend. Dit wordt niet ondersteund en hier heb ik niet meer informatie over. Ik hoor graag of je nog wil testen met een ander modem. Ik ga in ieder geval aan de slag met artikel 7.4a en hoop je daar spoedig terugkoppeling over te kunnen geven.

Met vriendelijke groet,

Joran

Reputatie 7
Beste Joran,

Ik wil graag testen of de Arcadyan V8 wel correct te configureren is.

Het lijkt erop dat in dit modem een DMZ geconfigureerd kan worden waarvan ik hoop dat deze de vereiste protocollen wel toestaat. Ik heb wel gelezen dat er een probleem lijkt te zijn met de beschikbare bandbreedte voor devices die in de DMZ geplaatst zijn.

Een paar dagen geleden heb ik je een pm gestuurd met mijn postcode, huisnummer en naam contractant.

Ik hoop dat je me op korte termijn een Arcadyan V8 kunt sturen.

Mvgr,

wjb

Reputatie 7
Badge +28
Dag wjb,

De V8 is bij deze verstuurd. Mogelijk ontvang je deze morgen nog, anders dinsdag. Ik hoor graag hoe je bevindingen zijn met dit modem!

Met vriendelijke groet,

Joran

Reputatie 7
Hartelijk dank, ik laat je zeker weten of de V8 de oplossing is.

Zijn er nog ontwikkelingen te melden?

Reputatie 4
Badge +1
Door middel van DMZ is de firewall van die kpn rommel te omzeilen.

Je kunt dan een eigen internet router of firewall neerzetten en daarachter je netwerk plaatsen.

En ping activeren, dat werkt. http://stats.pingdom.com/1gc0neu40zfe/725701

En ik neem aan dat je Artikel 7.4a sectie 1 bedoelt?

Daar staat inderdaad in dat KPN niets mag belemmeren tenzij...

En één van die tenzijs (7.4a.1.b) kan zo worden gelezen dat ping geblokkeerd mag worden.

Jammer, ik dacht dat er eindelijk een opening was om van die rampzalige modems af te komen.

Reputatie 7
Helaas blijkt de Arcadyan VGV7519 ook niet de oplossing voor dit probleem en is het nog steeds niet mogelijk om van buiten (via internet) een VPN verbinding op te zetten die gebaseerd is op QuickVPN (Cisco IPSec).

Zoals eerder vermeld wordt de VPN tunnel volledig opgebouwd, maar komt de QuickVPN client vervolgens met de melding "The remote gateway is not responding. Do you want to wait?".

Dit is de laatste stap van de VPN tunnel opbouw, waarbij door middel van een Echo Request (ICMP) gecontroleerd wordt of de VPN tunnel correct is opgezet. Blijkbaar wordt dit Echo Request door de router geblokkeerd als deze via de WAN poort binnen komt. Ook het definiëren van de Cisco VPN server (Cisco RV180W Wireless-N Multifunctional VPN Firewall) als "Virtual DMZ host" biedt geen oplossing ook al wordt hier beweerd dat deze host een ongelimiteerde twee-weg verbinding met internet zou moeten bieden. (If you have a local client PC that cannot run an Internet application properly from behind the NAT firewall, then you can open the client up to unrestricted two-way Internet access by defining a Virtual DMZ Host.)

Het bovenstaande probleem is 100% te wijten aan de KPN router aangezien er vanaf een werkstation op het LAN succesvol een VPN verbinding kan worden opgezet met de Cisco VPN server door rechtstreeks het IP adres van de Cisco router te gebruiken. Wordt echter het WAN IP adres gebruikt, dan mislukt de opbouw van de VPN tunnel.

Beste KPN, kunnen jullie a.u.b. met een oplossing voor dit probleem komen.

Jullie hebben in de configuratie schermen (port mapping) zelfs standaard de IPSEC IKE mogelijkheid opgenomen (TCP&UDP 500,4500) die samen met de TCP poorten 443 en/of 60443 door QuickVPN gebruikt worden, echter het Echo request (ICMP) wordt blijkbaar geblokkeerd en lijkt de oorzaak van dit probleem te zijn. Ook deze moet geopend kunnen worden om een QuickVPN tunnel op te kunnen bouwen.

Voor de goede orde:

In mijn netwerk is de Cisco VPN server opgenomen met IP 192.168.2.252.

Op de router is het IP adres 192.168.2.252 vastgelegd als "Virtual DMZ Host" en daarmee zou de Cisco VPN router dus ongelimiteerd twee-weg toegang moeten hebben naar internet.

De door QuickVPN gebruikte TCP (443, 60443) en UDP (500, 4500) poorten zijn middels poort mapping toegewezen aan IP adres 192.168.2.252.

Deze poort mapping lijkt te functioneren immers als ik van buiten af in een browser https://mijn-WAN-IP-adres (=TCP 443) benader, dan kom ik netjes op de beheer pagina's van mijn Cisco VPN Server.

Als ik op een Windows 7 PC op mijn LAN een VPN verbinding opzet naar IP 192.168.2.252, dan gaat alles goed. Als ik echter op dezelfde PC een VPN verbinding wil opzetten naar mijn-WAN-IP-adres, dan mislukt het opzetten van de verbinding. Dit laatste is ook het geval als ik een PC buiten het LAN gebruik om een VPN verbinding op te zetten. De firewalls op deze Windows 7 PC's staan overigens open voor alle door Quick VPN gebruikte protocollen.

Ik hoop spoedig van jullie te mogen horen.

Reputatie 4
Badge +1
Ik volg iets niet.

Je schijft "Deze VPN tunnel wordt succesvol tot stand gebracht echter de laatste fase van het activeren van de tunnel is de verificatie van het LAN (thuis) door het versturen van een ping naar het interne adres van de Cisco VPN Server."

Wat heeft de VPN Client (in bedrijfnetwerk) er in dit geval aan om via de VPN een ping te sturen naar de VPN? Als dat niet werkt, is er toch geen tunnel?

Als er wel een tunnel is, dan is het toch niet nodig om achteraf nog eens een ping naar het WAN ip te sturen? KPN routers gaan hier never nooit niet op reageren, dat is zogenaamd onveilig. Die optie kennen ze gewoonweg niet meer. Maar die requests komen wel gewoon door de DMZ, dat had ik al aangetoond.

Als het een ping naar het bedrijf is, vanuit het bedrijf, via de vpn, dan zou dat netjes aan moeten komen. Want je kunt gewoon icmp gebruiken vanaf kpn verbindingen.

Als ik het mag samenvatten is de situatie als volgt:

Bedrijf -> Internet -> KPN Router -> VPN -> LAN netwerk.

( "->"= routering)

Waar de VPN in de DMZ van de KPN router staat.

Het bedrijf verbindt met de VPN thuis. Dit werkt. Echter kan het bedrijf dit niet verifieren omdat een ping verstuurd vanaf locatie x niet aankomt op locatie y.

Wat zijn nu locatie x en y?

En even ter verduidelijking, het LAN netwerk bevindt zich "naast" (zelfde subnet) de VPN of "achter" de vpn (d.m.v NAT)? 

(ik ben niet van kpn, maar misschien kan ik wel helpen, ik heb namelijk ook een VPN thuis, en dit werkt prima)

Reputatie 7
Beste KPN,

Het blijkt dat icmp verkeer geblokkeerd wordt door de KPN router, ook als er een "Virtual DMZ Host" gedefinieerd is waarmee een "ongelimiteerde" twee-weg internet verbinding mogelijk zou moeten zijn.

Kunnen jullie er voor zorgen dat icmp verkeer (o.a. Ping) doorgegeven worden aan de DMZ Host.

Alvast bedankt,

Onderstaand wat scenario's voor het opzetten van een VPN verbinding naar mijn Cisco VPN Server die als "virtual DMZ Host" gedefinieerd is die aantonen dat de KPN router de ping (icmp) blokkeert.

In alle onderstaande scenario's is de Cisco RV180W VPN Server als Virtual DMZ Host gedefinieerd op IP adress 192.168.2.252.

Scenario 1 (succesvol):

Succesful connection accessing WAN port of Cisco RV180W VPN Server directly on LAN

VPN Client (192.168.2.19) -> (192.168.2.252) Virtual DMZ Host = VPN Server (10.1.2.254)

2013/08/26 23:47:41 [status]OS Version: Windows 7

2013/08/26 23:47:41 [status]Windows Firewall Domain Profile Settings: ON

2013/08/26 23:47:41 [status]Windows Firewall Private Profile Settings: ON

2013/08/26 23:47:41 [status]Windows Firewall Public Profile Settings: ON

2013/08/26 23:47:42 [status]One network interface detected with IP address 192.168.2.19

2013/08/26 23:47:42 [status]Connecting...

2013/08/26 23:47:42 [debug]Input VPN Server Address = 192.168.2.252

2013/08/26 23:47:42 [status]Connecting to remote gateway with IP address: 192.168.2.252

2013/08/26 23:47:42 [status]Remote gateway was reached by https ...

2013/08/26 23:47:42 [status]Provisioning...

2013/08/26 23:47:52 [status]Success to connect.

2013/08/26 23:47:52 [status]Tunnel is configured. Ping test is about to start.

2013/08/26 23:47:52 [status]Verifying Network...

2013/08/26 23:47:57 [warning]Failed to ping remote VPN Router!

Na de tweede ping is VPN tunnel up and running...

2013/08/26 23:48:04 [status]Disconnecting...

2013/08/26 23:48:08 [status]Success to disconnect.

De tunnel wordt succesvol opgebouwd en de tweede ping is succesvol.

Scenario 2 (niet succesvol): 

Unsuccesful connection accessing WAN port of KPN router from PC on the LAN behind the KPN Router

VPN Client (192.168.2.19) -> (86.xxx.xxx.xxx) KPN Router (192.168.2.254) -> (192.168.2.252) Virtual DMZ Host = VPN Server (10.1.2.254)

2013/08/26 23:48:28 [status]OS Version: Windows 7

2013/08/26 23:48:28 [status]Windows Firewall Domain Profile Settings: ON

2013/08/26 23:48:28 [status]Windows Firewall Private Profile Settings: ON

2013/08/26 23:48:28 [status]Windows Firewall Public Profile Settings: ON

2013/08/26 23:48:28 [status]One network interface detected with IP address 192.168.2.19

2013/08/26 23:48:28 [status]Connecting...

2013/08/26 23:48:28 [debug]Input VPN Server Address = 86.xxx.xxx.xxx

2013/08/26 23:48:28 [status]Connecting to remote gateway with IP address: 86.xxx.xxx.xxx

2013/08/26 23:48:29 [status]Remote gateway was reached by https ...

2013/08/26 23:48:29 [status]Provisioning...

2013/08/26 23:48:38 [status]Success to connect.

2013/08/26 23:48:39 [status]Tunnel is configured. Ping test is about to start.

2013/08/26 23:48:39 [status]Verifying Network...

2013/08/26 23:48:44 [warning]Failed to ping remote VPN Router!

2013/08/26 23:48:47 [warning]Failed to ping remote VPN Router!

2013/08/26 23:48:50 [warning]Failed to ping remote VPN Router!

2013/08/26 23:48:53 [warning]Failed to ping remote VPN Router!

2013/08/26 23:48:56 [warning]Failed to ping remote VPN Router!

2013/08/26 23:49:08 [warning]Ping was blocked, which can be caused by an unexpected disconnect.

2013/08/26 23:49:11 [status]Disconnecting...

2013/08/26 23:49:15 [status]Success to disconnect.

Scenario 3 (niet succesvol):  

Unsuccesful connection accessing WAN port of KPN router from PC through the internet

VPN Client (10.1.1.103) -> (10.1.1.254) Cisco 1811 (77.xxx.xxx.xxx) -> Internet -> (86.xxx.xxx.xxx) KPN Router (192.168.2.254) -> (192.168.2.252) Virtual DMZ Host = VPN Server (10.1.2.254)

2013/08/27 00:01:22 [status]OS Version: Windows 7

2013/08/27 00:01:22 [status]Windows Firewall Domain Profile Settings: ON

2013/08/27 00:01:22 [status]Windows Firewall Private Profile Settings: ON

2013/08/27 00:01:22 [status]Windows Firewall Public Profile Settings: ON

2013/08/27 00:01:22 [status]One network interface detected with IP address 10.1.1.103

2013/08/27 00:01:22 [status]Connecting...

2013/08/27 00:01:22 [debug]Input VPN Server Address = 86.xxx.xxx.xxx

2013/08/27 00:01:22 [status]Connecting to remote gateway with IP address: 86.xxx.xxx.xxx

2013/08/27 00:01:28 [status]Remote gateway was reached by https ...

2013/08/27 00:01:28 [status]Provisioning...

2013/08/27 00:01:39 [status]Success to connect.

2013/08/27 00:01:39 [status]Tunnel is configured. Ping test is about to start.

2013/08/27 00:01:39 [status]Verifying Network...

2013/08/27 00:01:45 [warning]Failed to ping remote VPN Router!

2013/08/27 00:01:48 [warning]Failed to ping remote VPN Router!

2013/08/27 00:01:51 [warning]Failed to ping remote VPN Router!

2013/08/27 00:01:54 [warning]Failed to ping remote VPN Router!

2013/08/27 00:01:57 [warning]Failed to ping remote VPN Router!

2013/08/27 00:02:09 [warning]Ping was blocked, which can be caused by an unexpected disconnect.

2013/08/27 00:02:12 [status]Disconnecting...

2013/08/27 00:02:16 [status]Success to disconnect.

Ik heb ook "gewone" ping testen uitgevoerd om te zien of de Virtual DMZ Host te pingen is.

Dit is niet het geval via het internet: 

PING request to the public IP address of the KPN router through the internet with Virtual DMZ Host configured 

Microsoft Windows [Version 6.1.7601]

Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

ping 86.xxx.xxx.xxx

Pinging 86.xxx.xxx.xxx with 32 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Ping statistics for 86.xxx.xxx.xxx:

    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Dit is wel het geval via het IP adres (LAN) van de Vitrual DMZ Host: 

PING request to the internal IP address of the Virtual DMZ Host (Showing this server replies on ping requests.)

Microsoft Windows [versie 6.1.7601]

Copyright (c) 2009 Microsoft Corporation. Alle rechten voorbehouden.

ping 192.168.2.252

Pingen naar 192.168.2.252 met 32 bytes aan gegevens:

Antwoord van 192.168.2.252: bytes=32 tijd=4 ms TTL=64

Antwoord van 192.168.2.252: bytes=32 tijd=1 ms TTL=64

Antwoord van 192.168.2.252: bytes=32 tijd=2 ms TTL=64

Antwoord van 192.168.2.252: bytes=32 tijd=1 ms TTL=64

Ping-statistieken voor 192.168.2.252:

    Pakketten: verzonden = 4, ontvangen = 4, verloren = 0

    (0% verlies).

De gemiddelde tijd voor het uitvoeren van één bewerking in milliseconden:

    Minimum = 1ms, Maximum = 4ms, Gemiddelde = 2ms

Reputatie 4
Badge +1
Scenario 1:

Het heeft geen nut een VPN verbinding op te stellen naar je eigen LAN.

Scenario 2:

Hier heerst een subnet conflict. Er komt tweemaal 192.168.2.x in de route voor.

Scenario 3:

VPN Client (10.1.1.103) -> Gateway (10.1.1.254) -> Internet -> KPN Router -> VPN Server -> VPN netwerk.

Ik vermoed dat je setup hier niet goed is. Mijn KPN router (ZTE H220n) blokkeert namelijk geen ICMP pakketjes, en ik verwacht dat andere routers dat ook niet doen, in de DMZ.

Echter moet het apparaat in DMZ wel reageren op deze pakketjes, en hier loopt denk ik het mis.

Echter is mij nog steeds niet duidelijk wat je probeert te bereiken.

Wil je een Site-to-Site tunnel of wil je één enkel apparaat registeren in het bedrijfsnetwerk?

QuickVPN is namelijk user based software die inlogt op een Cisco RV180W in het bedrijfsnetwerk.

Niet andersom.

Reputatie 7
Ik word altijd vrolijk van mensen die mee willen denken, waarvoor dank.

Inderdaad verstuurt de quickvpn cliënt NA het opzetten van de tunnel een icmp echo request (ping) door de tunnel naar het LAN ip adres van de VPN router om te verifiëren of de tunnel succesvol is opgezet.

Op zich inderdaad overbodig, maar ja zo werkt de quickvpn cliënt nu eenmaal. (Er ligt een verzoek bij Cisco om deze stap over te slaan en "er vanuit te gaan" dat de tunnel correct is opgebouwd.)

Deze icmp echo request gaat dus door de tunnel naar het interne ip adres van de VPN router en niet naar het WAN ip adres van de VPN router.

In mijn volgende post zie je enkele loggings van door mij uitgevoerde testen, waaruit blijkt dat icmp echo request geblokkeerd worden, zelfs richting de DMZ Host en nog erger (teven ALLE regels in) binnen een VPN tunnel.

Ik heb voor de test ook een gewone PC als DMZ host gedefinieerd en van buiten af een ping gestuurd en ook deze komt niet aan.

Jij zegt dat jij van buiten af VPN verbindingen kan opzetten naar een apparaat achter de KPN router.

Kan hij mij aangeven welk type KPN router jij hebt en welk VPN type jij gebruikt?

Je geeft ook aan dat jij van buiten af de DMZ Host succesvol kan pingen.

Wat voor een apparaat is jouw DMZ Host?

Alvast bedankt.

Reputatie 4
Badge +1
Oke, de PING gaat dus door de tunnel naar de VPN server zijn LAN zijde.

Alle tussenliggende routers zouden dit niet KUNNEN filteren op ICMP, want het is immers een versleutelde tunnel. En eenmaal bij de VPN blijft het dus intern.

Kun je je huidige situatie schetsen, het is mij nog steeds niet compleet duidelijk waar precies de VPN zich bevindt ten opzichte van de LAN gebruikers en de KPN gateway.

Mijn situatie:

Ik heb de ZTE H220N Experiabox met DMZ op 192.168.2.1.

Op 192.168.2.1 zit de WAN zijde van een Netgear WNDR4000.

Markant detail: de Netgear heeft GEEN statisch ip ingesteld, en krijgt zijn ip van een reservering in de dhcp server, binnen de DHCP range* van de H220N.

Op de LAN zijde van deze Netgear (192.168.1.1) zit mijn netwerk, plus een (met WAN aangesloten) Cisco WRT320N met DD-WRT OpenVPN (WAN ip: 192.168.1.253, LAN range: 192.168.3.x).

Deze Cisco draait een PPTP VPN server als "proxy". Dit werkt.

De terugroutering vanaf het netwerk van de netgear werkt niet geheel vlekkeloos want de NAT van de WRT320N zit ertussen. Maar dat heb ik ook niet nodig op mijn iPhone. DD-WRT ondersteund het niet om de VPN op de LAN zijde te draaien. Ik verwacht jouw Cisco ook niet, omdat er immers routering nodig is. En dat vindt pas plaats in de NAT, tenzij er een managed switch in zit.

*Anders doen portforwards het niet, de h220n moet het apparaat een ip hebben toegekend.

Reputatie 7
 In deze post hoop ik duidelijk te maken wat de probleem is met de Arcadyan VGV7519 router van KPN en het opzetten van VPN verbindingen van buiten af.

Netwerk overzicht:

https://

Op het LAN achter de KPN router is een VPN server (192.168.2.252) opgenomen die als "Virtual DMZ Host" gedefinieerd is.

Achter deze VPN server bevindt zich het beschermde netwerk (10.2.1.xxx) waar zich servers bevinden die ALLEEN via VPN verbindingen benaderd mogen worden. (Jeroen: daarom dus ook een VPN Cliënt op het LAN aangezien het LAN gebruikt wordt door ons gezin en deze niet zomaar de servers mogen benaderen.)

De VPN verbinding tussen het kantoor en dit beschermde netwerk is gebaseerd op een site-to-site VPN en levert geen problemen.

Voor verbindingen vanaf andere lokaties moet de QUICKVPN Client software gebruikt worden.

Het opbouwen van een QUICKVPN verbinding vanaf de VPN Cliënt op het LAN rechtstreeks naar de VPN Server (dus via adres 192.168.2.252) gaat vlekkeloos. Hiermee wil ik aangeven dat de configuratie van de VPN Server blijkbaar correct is.

Het opbouwen van een QUICKVPN verbinding via het WAN IP adres van de KPN Router (86.xxx.xxx.xxx) is echter niet succesvol.

Uit de loggings (zie voorgaande post) kan geconcludeerd worden dat het icmp echo request (ping) vanuit een VPN Cliënt buiten het LAN niet doorgelaten wordt. (Dit is overigens een ping BINNEN de dan al opgebouwde tunnel naar het interne adres van de VPN Server (10.2.1.254) en zelfs die wordt door de KPN router geblokkeerd (tegen alle regels in, immers dit geschiedt BINNEN de tunnel).

Uiteraard heb ik ook gewone ping testen uitgevoerd.

Een ping vanaf een werkstation op het LAN naar het ip adres van de VPN Server (192.168.2.252) wordt keurig gereplied. Dit zou dan dus ook het geval moeten zijn op het WAN IP adres (86.xxx.xxx.xxx) van de KPN router, immers de VPN Server is de "Virtual DMZ Host". Helaas is de realiteit anders en is een ping naar het WAN IP adres niet succesvol.

Jeroen geeft aan dat zijn router wel icmp pakketjes door laat en dat een ping op het WAN IP adres van zijn router dus wel succesvol is.

Beste KPN,

Edit 

Wat ik vraag is om icmp verkeer door te laten naar het DMZ op de Arcadyan VGV7519 zoals dat blijkbaar ook op de ZTE H220n het geval is.

Wat ik vraag is om naast het TCP en UDP verkeer ook het IP verkeer door te laten naar het DMZ op de Arcadyan VGV7519 zoals dat blijkbaar ook op de ZTE H220n het geval is. 

Reputatie 4
Badge +1
De H220N is niet aan te raden voor glasvezel wegens het gebrek aan Gigabit LAN. De maximale snelheid is dus beperkt tot maximaal 100 Mbit, met goed geluk.

De situatie is inmiddels duidelijk, echter geloof ik nog steeds niet dat DMZ niet goed werkt.

Het lijkt namelijk zo dat de control verbinding van de QuickVPN prima werkt, echter de tunnel zelf doet het niet.

Als ik het zo inschat ben je wel voorzien van de nodig kennis.

Daarom stel ik voor om alle benodigde portforwards eens te verifieren. Zo kun je misschien ook kijken of ICMP binnen komt.

Je kunt daarvoor deze tool gebruiken Hercules: http://www.hw-group.com/products/hercules/index_en.html

Start de tool en ga naar de tab TCP Server, vul onder "Server status" de poort in die je wilt testen, en start de server door op Listen te klikken. 

Ga vervolgens naar een website zoals http://www.canyouseeme.org/ vul de poort weer in, en klik op Check.

Eventueel kan je ook hercules als TCP Client gebruiken via een andere verbinding (op ander pc), via je mobiele internet op de iPhone bijvoorbeeld.

Wanneer de poort juist geopend is verschijnt er onder de Close knop in het veld Client Connection Status een nieuwe regel met "22:47:11: 107.xx.xxx.xx Client connected".

 

Deze tool kan ook UDP poorten testen.

 

Test hiermee alle benodige poorten, vaak blijkt namelijk dat er hier iets fout zit.

Zoals ook bij mijn OpenVPN proef.

 

Edit:

Opmerkelijk, een ICMP Echo Request (die kan hercules tool ook sturen) komt ook niet aan via LocalHost, ik vermoed dat er iets fout staat in de firewall van Windows 7.

Reputatie 7
Beste Jeroen,

Ik heb inderdaad aardig wat ervaring met het opzetten van VPN verbindingen.

Vanuit ons kantoor hebben wij tientallen site-to-site verbindingen naar onze klanten om support te kunnen leveren op onze software. Daarnaast kunnen onze medewerkers "on the road" vanaf hun Windows, Android of iOS device zonder problemen VPN verbindingen opzetten naar ons kantoor.

Ondertussen ben ik er wel vrijwel 100% van overtuigd dat het icmp verkeer door de Arcadyan VGV7519 geblokkeerd wordt, ongeacht het wel of niet definiëren van een "Virtual DMZ Host".

Alle TCP en UDP poorten die ik forward naar de "Virtual DMZ Host" functioneren ook naar behoren. Het icmp verkeer wordt echter categorisch geblokkeerd!

Uit de loggings (zie een paar posts terug) blijkt ook dat het opbouwen/configureren de tunnel succesvol is. (Mits ik de gebruikte terminologie van Cisco mag geloven)

De poorten TCP 443 en UDP 500,4500 zijn dus blijkbaar succesvol naar naar de DMZ "geforward".

Reputatie 4
Badge +1
Ik heb me nog eens verdiept op het functioneren van QVPN en kom toch tot de conclusie dat er één van de volgende problemen aanwezig moet zijn:

- Windows 7 is niet juist geconfigureerd.

-- De IPsec service draait niet

-- of de firewall (die aan moet) laat geen icmp door.

- Niet de juiste set van poorten kan worden gebruikt door de VPN op locatie in de modem van kpn. Dit kunnen inkomende of uitgaande poorten zijn. Echter is de tunnelonderhandeling en authenticatie gelukt via waarschijnlijk poort 443. Je had ook al een site-to-site vpn draaien, is het niet mogelijk dat dit conflicteert?

- Het ICMP Echo Request word niet de tunnel in geroute.

Waarom het niet aan de modem zou moeten liggen is heel eenvoudig. De client stuurt een ICMP Echo Request door de tunnel, en als deze netjes voorzien is van een certificaat en deze is versleuteld dan kan geen man-in-the-middle, noch modem herkennen dat hier een ICMP pakket in zit. Dat is het hele idee van die tunnel toch?

Nu ik erover nadenk is het helemaal niet gebruikelijk een Echo Request vanaf WAN naar een apparaat in LAN te sturen. De router moet het pakket expliciet door routeren. Terwijl het pakket initieel voor hem bedoeld was. 

 

Staan de tijden wel goed. Want dat wil soms ook moeilijk doen, een paar minuten verschil en je certificaat is fout.

De meeste glasvezels verbindingen zijn toch maar 100Mbit en dan voldoet de ZTE H220 ook gewoon.

Alleen intern heb je dan geen gigabit.

Maar binnenkort komt KPN met de ZTE H368N en deze heeft wel gigibit.

Alle KPN welke in de afgelopen jaren heb gehad (3 types) blokkeren ICMP. Bij KPN kun je daarom geen ipv6 tunnel van Hurricane aanvragen.

Bij glasvezel kun je naast via DMZ en dan een aparte router ook nog via een switch de vlans opdelen. Telefoon naar EB, internet naar eigen router en tv rechtstreeks vanaf de switch. Dit wordt natuurlijk niet ondersteund door KPN maar werkt wel.

Reputatie 7
Hoi Jeroen

Dank voor deze reply, de oorzaak van het probleem is nu duidelijk...

Je geeft aan dat er één van de volgende problemen moet zijn:

- Windows 7 is niet juist geconfigureerd.

- De IPsec service draait niet.

- of de firewall (die aan moet) laat geen icmp door.

Deze oorzaken kan ik uitsluiten immers dan zou ik vanaf die PC geen enkele QVPN verbinding kunnen opbouwen en dat kan ik wel. (Bijvoorbeeld rechtstreeks naar het ip adres van de VPN router (192.168.2.252), maar ook naar QVPN servers van enkele van mijn klanten.)

- Niet de juiste set van poorten kan worden gebruikt door de VPN op locatie in de modem van kpn. Dit kunnen inkomende of uitgaande poorten zijn. Echter is de tunnelonderhandeling en authenticatie gelukt via waarschijnlijk poort 443. Je had ook al een site-to-site vpn draaien, is het niet mogelijk dat dit conflicteert?

De site-to-site VPN wordt vanaf de VPN server (in het thuis netwerk) geïnitieerd. Dit betreft dus een uitgaande VPN verbinding voor de KPN router en daar zijn überhaupt geen problemen mee.

Voor inkomende VPN verbindingen worden de UDP poorten 500 en 4500 en de TCP poort 443 naar de VPN Server geforward. Ook daar zit het probleem niet in aangezien de VPN tunnel correct opgebouwd/geconfigureerd wordt.

Blijft over:

- Het ICMP Echo Request word niet de tunnel in geroute.

Nu hier wordt het tricky, immers het betreft hier een ICMP Echo Request binnen de tunnel en zoals je terecht stelt kan de router dit helemaal niet herkennen immers het is versleuteld.

QVPN en vele andere VPN's maken gebruik van zogenaamde ESP (Encapsulation Security Payload) tunnels.

Dat betekent dat de versleutelde pakketten voorzien worden van een onversleutelde IP Header en ESP Header. Dit is puur voor de routering van de versleutelde pakketjes in de tunnel.

Wat de router dus ziet zijn pakketjes voor IP protocol 50 (ESP = IP protocol 50 (0x32)).

(http://en.wikipedia.org/wiki/List_of_IP_protocol_numbers)

Daar lijkt het dus nu mis te gaan, de router lijkt alleen TCP en UDP door te routeren naar de "Virtual DMZ Host", maar niet enig ander verkeer zoals IP verkeer.

Dit verklaart ook waarom een eenvoudige ping van buitenaf naar de KPN router (en dus de "Virtual DMZ Host") geen resultaat heeft immers ook een icmp echo request is een IP protocol (0x01).

Blijkbaar geeft jouw ZTE H220n wel netjes IP verkeer door aan de DMZ, maar de Arcadyan VGV7519 dus niet. :(

De KPN router zal ook IP verkeer moeten gaan doorgeven aan de "Virtual DMZ Host" om dit probleem te verhelpen.

Wie van het KPN Webcare team neemt eens contact met mij op... ...Joran HELP!

Je hebt glasvezel? Misschien moet je zoals Space al aangeeft toch eens denken aan een managed switch + eigen router. Dan blijf je alleen voor VoIP zitten met die V8 en kun je de rest van je netwerk naar eigen wens inrichten. Ik ben van mening dat het niet nodig hoeft te zijn, maar ik denk wel dat het de meest betrouwbare optie is.

Zie bijvoorbeeld: http://gathering.tweakers.net/forum/list_message/37416132#37416132

Reputatie 4
Badge +1
Je eigen router configureren voor glasvezel lijkt me in jouw situatie het beste als je niet weg wilt bij kpn. 

Dit is wel lastig, maar op tweakers.net zijn er mensen die het doen.

Hoewel overstappen naar de kabel misschien een beter alternatief is, bij kabelproviders is het niet verplicht hun router te gebruiken, enkel het modem. Deze apparaten kan je in bridge zetten, en dan tast hij het verkeer niet meer aan. Je eigen router krijgt dan een WAN ip op internet.

Jammer van je glasvezel, maar je kunt tenminste wel echt gebruik maken van je verbinding.

Maar misschien biedt KPN je nog een ZTE H220N aan (of een andere oplossing), ik hoop het voor je.

Reputatie 7
Ik heb nog wel een Cisco 877W staan die met een paar eenvoudige aanpassingen tussen het glasvezel modem en de KPN router geplaatst kan worden. (Methode 2 http://netwerkje.com/eigen-router)

Dit lijkt me niet zo spannend om te realiseren.

Het stuit me echter tegen de borst om daarmee alleen mijzelf te helpen en niet al die andere KPN gebruikers die tegen soortgelijke problemen aanlopen.

Er zitten wel wat pro's en contra's aan deze "oplossing":

+ Geen beheer van de internet settings (firewall / port forwarding / protocol blocking) door KPN

+ Veel beter WiFi bereik van de Cisco 877W t.o.v. de VGV7519 van KPN

+ Zeer uitgebreide configuratie mogelijkheden op basis van Cisco IOS

+ Waarschijnlijk een betere afwikkeling van internet storingen, waarbij het nu zo is dat soms de verbinding pas weer opgebouwd kan worden nadat het glasvezel modem even van de stroom af is geweest (Een ander groot issue bij mijn glasvezelaansluiting en met de alarminstallatie via Internet ook niet echt geruststellend) 

- LAN op 100Mb i.p.v. 1Gb (en anders een nieuwe Router aanschaffen)

- Complexere infrastructuur en één extra apparaat in de meterkast en aangesloten op de UPS (noodstroom).

- Geen ondersteuning van KPN in die situaties dat ik in het buitenland ben en mijn gezin problemen ondervindt met Internet, televisie of telefonie

- Geen firmware updates meer van de KPN router (is immers niet meer de benaderen door KPN)

- Geen beheer van SIP instellingen voor telefonie in het geval dat er door KPN aanpassingen doorgevoerd worden

Mocht KPN niet op korte termijn met een bevredigende oplossing komen, dan zal ik genoodzaakt zijn om deze "oplossing" te gaan implementeren.

Reputatie 7
Beste KPN,

Hierbij nogmaals het verzoek om inkomend IP verkeer voor het Protocol 0x32 (ESP) door de firewall op mijn router (Experia V8 = Arcadyan VGV7519) door te laten en te forwarden naar de "Virtual DMZ Host".

Er zijn vele protocollen (Zie: http://en.wikipedia.org/wiki/List_of_IP_protocol_numbers), waarvan firewall op de router er inkomend maar twee doorlaat, te weten TCP (0x06) en UDP (0x11).

Zoals jullie vast wel weten, bepalen de meeste firewalls aan de hand van het protocol veld in de IP Header het type verkeer. (Zie onderstaand.)

https://

Dit weerhoudt gebruikers van het KPN netwerk er -onder andere- van om inkomende VPN verbindingen op te bouwen. Vele VPN verbindingen zijn gebaseerd op zogenaamde ESP tunnels, waarbij het protocol dat in de IP header wordt aangeduid dus het ESP protocol is.

Aangezien alleen TCP en UPD verkeer doorgelaten wordt, worden pakketjes voor de VPN tunnel dus geweigerd en daarmee is de VPN tunnel dus niet beschikbaar.

Tot mijn spijt heb ik ook een klacht bij klantenservice ingediend, aangezien dit issue nu al vele maanden loopt en het er op lijkt dat je als klant alleen maar een antwoord krijgt als er een kant en klare "oplossing" voorhanden is. Als die er niet is, of de kennis is bij jullie niet aanwezig, dan heerst er een grote radiostilte en laten jullie de klant in het ongewis. Geloof me, slecht bericht is nog altijd beter dan geen bericht. Trek daar lering uit, want één van de meest gehoorde en gelezen klachten over KPN als organisatie is het gebrek aan communicatie.

Ik hoop dan ook heel spoedig iets van jullie te vernemen zodat we de next steps kunnen bepalen.

Overigens belooft het antwoord op mijn mail naar klantenservice dat er morgen (2 september) of overmorgen (3 september) contact opgenomen zal worden, maar het verleden heeft mij geleerd dat ik daar ook niet echt op kan vertrouwen.

Mvgr,

wjb

Reputatie 7
Badge +28
Beste wjb,

Ik heb inderdaad geen kant en klaar antwoord. De reden dat ik verlaat reageer is omdat ik op vakantie was, ik zie helaas nu pas het privébericht. Excuses, dat had beter opgevangen moeten worden.

Je hebt een zeer duidelijke en uitgebreide schets gemaakt van het probleem welke ik door ga spelen naar het firmwarebeheer. Of en wanneer dit aangepast gaat worden kan ik nog niet aangeven.

Ik wil intussen mijn best doen om een ZTE modem naar je toe te sturen. Deze wordt inmiddels niet meer standaard uitgeleverd, maar ik ga dit via een omweg alsnog proberen te regelen. Als hiervan een voorraad is verwacht ik dat je dit model deze week ontvangt. Ik zal dit in ieder geval in een privébericht bevestigen zodra het geregeld is.

Met vriendelijke groet,

Joran

Reageer