Tunneled standardrutt på Cisco ASA: när den faktiskt gäller

En fjärråtkomstsanvändare når ingenting bortom ASA:n medan samma server svarar på ping från det interna LAN:et. Tunneln kommer upp, klienten får en adress från poolen, och paketet lämnar ändå via internetstandardrutten eller försvinner. Det mönstret betyder oftast att den dekrypterade trafiken inte hittade en egen rutt och föll igenom till den vanliga standardrutten. Åtgärden är inte ännu en NAT-regel; det är den tunneled standardrutten.

Börja med symtomet, inte konfigurationen

Titta vart paketet tar vägen i stället för vart du förväntade dig att det skulle ta vägen. En avlyssning på det yttre gränssnittet under en misslyckad session visar det dekrypterade paketet på väg mot ISP:ns gateway med pooladressen fortfarande intakt, eller visar ingenting alls eftersom sökningen misslyckades. Hur som helst är det inte tunneln som är problemet.

Tunneln ser frisk ut i show vpn-sessiondb, och det är precis därför folk fortsätter felsöka IKE.

Det som skiljer detta från ett ACL-släpp är riktningen. Ett ACL-släpp loggas och räknas, medan en saknad rutt ger ett sökfel utan matchande post. Kör show route för klientens destination och läs vad ASA:n faktiskt valde, inklusive om en standardrutt valdes och vilken.

Hur den tunneled sökningen skiljer sig

Ciscos guide för statisk routing på ASA 9.23 dokumenterar en separat standardrutt för dekrypterad VPN-trafik som inte har någon statisk eller inlärd rutt. Nyckelordet tunneled markerar den rutten, så ett dekrypterat paket kan falla tillbaka på ett annat nästa hopp än det ASA:n använder för sin egen transport. Mer specifika rutter vinner fortfarande, och därför kan en klient nå 10.0.0.0/8 via den interna gatewayn och förlora allt annat.

En minimal uppställning behåller två standardrutter med olika nästa hopp. Den ena bär ASA:ns egen trafik, den andra bär dekrypterad trafik som inte har någon bättre rutt. Båda nästa hoppen måste fortfarande vara nåbara från det gränssnitt du kopplar dem till.

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

Om båda standardrutterna pekar på samma nästa hopp ändrar nyckelordet ingenting och symtomet flyttar sig inte.

Begränsningarna som avgör om det fungerar

Samma guide tillåter bara en tunneled standardrutt och anger att ECMP inte stöds för den, så du kan inte lastbalansera den vägen. Den listar också begränsningar som rör ruttspårning, verifiering av returväg och vissa inspektions- och hanteringsflöden. Läs dem mot den release du har installerad innan du designar kring funktionen. En design som ignorerar dem misslyckas oftast på ett specifikt ställe i stället för överallt, och därför verkar symtomet intermittent.

Verifiering av returväg är den som biter i asymmetriska designer. Om svaret skulle komma in via ett annat gränssnitt än ASA:n förväntar sig, släpps paketet innan routingen spelar någon roll. Åtgärda topologin eller returvägen i stället för att stänga av verifieringen för att tvinga fram ett nästa hopp.

Ruttspårning är en egen fälla: det spårade objektet skyddar vanligtvis den vanliga standardrutten, inte den tunneled.

Vad nyckelordet inte gör

Det väljer inte den källadress som ASA:n använder för att bygga IKE. Den yttre tunneländpunkten följer plattformens eget val av gränssnitt och källa, och den tunneled standardrutten har ingen del i det beslutet. Att ändra den reparerar inte en phase 1 som utgår från fel adress.

Det gör inte heller nästa hopp till en proxy. Om destinationen förväntar sig ett HTTP CONNECT-utbyte ger det dig bara en värd som inte routar dem att skicka råa IP-paket till en proxyvärd. Konfigurera i stället den proxymekanism som klienten stöder.

Och det skapar ingen vidarebefordran nedströms. Gatewayn du pekar på behöver fortfarande en rutt tillbaka till VPN-poolen, plus källöversättning där designen kräver det.

Verifiera vägen från ände till ände

När rutten är på plats, kontrollera fyra saker i ordning: show route för en destination som poolen behöver, en avlyssning på gränssnittet mot det nya nästa hoppet, en avlyssning på själva gatewayn och en returväg från den gatewayn till pooladressen. De två första bevisar att ASA:n valde vägen, och de två sista att någon svarar på den.

Om gatewayn svarar men klienten aldrig ser ett svar, titta på källöversättningen och returrutten innan du rör rutttabellen igen.

Anteckna vilken release du verifierade på, eftersom begränsningslistan är versionsspecifik och en design som fungerar på en linje kan behöva en annan väg på en annan. Den anteckningen lever längre än konfigurationsutdraget.