Beantwoord

VPN Passthrough

  • 26 april 2013
  • 63 reacties
  • 23015 keer bekeken


Toon eerste bericht

63 reacties

Reputatie 5
Badge +5
nee, de klantenservice kan niet meer dan jij in het modem. vpn passthrough vinkjes staan aan in de draytek? ;)

je kunt proberen de betreffende poorten te forwarden in de experia box naar het ip van de draytek en dmz uit te schakelen?

via poort-check sites laat-ie zien dat de poort op dat moment 'closed' is maar dit is niet zo in werkelijkheid. 

Reputatie 7
Hoi David_Libido,

Allereerst een paar opmerkingen:

  • Een Experia Box blokkeert niets richting DMZ m.u.v. TCP poort 8085 die gereserveerd is voor het beheren van de Experia Box.
  • Ook een ping wordt dus niet geblokkeerd door de Experia Box. Als de DMZ host (in jouw geval de Draytek) geconfigureerd is om te antwoorden op pings vanaf het WAN, dan zal dit dwars door de Experia Box ook vanaf Internet werken.
  • Naar een DMZ host hoeven nooit port-forwardings gedefinieerd te worden. Sterker nog, naar een DMZ host mogen geen port-forwardings gedefinieerd worden.
Laat me raden, je probeert waarschijnlijk een VPN tunnel op basis van IPSec op te zetten, klopt dat?

Als dat het geval is, dan heb je nu last van "double natting" waardoor vele VPN Cliënts geen verbinding kunnen opzetten.

De VPN cliënts die wel om kunnen gaan met "double natting" zijn:

Shrew Soft VPN cliënt for Windows. (gratis)

NCP VPN cliënt for Android. (niet gratis)

Ik heb tot nu toe geen enkele andere VPN cliënt gevonden die dit ook kan.

Reputatie 4
Badge +1
Ik heb een Experiabox V8 een Netgear (in dmz) en een Synology met een L2TP/Ipsec vpn server.

Werkt prima. Evenals OpenVPN en PPTP.

Met Windows kan je geen l2tp vpn verbinding maken totdat je een regedit uitvoert.

Als ik het goed heb onthouden heeft dit te maken met het veld: AssumeUDPEncapsulationContextOnSendRule

Reputatie 7
Een Synology NAS is ook geen NAT device.

Hiermee heb je dus geen last van "double natting".

Een Synology NAS kan zelfs zonder problemen terug routeren naar Internet als vanaf Internet een VPN verbinding tot stand gebracht is.

Ik maak daar dankbaar gebruik van aangezien het daarmee mogelijk is om overal ter wereld mijn KPN iTV te gebruiken.

Voor een tweede router achter de Experia Box ligt dit echter anders.

IPv4 routers die niet in bridge mode staan zijn NAT devices en introduceren daardoor double natting.

Ik heb ze hier allemaal draaien.

Een tweede router (Cisco RV180W) voor mijn zakelijk netwerk met site-to-site VPN richting mijn kantoor en IPSec VPN voor Windows en Android cliënts.

Een Synology NAS met VPN server voor mijn privé netwerk om overal ter wereld bijvoorbeeld KPN iTV te kunnen kijken.

Reputatie 4
Badge +1
Mogelijk heb je over het woordje netgear heen gelezen. Maar het gaat om een Netgear WNDR4000. 

Deze voert toch echt NAT uit, net als de Experiabox. Hoewel dubbel nat correct ingesteld eigenlijk helemaal geen probleem mag vormen, doet dat het toch.

Aangezien KPN routers levert waarbij je een zeer beparkt aantal aan instellingen hebt, zal de KPN router in de toekomst nog steeds de eerste schuldige blijven. Pas als KPN bridge modus gaat ondersteunen zoals de kabelproviders dat doen, zal dit verminderen.

Reputatie 7
Staat die Netgear in router mode of in bridge mode?

Reputatie 4
Badge +1
Open-NAT mode. Van 192.168.2.1 naar 192.168.1.0/24.

Reputatie 7
Zie volgend bericht.

Reputatie 7
Dat "double natting" roet in het eten gooit ligt niet zozeer aan de routers, maar aan het (terecht) streng beveiligde protocol om een IPSec VPN tunnel op te bouwen.

Als laatste stap in het opbouwen van een IPSec VPN tunnel wordt door de tunnel een ping gestuurd naar het IP adres waarvoor de tunnel initieel werd opgezet. (Het publieke (WAN) IP adres van de Experia Box.)

Als er geen antwoord ontvangen wordt op deze ping (zoals bij double natting) dan wordt de VPN tunnel verbroken, immers de VPN zou "gekaapt" kunnen zijn door een "man-in-the-middle" attack.

Op zich dus een prima mechanisme, maar blokkerend bij "double natting", immers:

Een VPN server stelt normaliter alleen het achterliggende LAN subnet beschikbaar en het WAN IP adres van de VPN server zelf.

Bij "double natting" is het WAN IP adres van de VPN server echter een 192.168.2.xxx adres en niet het WAN (publieke) IP adres van de Experia Box. De ping zal dus mislukken omdat het WAN (publieke) IP adres van de Experia Box niet bereikbaar is binnen de VPN tunnel.

Waarom werkt een L2TP/IPSec VPN tunnel dan wel met "double natting" en een Synology NAS?

In een voorgaande post van mij gaf ik aan dat een Synology NAS zelfs zonder problemen binnen een VPN tunnel terug kan routeren naar Internet en dat ik daar dankbaar gebruik van maak.

Dat is precies waardoor het WAN (publieke) IP adres van de Experia Box nu dus wel binnen de VPN tunnel bereikbaar is en de ping dus zal slagen.

De door mij aangehaalde VPN cliënts slaan de stap om het WAN (publieke) IP adres binnen de VPN tunnel te pingen over (iets minder veilig), maar zijn daardoor wel in staat om VPN tunnels op te bouwen door meerdere natting devices heen.

Ok duidelijk, bedankt voor de uitleg. Het heeft er dus niets mee te maken dat de firewall op de Experiabox niet uitschakelbaar is? De klantenservice was wel bereid deze uit te zetten namelijk.

Reputatie 7
Klopt, dit heeft niets met de firewall op de Experia Box te maken.

Een DMZ Host staat per definitie buiten de firewall en wijzigen van de firewall heeft dan ook geen enkele invloed hierop.

Iedereen die zijn firewall anders dan op high wil hebben moet eens goed nadenken waarom.

Ik zie geen enkel voordeel en zou "verlaging" van de firewall dan ook ten strengste afraden.

A) Statefull package inspection is beter dan Stateless package inspection en heeft geen enkele invloed op welke poorten er al dan niet doorgelaten worden door de firewall.

😎 Het laten reageren van jouw router op een ping vanaf Internet is een doodzonde, nooit doen.

C) Het uitzetten van de firewall is alleen voor mensen die "levensmoe" zijn. ;)

Dus: Firewall moet wat mij betreft altijd op High staan.

wjb schreef op 26 aug '13 om 00:02u
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.

 
Is anno 29-1-2016  nu de VGV7519  wel geschikt om hierachter een VPN server, in mijn geval Zywall USG 20,  te zetten?

ik heb modem versie: 

Runtime Code Version:  02.00.135W4 (31.07.2015-15:35:48)
Boot Code Version:  v3.00.06c
ADSL Modem Code Version: 5.7.1.15.1.1

Ik wil graag L2TP IPSEC gebruiken. Conform het forum hoef ik alleen DMZ in te stellen met IP van VPN server.

ICMP door laten op WAN aanvinken.

Of zijn er dan nog protocollen die toch nog geblokeerd worden?

Reputatie 4
Badge +1
Zojuist even getest vanaf m'n werk.

Runtime Code Version:  02.00.135 (24.07.2015-15:45:22)
Boot Code Version:  v3.00.06c

(glas)

Zonder dmz maar met deze forward naar mijn tweede router.

UDP 500,1701,4500

Ik ervaar alleen vaak wel problemen als de verbinding verloren raakt zonder netjes af te melden. Kennelijken blijven de poorten dan steken en moet je wachten tot ze verlopen zijn om het opnieuw te proberen.

Daarom gebruik ik doorgaans OpenVPN, want dat werkt altijd.

Je moet wel een wijziging maken in windows (als client) om het te laten werken.

Reageer