Debuggen van een VPN-verbinding
referentie Z069O
Dit document is bedoeld om oplossingen voor de meest voorkomende VPN problemen aan te dragen en om support@valadis.nl (of de fabrikant) van voldoende gegevens te voorzien om de problemen te kunnen helpen oplossen. (ongeveer 80% van de bij ons aangebrachte problemen met het niet tot stand komen van VPN kunnen middels dit document worden opgelost.)
Het document heeft betrekking op VPN verbindingen van en/of naar de ZyXEL ZyWall routers en Prestige routers met VPN ondersteuning. Dus ook voor verbindigen van VPN cliënten naar ZyWall en Prestige routers met VPN ondersteuning.
Inhoud:
- Veel voorkomende problemen:
- De tunnel komt niet op, (want) er gebeurt aan de zendende kant helemaal niets.
- De tunnel komt op, maar er gaat geen verkeer doorheen.
- De tunnel komt niet op en er staan NOTFY regels in de (webpagina)log.
NOTFY:ERR_PAYLOAD_TYPE.
- De tunnel komt niet op en er staan in de router die de verbinding moet gaan opbouwen uitsluitend(!) IKE Packet retransmit regels in de (webpagina)log.
- De tunnel komt niet op, en er staan meldingen Resv ID: SINGLE/SUBNET/REMOTE, vs My Remote, !!Verifing remote failed in de (webpagina)log.
- De tunnel komt op, maar mijn LAN verbinding is weg!
- De tunnel komt op, er gaat data doorheen, maar na verloop van tijd komt er geen data meer doorheen en blijkt maar nog in een van de twee routers de tunnel in het overzicht te staan!
- Ik kan alles door de VPN-tunnel, maar ik kan niet bij een op een Windows machine gedeelde map of printer.
- De tunnel komt op, maar dan is er geen Internet meer!
- De tunnel komt niet op en ik zie in de log wel een aantal IKE packetjes heen en weer gaan (Send:[KE][NONCE], Recv:[SA][VID][VID], Send:[SA][VID][VID]) maar daarna(!) alleen nog maar IKE Packet Retransmits.
- De tunnel komt soms op, komt niet altijd meteen terug na het afvallen, of valt (schijnbaar) periodiek weg.
- De tunnel komt niet op en er staat Rule [x] Verifying Local ID failed: gevolgd door !! unsupported local ID Type: [x]
- De VPN-Checklist
- Wat moet er in de E-mail? Hierbij blijkt nog wat uitleg over het waarom - we zaken in de e-mail willen zien - te moeten. Soms krijgen we de klacht n.a.v. de vermelde lijst dat het "bijna niet te doen is" om al de gevraagde de screendumps te maken. Dus krijgen we configuratiebestanden (waar we nog niet om gevraagd hebben), of IP-adressen zodat we zelf in routers kunnen kijken (waar we dus niet om gevraagd hebben).
Maar u moet zich realiseren dat het voor ons bijna niet te doen is om configuraties van klanten bij ons in routers te flashen. Er zijn te veel verschillende firmwares (die men vaak vergeet te vermelden) die bij ons naast het er in flashen van de configuratie vaak nog eerst het flashen van dezelfde firmware vereisen. Vervolgens blijkt dan het wachtwoord geen 1234 te zijn (nee wij hebben geen achterdeur).
Wij willen ook niet in routers van klanten (van klanten) wroeten. Want als wij in de router kunnen komen en er vervolgens iets anders mis gaat, dan wordt het te makkelijk om ons als zondebok aan te wijzen.
In beide gevallen is er geen of minimale correspondentie zodat we later niet er nog eens naar kunnen kijken. Verder is het voor ons noodzakelijk dat de installateurs er ook wat van leren en dat lukt niet als wij alles doen. Wij hopen eigenlijk dat bij het nalopen van dit document het probleem door de installateur wordt gevonden.
- Waar vind ik de (webpagina)log?
- Hoe doe ik via Telnet de IPsec debug procedure?
Andere relevante links:
Veel voorkomende problemen
Met de zendende kant bedoelen we de router waar in de gegeven situatie de VPN vandaag geinitieerd wordt. Met de ontvangende kant bedoelen we de router waar de verbinding naar toe wordt opgezet.
- Symptoom: De tunnel komt niet op, (want) er gebeurt aan de zendende kant helemaal niets.
Oorzaak 1: Foute routering, de computers hebben geen of een andere router als (default) gateway.
Oplossing 1: Pas de gateway instellingen van de computers aan.
Oorzaak 2: De betreffende tunnel is niet als actief ingesteld in het profiel.
Oplossing 2: Pas de instelling in het profiel aan..
Oorzaak 3: Er wordt verondersteld dat de "keep-alive" zelf een verbinding gaat forceren.
Oplossing 3: "Keep-alive" is niet hetzelfde als "always on" of "nailed-up". "Keep alive" zal geen verbinding forceren. Alleen maar nadat er een verbinding is opgebouwd er voor (proberen te) zorgen dat de SA's (Security Associations) bij het verlopen ververst worden. U moet zelf een verbinding forceren met bijvoorbeeld een ping of met Telnet in de CLI.
- Symptoom: De tunnel komt op, maar er gaat geen verkeer doorheen.
Oorzaak 1: De meest waarschijnlijke oorzaak is dat het IKE (UDP poort 500) verkeer wel op de VPN-router komt, maar het ESP (Protocol 50) verkeer niet. Dit ligt dan meestal aan het type, de firmware of de instellingen van het gebruikte modem. In theorie zou het nog kunnen dat (apparatuur van) de ISP het ESP verkeer blokkeert, maar we hebben dat nooit vastgesteld.
Oplossing 1a: Controleer of de gebruikte modem wel IPsec ESP verkeer ondersteunen. Controleer of de gebruikte firmware het ondersteunt. Controleer of het modem het kan en de juiste instellingen heeft. (Zie VPN pass-through.)
Oplossing 1b: Stel de gebruikte VPN apparatuur in om NAT Traversal (NAT-T) te gebruiken. Dit moet aan beide zijden. Helaas is dit geen oplossing wanneer u nog een typen Prestige heeft die geen NAT-T ondersteun. De recente versies van de Greenbow en de ZyXEL Secure Clients schakelen automatisch NAT-T in. Na het ischakelen van NAT-T wordt er geen ESP meer gebruikt maar blijft het allemaal UDP verkeer (van of naar poort 500). Het nadeel van NAT-T gebruiken is dat het minder efficient is, doordat de IP-overhead bij NAT-T net wat groter is dan bij gebruik van ESP.
Oorzaak 2: RIP staat aan en verstoort de routeringen.
Oplossing 2: Controleer in alle routers (dus ook andere routers in de betrokken netwerken) of RIP uit staat en zet het uit wanneer het aan staat. Controleer de routering in de computers (bijvoorbeeld met route print in een DOS-box.)
Oorzaak 3: De internet gateway van de router (voor een ZyWall kan dat een DSL of kabel router zijn) is niet correct ingesteld of is onbereikbaar.
Oplossing 3: Stel de gateway correct in.
Oorzaak 4: U gebruikt (KPN) UMTS/GPRS met de "fast internet" instelling.
Oplossing 4: Via het programma "Dashboard" waar de MTS/GPRSkaart van KPN mee werkt kan via het optie-menu de snelheid ingesteld worden. De keuze is tussen "fast internet" en "internet". Dit moet zijn "internet". Let op: voor het wisselen van moden naar UMTS/GPRS wel eerst de Greenbow-VPN worden af gesloten, anders wordt de tunnel niet meer active gemaakt.
Oorzaak 5: Bij NAT Server setup staat de default server geconfigureerd. Dat kan er voor zorgen dat ESP verkeer niet wordt ontsleuteld, maar versleuteld wordt doorgestuurd naar de ingestelde server. Het is mogelijk dat u hierbij in de firewall logging ziet dat ESP verkeer van WAN naar LAN (of DMZ) wordt geblokkeerd.
Oplossing 5: Gebruik geen default server, maar geef in een van de normale regels een bereik op van 0 - 499 en 501 - 65535. Via de eWC/WebGui (IP-adres 192.168.1.33 is uiteraard slechts een voorbeeld)):
| |
NAT - Edit SUA/NAT Server Set |
|
|
|
| |
Via de eWC/webGui:
Menu 15.2 - NAT Server Setup
Rule Start Port No. End Port No. IP Address
---------------------------------------------------
1. Default Default 0.0.0.0
2. 0 499 192.168.1.33
3. 501 65535 192.168.1.33 |
Oorzaak 6: TCP MSS wordt voor de tunnel op 0 ingesteld, dat betekent dat er maximaal 0 bytes aan data in elk pakketje zitten... In de log wordt dit gemeld. Helaas wordt het niet altijd gemeld dat de TCP MSS na de tot standkoming weer wordt opgehoogd naar een normale waarde.
Oplossing 6: (Eigenlijk een work-around) Stel de TCP MSS handmatig in (in het voorbeeld wordt 1400 gebruikt, maar 1358 is waarschijlijk de juiste waarde.) door naar de CLI van de router te gaan (menu 24.8) en daar de volgende opdrachten in te tikken:
Copyright (c) 1994 - 2003 ZyXEL Communications Corp.
P652HW> ip adjmss om de huidige waarde te tonen
Adjust TCP MSS is 0 MSS = 0, betekent automatisch bepalen
P652HW> ip adjmss 1400 tik de opdracht
Adjust TCP MSS is 1400
Als het werkt dan kunt u als volgt (weer in de CLI) de instelling permanent maken:
P652HW> sys edit autoexec.net
EDIT cmd: q(uit) x(save & exit) i(nsert after) d(elete) r(eplace) n(ext)
: ip adjmss 1400 tik de opdracht
ppp ipcp compress off
sys wdog sw on
sys errctl 0
sys trcl level 5
sys trcl type 1180
sys trcp cr 64 96
sys trcl sw off
sys trcp sw off
ip tcp mss 512
ip tcp limit 2
ip tcp irtt 65000
ip tcp window 2
ip tcp ceiling 6000
ip rip activate
ip rip merge on
ip icmp discovery enif0 off
bridge mode 1
sys quick enable
wan adsl rate off
EOF
P652HW> sys view autoexec.net kijk of het commando is opgeslagen
ip adjmss 1400
ppp ipcp compress off
sys wdog sw on
sys errctl 0
sys trcl level 5
sys trcl type 1180
sys trcp cr 64 96
sys trcl sw off
sys trcp sw off
ip tcp mss 512
ip tcp limit 2
ip tcp irtt 65000
ip tcp window 2
ip tcp ceiling 6000
ip rip activate
ip rip merge on
ip icmp discovery enif0 off
bridge mode 1
sys quick enable
wan adsl rate off
P652HW>
Herstarten om in te laten gaan.
Als aan beide kanten ZyXel routers staan, dan beide routers instellen.
Oorzaak 7 : (bij gebruik van een VPN client zoals The Greenbow of de ZyWALL RSC:) de instellingen van de firewall blokkeren het verkeer.
Oplossing 7 : Vanaf sommige firmwares en bij bepaalde types is een wijziging aan de VPN NAT-traversal techniek uitgevoerd.
Daarom dient u een extra service toe te voegen (UDP, poort 4500) aan de WAN(x) to WAN(x) / ZyWALL firewall regels.
Daar staat nu standaard IKE(UDP:500) en BOOTP_CLIENT(UDP:68) als eerste firewall regel
Afhankelijk van de gebruikte firmware op de ZyWALL bestaat deze service al als Predefined Service genaamd: VPN_NAT_T(UDP:4500), Zoniet dan dient u deze als Custom Service toe te voegen.
- Symptoom: De tunnel komt niet op en er staan NOTFY regels in de (webpagina)log:
NOTFY:ERR_PAYLOAD_TYPE
In (maar) een van de twee routers staat NAT Transversal aan.
NOTFY:PYLD_MALFORMED (alleen in log van de beantwoorder)
De preshared key (PSK) komt niet overeen.
NOTFY:ERR_ID_INFO (in beide logs en alleen in log van de beantwoorder:) !! ID Type Mismatch
Local ID Type bij initiator en Remote ID Type bij beantwoorder komen niet overeen.
NOTFY:ERR_ID_INFO (in beide logs en alleen in log van de beantwoorder:) !! ID Content Mismatch
Local ID Content bij initiator en Remote ID Content bij beantwoorder komen niet overeen.
NOTFY:ERR_ID_INFO (in beide logs en alleen in log van de initiator:) !! ID Type Mismatch
Remote ID Type bij initiator en Local ID Type bij beantwoorder komen niet overeen.
NOTFY:ERR_ID_INFO (in beide logs en alleen in log van de initiator:) !! ID Content Mismatch
Remote ID Content bij initiator en Local ID Content bij beantwoorder komen niet overeen.
NOTFY:NO_PROP_CHOSEN (alleen in log van de bantwoorder)
Een of meer Phase 1 instellingen komen niet overeen. Dit kan dus zijn:
- Encryption Algorithm (DES/3DES)
- Authentication Algorithm (MD5/SHA1)
- Key Group (DH1/DH2)
NOTFY:NO_PROP_CHOSEN (in beide logs)
Een of meer Phase 2 instellingen komen niet overeen. Dit kan dus zijn:
- Encryption Algorithm (DES/3DES)
- Authentication Algorithm (MD5/SHA1)
- Key Group (DH1/DH2)
- Symptoom: De tunnel komt niet op en er staan in de router die de verbinding moet gaan opbouwen uitsluitend(!) IKE Packet retransmit regels in de (webpagina)log:
Oorzaak 1: Een van de apparaten is ingesteld op MAIN MODE en de andere op AGRESSIVE MODE.
Oplossing 1: Stel beide routers op dezelfde mode in.
Oorzaak 2: De firewall blokkeert aan de ontvangende kant het inkomende VPN verkeer. Er staat dan meestal wel een melding van geblokkeerde IKE packets in de (webpagina)log.
Oplossing 2: Zet de firewall uit (zodra het werkt aanpassen en weer activeren).
Oorzaak 3: Het IKE (UDP poort 500) verkeer wordt niet doorgegeven aan de VPN-router aan de andere kant. Dit laatste ligt dan meestal aan het type, de firmware of de instellingen van het gebruikte modem.
Oplossing 3: Controleer of de gebruikte modem de juiste instellingen heeft.
Oorzaak 4: Het My IP-address in de VPN-instellingen van de ontvangende router, of het secure gateway IP-address van de zendende router staat niet correct ingesteld.
Oplossing 4: Controleer de VPN instellingen.
Oorzaak 5: IKE verkeer (UDP poort 500) verkeer wordt via de NAT Setup door gestuurd naar een intern IP-adres.
Oplossing 5: Verwijder poort 500 uit de NAT Setup tabel.
- Symptoom: De tunnel komt niet op, en er staan meldingen Resv ID: SINGLE/SUBNET/REMOTE, vs My Remote, !!Verifing remote failed in de (webpagina)log.
Oorzaak 1: Een van de meest voorkomende problemen is dat de SINGLE (voor ZyWall 1, 2 en 2WE standaard voor local), RANGE en SUBNET instellingen niet in beide routers correct gespiegeld (dus REMOTE voor de ene is LOCAL voor de andere)staan ingesteld.
Oplossing 1: Wijzig Local en Remote Address Types in beide de routers aan.
- Symptoom: De tunnel komt op, maar mijn LAN verbinding is weg!
Oorzaak 1: U heeft in de router voor het remote netwerk een bereikopgegeven wat met het eigen LAN-bereik overlapt. Meestal is dit het gevolg van RANGE instellen i.p.v. SUBNET met als eindadres (i.p.v. subnetmaster) 255.255.255.0.
Oplossing 1: Wijzig RANGE in SUBNET, of pas het eind-adres aan. Doe dit in beide routers!
- Symptoom: De tunnel komt op, er gaat data doorheen, maar na verloop van tijd komt er geen data meer doorheen en blijkt nog maar in een van de twee routers de tunnel in het overzicht te staan!
Dit wordt door ZyXEL een zombie-tunnel genoemd. In de IPsec standaard worden helaas niet beschreven hoe dit verschijnsel opgelost dient te worden, dus elke fabrikant heeft zijn eigen implementatie.
Oorzaken: Een van de routers is herstart zonder de kans te krijgen om de tunnel netjes te sluiten. Of de Internet verbinding is bij een van de routers zo lang weggevallen dat die router de VPN-verbinding heeft gesloten.
Oplossing 1: Gebruik firmware die een 'INITIAL CONTACT' payload kan verzenden en bij ontvangst begrijpt. Dit is het geval met de meeste zo niet alle firmwares van na oktober 2003. Helaas zal dit niet helpen als het publieke IP-adres van de andere router veranderd is. Er onstaat dan een conflict en de nieuwe verbinding wordt geweigerd vanwege een overlap in IP-bereiken.
Oplossing 2: Stel de Outbound Idle Timout (let dus alleen op uitgaand en niet op ingaand verkeer) in. De Security Association (SA) wordt verwijderd na het verlopen van de ingestelde tijd. De tijd is in te stellen in de Command Interface (Telnet of Hyperterminal menu 24.8) met:
ipsec timer chk_conn tijd in minuten
|
De standaard waarde is twee minuten. De tijd kan worden ingesteld tussen 2 en 255.
Oplossing 3: Stel (indien dit wordt ondersteund door firmware) de Inbound Idle Timout (let dus alleen op ingaand en niet op uitgaand verkeer) in. De Security Association (SA) wordt verwijderd na het verlopen van de ingestelde tijd. De tijd is in te stellen in de Command Interface (Telnet
/Hyperterminal menu 24.8) met:
ipsec timer chk_input tijd in minuten
|
De standaard waarde is nul (is niet opletten). De tijd kan worden ingesteld tussen 2 en 255.
Oplossing 4: Verbreek handmatig de spookverbinding als dit optreed.
- Symptoom: Ik kan alles door de VPN-tunnel, maar ik kan niet bij een op een Windows machine gedeelde map of printer.
Oorzaak 1: Een of beide routers laten helemaal geen NetBIOS verkeer door.
Oplossing 1: Stel de router in dat over alle VPN-verbindingen NetBIOS verkeer wordt toegestaan. Bijvoorbeeld in de Prestige 652R (firmware 3.40(FW.7)) moet u onder de VPN - Global Setting - Windows Networking (NetBIOS over TCP/IP) "Allow NetBIOS Traffic Through All IPSec Tunnels" aanvinken.
Oorzaak 2: NetBIOS over IP wordt niet gebruikt, of wordt niet ondersteund door een of meerdere van de betreffende computers.
Oplossing 2: Schakel IPX en NetBEUI uit en/of schakel NetBIOS over IP in op alle computers.
Oorzaak 3: (NetBIOS) broadcasts (in dit geval noodzakelijk om namen van machines in de netwerkomgeving te zien) worden in principe door routers niet doorgelaten. Dus machines zien of op naam bereiken kan niet zonder maatregelen.
Oplossing 3a: Probeer machines niet op naam maar op \\ip-adres te bereiken.
Oplossing 3b: Maak op elke computer een HOST en/of LMHOSTS bestand aan (dit is een oplossing voor zowel Macintosh, Unix en Windows OS-en) waarin de namen en bijhorende IP-adressen staan.
Oplossing 3c: Gebruik WINS om machines wel op naam te kunnen gebruiken.
Oplossing 3d: Gebruik een eigen DNS server (statisch met de namen en bijbehorende IP-adressen, of dynamisch door koppeling aan de DHCP-servers) om machines wel op naam te kunnen gebruiken.
- Symptoom: De tunnel komt op, maar dan is er geen Internet meer!
Oorzaak 1: U heeft in de router voor het remote netwerk een bereikopgegeven wat met het Internet bereik overlapt. Meestal is dit het gevolg van het bij (remote) SUBNET een te groot subnetmaster (bijvoorbeeld 0.0.0.0) instellen.
Oplossing 1: Wijzig RANGE in SUBNET, of pas het eind-adres aan. Doe dit in beide routers!
- Symptoom: De tunnel komt niet op en ik zie in de log wel een aantal IKE packetjes heen en weer gaan (Send:[KE][NONCE], Recv:[SA][VID][VID], Send:[SA][VID][VID]) maar daarna(!) alleen nog maar IKE Packet Retransmits.
Oorzaken: Een (of beide) ZyWalls staat achter een NAT-router en in het "My IP addr" van de ZyWall staat het publieke IP-adres in plaats van het WAN IP-adres.
Oplossing: Stel de "My IP addr" van de ZyWall correct in op het werkelijke WAN IP-adres van de ZyWall.
- Symptoom: De tunnel komt soms op, komt niet altijd meteen terug na het afvallen, of valt (schijnbaar) periodiek weg.
Oorzaak: In een van de betrokken routers staat het IKE (UDP) protocol (poort 500) niet (meer) op doorlaten. Dit is meestal het gevolg van een firmware upgrade waar deze regel niet bij de WAN->WAN/ZyWall, maar bij de WAN->LAN firewall regels terecht is gekomen. Het lijkt soms alsof het wel lukt om beide kanten op de VPN-verbinding open te zetten. Maar dat is dan het gevolg van het door het openzetten als gevolg van een actie vanaf de kant die zelf inkomend IKE verkeer niet toestaat.
Oplossing: Stel bij de WAN->WAN/ZyWall firewall regels in dat IKE moet worden toegelaten.
- Symptoom: De tunnel komt niet op en er staat Rule [x] Verifying Local ID failed: gevolgd door !! unsupported local ID Type: [x] in de (web)log, waar x het nummer van de regel is.
Oorzaak: In de bijbehorende VPN rule staat niet aan beide zijden dezelfde port (range) ingesteld.
Oplossing: Stel de port (range) gelijk in.
De VPN-Checklist
Kijk eerst bij de veel voorkomende problemen. Als dat niet helpt loop de volgende checklist af
Als het probleem hiermee niet wordt opgelost, dan de checklist ingevuld mee-e-mailen met waar in Wat moet er in de E-mail? om wordt gevraagd:
- Binnen het LAN is de eerste router bereikbaar (op IP-adres: ___.___.___.___) en de eventuele tweede router is ook bereikbaar (op IP-adres: ___.___.___.___). Dit is met een ping vanaf een computer in hetzelfde LAN naar het LAN IP-adres van de router te controleren. De LAN IP-adressen zijn ook onder (Telnet) menu 24.2.1 te vinden.
- De eerste router heeft een goed functionerende Internet verbinding (met WAN IP-adres: ___.___.___.___) te vinden onder Telnet menu 24.1 of 24.8 met het commando ip ifconfig. De eventuele tweede router heeft ook een goed functionerende Internet verbinding (met WAN IP-adres: ___.___.___.___). Dit is met het ping naar een willekeurig extern publiek IP-adres vanuit de router onder (Telnet) menu 24.4 te controleren.
- Via de eerste router komen computers op het Internet. Dat geldt ook voor de eventuele tweede router. Dit is met traceroute commando (Windows commando tracert) vanaf een computer in hetzelfde LAN naar een willekeurig extern publiek IP-adres te controleren. Dit is te forceren door door de DHCP server onder (Telnet) menu 3.2 in te schakelen en de computers automatisch een IP-adres te laten verkrijgen. Let er hierbij op dat er nooit meer dan een DHCP-server in een netwerk mag zijn.
- RIP staat uit in alle betrokken routers en computers. RIP voor WAN is te vinden via (Telnet) menu 11.1 Edit IP Option = Yes, voor de LAN onder (Telnet) menu 3.2.
- NAT Transversal staat uit onder (Telnet) menu 27.1.profiel in alle betrokken routers (danwel alleen wanneer het echt niet anders werkt aan in alle routers). Het gaat niet werken als het in de ene router aan staat en in de andere router uit staat of niet eens kan worden ingesteld.
- De firewall van de router is niet actief onder (Telnet) menu 21.2 zodat uitgesloten wordt dat de firewall de oorzaak van de problemen is.
- Alleen de probleemverbinding is actief ingesteld onder de (Telnet) menu 27.1.profiel(en)).
- In de verschillende routers staat onder (Telnet) menu 27.1.profiel bij My IP Addr het WAN-IP-adres van de router ingesteld (Dit kan het publieke IP-adres zijn, maar niet altijd).
- De meest recente (of een speciaal voor de gegeven situatie aangeraden) firmware (te vinden op ftp.zyxel.dk en ftp.zyxel.com) zit in de routers. De versie is onder (Telnet) menu 24.2.1 te vinden. Het betreft firmware (inclusief achtervoegsels en datum) 3.____(___.__)__ van ___/___/____ en 3.____(___.__)__ van ___/___/______
of software _________________ versie ____________________
- De Preshared Key (PSK of security-string) is niet langer dan 31 tekens (de maximum lengte voor de ZyXEL).
Wat moet er in de E-mail?
Let op! Daar waar we in de tekst vragen om gegevens uit Telnet, deze als tekst (en niet als screendump) uit Telnet (en niet uit een webpagina) in de e-mail kopieren (dit is met alle Telnet versies op een of andere manier mogelijk). Screendumps maken het document groter, moeilijker door te kijken en het doorgeven van correcties kost aanmerkelijk meer moeite. Daarnaast is ook de webpaginalog vaak van belang, ook deze log is als tekst te kopieren in de e-mail.
Wij kunnen niet garanderen dat aangekoppelde webpaginas, PDF-documenten en MS Word documenten door ons gelezen kunnen worden, of zelfs maar aankomen. Deze bestanden kunnen worden verwijderd wegens besmettingsrisico's.
Voeg aan de checklist het volgende toe:
- Soort WAN verbinding (Telnet menu 4) van elke router
- Het gebruikte type modems (bij een ZyWall) en soort verbinding (abonnementsnaam bij ISP en indien bekend de Telco/operator).
- De teksten van de VPN instellingen van de routers (Telnet menu 27.1, 27.1.profiel en 27.1.profiel.1). Beide teksten zijn noodzakelijk, kleine tikfoutjes hebben grote gevolgen. En mogelijk dat wij ze wel zien.
- De tekst van de router logs uit de web-interface (aan beide hebben we het meest, anders minimaal die van de ontvangende kant). De meest voorkomende foutmeldingen staan in bij probleem 3: Er staan NOTFY regels in de (webpagina) log. Let er op dat u eerst in Telnet moet uitloggen (menu 99) voor u in de webinterface kunt komen (en andersom).
- De opgevangen ipsec debug log(s) (als tekst) uit beide routers gedurende een poging een VPN verbinding op te bouwen. Maak daarbij duidelijk van welke van de apparaten welk log afkomstig is. De procedure staat in het vervolg van dit document aangegeven.
- Bij zeer hardnekkige problemen (uitsluitend op ons verzoek) ook de uitgelezen configuraties van de ZyXEL routers (met de wachtwoorden, bij voorkeur 1234). Let er op dat we dan verwachten dat DHCP in de routers aan staat! Maar voor snelle analyse is het beter dat de instellingen ook dan als tekst uit de routers worden gehaald, zodat er niet meteen veel vertraging is voor we deze in het juiste type product met de juiste firmware kunnen flashen.
- Verstuur de gegevens in een e-mail uitsluitend aan support@valadis.nl
Uiteraard kunt u delen van de informatie aan ons sturen, maar onvolledige informatie zal vermoedelijk tot een tragere afhandeling - of mogelijk tot geen afhandeling - leiden.
Waar vind ik de (webpagina)log?
Het uiterlijk van schermen kan afhankelijk van het type en de firmware afwijken!
-

Maak een verbinding met de webpagina van de router. De router zit standaard op http://192.168.1.1/.
-
Log in op de router door het wachtwoord (standaard is dat 1234) in te vullen en op de knop Login te drukken.
-
Klik op ADVANCED.
-
Klik op LOGS.
Druk voor de poging op de knop Clear Log om te wissen. (Na de poging de tekst van het log kopieren)
Log uit de router door op Logout te klikken.
Hoe doe ik via Telnet de IPsec debug procedure?
- Maak een Telnet verbinding met de router. De router zit standaard op 192.168.1.1. U mag dit een seriele verbinding maken, i.p.v. Telnet te gebruiken. Het is handig om de Telnet-client of het terminal programma zo in te stellen dat alle tekst naar een bestand wordt geschreven. Deze kunt u dan voor het versturen opschonen en van aanvullend commentaar voorzien.
- Log in op de router door het wachtwoord (standaard is dat 1234) te tikken, gevolgt door [ENTER]-toets:
- Ga naar menu 24.8 door eerst 24 te tikken, gevolgt door de [ENTER]-toets:
Copyright (c) 1994 - 2002 ZyXEL Communications Corp.
ZyWALL Main Menu
Getting Started Advanced Management
1. General Setup 21. Filter and Firewall Setup
2. WAN Setup 22. SNMP Configuration
3. LAN Setup 23. System Password
4. Internet Access Setup 24. System Maintenance
26. Schedule Setup
27. VPN/IPSec Setup
Advanced Applications
11. Remote Node Setup
12. Static Routing Setup
15. NAT Setup
99. Exit
Enter Menu Selection Number:
|
- En dan door 8 te tikken, gevolgt door de [ENTER]-toets:
Menu 24 - System Maintenance
1. System Status
2. System Information and Console Port Speed
3. Log and Trace
4. Diagnostic
5. Backup Configuration
6. Restore Configuration
7. Upload Firmware
8. Command Interpreter Mode
9. Call Control
10. Time and Date Setting
11. Remote Management Setup
Enter Menu Selection Number: |
- U zit nu in de commandline mode (waar u met een ZyWall 1 meteen in terecht komt):
Copyright (c) 1994 - 2002 ZyXEL Communications Corp.
ras> |
- Start de debug mode met het commando ipsec debug on (soms moet er i.p.v. on het cijfer een worden gebruikt):
Bij de nieuwere modellen en/of firmware worden vaak andere commando's gebruikt:
ras> ipsec debug level 3
ras> ipsec debug type 6 |
-
Forceer de verbinding vanaf een computer:
Of vanuit de router met het ipsec dial profielnummer commando. In het voorbeeld wordt profiel 1 verondersteld:
Zorg er voor dat al het verkeer door de Telnet sessie wordt opgevangen (capture) .
Ping vanaf een computer(!) een achter een IP-adres in het andere netwerk .
- Stop de debug mode met het commando ipsec debug off (soms moet er i.p.v. off het getal nul worden gebruikt). U kunt hier desgewenst uit met exit[ENTER]99[ENTER].
ras> ipsec debug off
ras> exit
99[ENTER] |
Bij de nieuwere modellen en/of firmware worden vaak andere commando's gebruikt:
ras> ipsec debug level 0
ras> ipsec debug type 0
ras> exit
99[ENTER] |
- Let op! Vergeet niet om inderdaad de debug mode na het maken van de log inderdaag te stoppen, want in debug mode is de eigenlijke tunnel onbruikbaar voor normaal gebruik. De datatransport wordt bijzonder vertraagd.