Tunneled standaardroute op Cisco ASA: wanneer die echt geldt

Een gebruiker met externe toegang bereikt niets voorbij de ASA, terwijl dezelfde server wel antwoordt op pings uit het interne LAN. De tunnel komt op, de client krijgt een adres uit de pool, en toch verlaat het pakket via de internetstandaardroute of verdwijnt het. Dat patroon betekent meestal dat het ontsleutelde verkeer geen eigen route vond en terugviel op de gewone standaardroute. De oplossing is geen extra NAT-regel; het is de tunneled standaardroute.

Begin bij het symptoom, niet bij de configuratie

Kijk waar het pakket heen gaat in plaats van waar u verwachtte dat het heen zou gaan. Een capture op de buiteninterface tijdens een mislukte sessie toont het ontsleutelde pakket op weg naar de ISP-gateway met het pooladres nog intact, of toont helemaal niets omdat de opzoeking mislukte. Hoe dan ook is de tunnel niet het probleem.

De tunnel ziet er gezond uit in show vpn-sessiondb, en juist daarom blijven mensen IKE debuggen.

Wat dit onderscheidt van een ACL-drop is de richting. Een ACL-drop wordt gelogd en geteld, terwijl een ontbrekende route een opzoekfout oplevert zonder overeenkomende vermelding. Voer show route uit voor de bestemming van de client en lees wat de ASA werkelijk selecteerde, inclusief of een standaardroute werd gekozen en welke.

Hoe de tunneled-opzoeking verschilt

Cisco's handleiding voor statische routering op ASA 9.23 documenteert een aparte standaardroute voor ontsleuteld VPN-verkeer dat geen statische of geleerde route heeft. Het trefwoord tunneled markeert die route, zodat een ontsleuteld pakket kan terugvallen op een andere volgende hop dan die de ASA voor zijn eigen transport gebruikt. Specifiekere routes winnen nog steeds, en daarom kan een client via de interne gateway 10.0.0.0/8 bereiken en al het overige verliezen.

Een minimale opzet houdt twee standaardroutes met verschillende volgende hops. De ene draagt het eigen verkeer van de ASA, de andere draagt ontsleuteld verkeer dat geen betere route heeft. Beide volgende hops moeten nog steeds bereikbaar zijn vanaf de interface waaraan u ze koppelt.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

Als beide standaardroutes naar dezelfde volgende hop wijzen, verandert het trefwoord niets en zal het symptoom niet verschuiven.

De beperkingen die bepalen of het werkt

Dezelfde handleiding staat slechts één tunneled standaardroute toe en vermeldt dat ECMP daarvoor niet wordt ondersteund, dus u kunt die route niet loadsharen. Ze noemt ook beperkingen rond route tracking, reverse-path-verificatie en enkele inspectie- en beheerstromen. Lees die naast uw geïnstalleerde release voordat u rond deze functie ontwerpt. Een ontwerp dat ze negeert, faalt meestal op één specifieke plek in plaats van overal, en daarom lijkt het symptoom intermittierend.

Reverse-path-verificatie is degene die bijt in asymmetrische ontwerpen. Als het antwoord via een andere interface zou binnenkomen dan de ASA verwacht, wordt het pakket gedropt voordat routering ertoe doet. Repareer de topologie of het retourpad in plaats van de verificatie uit te schakelen om een volgende hop af te dwingen.

Route tracking is een aparte valkuil: het gevolgde object bewaakt meestal de gewone standaardroute, niet de tunneled.

Wat het trefwoord niet doet

Het kiest niet het bronadres dat de ASA gebruikt om IKE op te bouwen. Het buitenste tunnel-eindpunt volgt de eigen interface- en bronselectie van het platform, en de tunneled standaardroute heeft geen aandeel in die beslissing. Die wijzigen repareert geen phase 1 die vanaf het verkeerde adres vertrekt.

Het maakt de volgende hop ook niet tot een proxy. Als de bestemming een HTTP CONNECT-uitwisseling verwacht, levert ruwe IP-pakketten naar een proxyhost sturen u alleen een host op die ze niet routeert. Configureer in plaats daarvan het proxymechanisme dat de client ondersteunt.

En het creëert geen doorsturing stroomafwaarts. De gateway waar u naar wijst heeft nog steeds een route terug naar de VPN-pool nodig, plus bronvertaling waar het ontwerp daarom vraagt.

Verifieer het pad van begin tot eind

Zodra de route erin staat, controleer vier dingen in volgorde: show route voor een bestemming die de pool nodig heeft, een capture op de interface richting de nieuwe volgende hop, een capture op de gateway zelf, en een retourpad van die gateway naar het pooladres. De eerste twee bewijzen dat de ASA het pad koos, de laatste twee dat er iemand op antwoordt.

Als de gateway antwoordt maar de client nooit een antwoord ziet, kijk dan naar bronvertaling en de retourroute voordat u de routetabel weer aanraakt.

Noteer de release waarop u heeft gevalideerd, want de beperkingenlijst is versieafhankelijk en een ontwerp dat op de ene train werkt, kan op een andere een ander pad nodig hebben. Die notitie leeft langer dan het configuratiesnippet.