vpnc tegen Check Point of Nortel: waarom het blijft hangen

Het symptoom is makkelijk verkeerd te lezen: vpnc start, vraagt om het groepswachtwoord en blijft dan bij een onderhandelingsstap staan tot het meldt dat er geen antwoord van het doel komt. Niets in de uitvoer noemt het gatewayproduct, en het account werkt vanuit een browser, dus de voor de hand liggende conclusie is een verkeerd wachtwoord of een geblokkeerde poort. In de meeste van deze gevallen is de gateway helemaal geen IPsec-peer, zodat de uitwisseling nooit ver genoeg komt om inloggegevens te testen. Dat patroon is het testen waard voordat er iets anders in het profiel verandert.

Identificeer het product voordat je een ander profielveld bewerkt.

De storing lijkt op verkeerde inloggegevens

vpnc begint met het sturen van IKE naar UDP 500 en, als NAT-traversal wordt aangeboden, naar UDP 4500. Een gateway die SSL in plaats van IPsec termineert, antwoordt op geen van beide, dus de client probeert opnieuw en geeft uiteindelijk op met een algemene fout. Als hetzelfde account werkt via een browserportaal dat een kleine hulptoepassing laadt, is dat een sterke aanwijzing dat de tunnel op SSL is gebaseerd en dat de client de verkeerde vraag stelt.

Een mislukte poging hier zegt niets over het gebruikersaccount, omdat er nooit inloggegevens aan de gateway zijn voorgelegd.

Controleer welk protocol de gateway aanbiedt

Twee minuten onderzoek scheiden een IPsec-peer van een SSL-portaal. Voer ze uit vanaf hetzelfde netwerk dat de client gaat gebruiken, en lees welke poorten antwoorden in plaats van welke in een document staan. Bewaar het resultaat, want diezelfde poorten bepalen welke client de eigenaar van de gateway zou moeten ondersteunen. Onderzoek vanaf het clientnetwerk en niet vanaf een host naast de gateway.

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

Een open 443 met een doorverwijzing naar een inlogpagina en stilte op 500 en 4500 wijst op een SSL VPN. Open 500 en 4500 met een certificaat dat op 443 wordt geserveerd, wijzen op een IPsec-gateway die ook een webfrontend draait, en dat is precies het geval waarvoor vpnc is gebouwd.

Check Points SSL Network Extender en Nortels Aventail-client vallen beide in de tweede categorie, en geen van beide accepteert een IKEv1-groepsgeheim.

Wat het vpnc-profiel wel en niet kan uitdrukken

Onder de motorkap draait vpnc IKEv1 tegen een vooraf gedeelde groepssleutel en stuurt daarna de inloggegevens van de individuele gebruiker via XAuth. Alles in het configuratiebestand hoort bij die uitwisseling: gateway, groepsnaam, groepsgeheim, gebruikersnaam en gebruikerswachtwoord. Die velden beschrijven één protocol, en geen enkele combinatie ervan kan de client een ander laten spreken.

Daarom lost het uitbreiden van de cijferlijst of het uitschakelen van certificaatcontroles dit soort storing nooit op. Die wijzigingen verzwakken een onderhandeling waar de gateway niet naar luistert.

De client kiezen die bij de gateway past

Gebruik voor een Check Point-gateway het SNX-pakket dat voor die gatewayversie is gebouwd, dat de leverancier samen met zijn documentatie voor toegang op afstand publiceert. Oudere SNX-builds falen vaak op huidige distributies omdat ze 32-bit-bibliotheken verwachten die niet meer zijn geïnstalleerd, en een verlaten pakket patchen is meestal slechter dan de ondersteunde client op een ondersteund platform draaien.

Aventail-clients verloren lang geleden de ondersteuning. Waar zo'n gateway nog in dienst is, zijn de realistische keuzes het browserportaal als de organisatie dat inschakelt, of de ondersteunde client van de leverancier op een ondersteund besturingssysteem.

Vraag de eigenaar van de gateway naar het product en de versie, de client die zij onder Linux ondersteunen, en of er überhaupt een IPsec-profiel bestaat. Als dat er is, vraag dan de groepsidentificatie en het groepsgeheim als afzonderlijke items, want die zijn niet het gebruikerswachtwoord en een verwisseld paar is de andere veelvoorkomende oorzaak van een mislukte tunnel. Noteer, wanneer een verbinding eindelijk lukt, welk protocol is onderhandeld, zodat de volgende persoon van een feit uitgaat in plaats van dezelfde gok te herhalen.