VPN mellom lokasjoner virker, men ASA-loggene kommer ikke: kontroller kildeadressen

Interne verter når den eksterne samleren, og syslog-linjene deres dukker opp. ASA-ens egne meldinger om de samme sesjonene kommer aldri frem. Det er ikke noe galt med samleren eller med tunnelen, og det er det forvirrende. Brannmuren sender loggene sine fra en kilde som tunnelen aldri ble bygget for å beskytte.

Hva som kommer frem, og hva som ikke gjør det

Begynn med å skille to strømmer som ser identiske ut på et dashbord. Videresendt trafikk passerer gjennom ASA-en: en LAN-vert sender til samleren, ASA-en matcher det mot tunnelpolicyen, krypterer det, og samleren ser vertens adresse. Generert trafikk starter på ASA-en selv: boksen bygger en syslog-pakke, velger et utgangsgrensesnitt og en kilde og spør først deretter om noen tunnelpolicy passer. Den første strømmen beviser at tunnelen virker, og den sier ingenting om den andre.

En bufret hendelse på enheten er heller ikke bevis på ekstern levering, fordi loggen kan finnes lokalt og aldri ha blitt sendt. Kontroller samlerens mottakstellere før du klandrer tunnelen, fordi en tom teller er et annet funn enn en som vokser.

En generert melding er ikke videresendt trafikk

Når ASA-en selv oppretter en pakke, proxyer den ikke for en LAN-vert. Kilden kommer fra utgangsgrensesnittet eller fra en eksplisitt kildeinnstilling, og pakken går gjennom samme rutesøk og samme policykontroller som alt annet boksen sender. Det betyr at VPN-selektoren må inneholde adressen ASA-en faktisk bruker, og det er ofte grensesnittet på utsiden fremfor et internt subnett.

Hvis policyen beskytter 10.20.0.0/24 og ASA-en bruker sin eksterne adresse som kilde, forlater loggpakken enten i klartekst mot en samler den ikke kan nå, eller den blir droppet. Begge utfallene ser identiske ut fra samlerens side. Samme resonnement gjelder for administrasjonstrafikk, og derfor er management-access en separat designbeslutning.

Hvilken kilde ASA-en setter på ledningen

Finn kilden empirisk i stedet for ved antakelse. Et opptak på utgangsgrensesnittet under en testmelding viser den faktiske kilden og destinasjonen, og det koster mindre tid enn å lese tre konfigurasjonsavsnitt. Sammenlign den adressen med tunnelens lokale selektor.

Noen versjoner lar deg feste loggkilden til et grensesnitt, og kommandoreferansen for versjonen din er autoriteten på om det alternativet finnes og hva det endrer. En source-interface-kommando fra en annen Cisco-plattform er ikke automatisk gyldig på en ASA.

Hvis du endrer kilden, gjør det bevisst og noter det, fordi samlerens ACL-er og enhver korrelasjon bygget på syslog avhenger av den.

Tilpass selektoren til loggstrømmen

Når kilden er kjent, kontroller tre ting i rekkefølge: krypto-ACL-en eller den policybaserte selektoren som avgjør hvilken trafikk som er interessant, ruten som avgjør hvor pakken går, og enhver NAT-regel som kan skrive om kilden før kryptering. En pakke som passer med ruten men ikke selektoren blir ikke tunellert, og en pakke som skrives om av NAT passer kanskje ikke med noen av dem.

Samlersiden har sine egne krav: en ACL som tillater ASA-ens kilde, en returrute og en lyttende tjeneste på porten du konfigurerte. Transport betyr noe her også, fordi TCP- og TLS-logging oppfører seg annerledes enn UDP på en delvis blokkert vei. Endre ett element om gangen, ellers vil det neste opptaket ikke fortelle deg hvilken endring som betydde noe.

Verifiser hos samleren, og noter deretter kilden

Bekreft at meldingen kommer frem, og skriv deretter ned kildeadressen ASA-en brukte, selektoren som bar den og alvorlighetsgraden du testet med.

Den registreringen gjør den neste ACL-endringen eller selektorredigeringen på samleren til en tominutters sjekk i stedet for en gjenoppdagelse. Den dokumenterer også hvilken av de to strømmene som noen gang ble validert, og det er den delen de fleste runbooks utelater. Hvis meldingen fortsatt ikke kommer frem, senk alvorlighetsterskelen midlertidig og test mot en enkelt destinasjon.

Cisco FAQ om ASA-logging dokumenterer et tilfelle med ekstern kilde som krever den tilsvarende definisjonen av beskyttet trafikk, og eksempelet med intern kilde omfatter både en loggvert på innsiden og management-access på innsiden. Behandle den dokumenterte kombinasjonen og programvarekonteksten sammen i stedet for å anta at én kopiert linje passer til enhver konfigurasjon.

En tunnel som bærer LAN-trafikk er ikke en tunnel som bærer brannmurens egen stemme.