VPN mellan platser fungerar, men ASA-loggarna kommer inte: kontrollera källadressen

Interna värdar når den fjärranslutna insamlaren och deras syslog-rader dyker upp. ASA:ns egna meddelanden om samma sessioner kommer aldrig fram. Det är inget fel på insamlaren eller på tunneln, och det är det förvirrande. Brandväggen skickar sina loggar från en källa som tunneln aldrig byggdes för att skydda.

Vad som kommer fram och vad som inte gör det

Börja med att skilja två flöden som ser identiska ut på en instrumentpanel. Vidarebefordrad trafik passerar genom ASA:n: en LAN-värd skickar till insamlaren, ASA:n matchar det mot tunnelpolicyn, krypterar det, och insamlaren ser värdens adress. Genererad trafik börjar på ASA:n själv: enheten bygger ett syslog-paket, väljer ett utgångsgränssnitt och en källa och frågar först därefter om någon tunnelpolicy passar. Det första flödet bevisar att tunneln fungerar, och det säger ingenting om det andra.

En buffrad händelse på enheten är inte heller bevis på fjärrleverans, eftersom loggen kan finnas lokalt och aldrig ha skickats. Kontrollera insamlarens mottagningsräknare innan du skyller på tunneln, eftersom en tom räknare är ett annat fynd än en som växer.

Ett genererat meddelande är inte vidarebefordrad trafik

När ASA:n själv skapar ett paket proxar den inte för en LAN-värd. Källan kommer från utgångsgränssnittet eller från en explicit källinställning, och paketet går genom samma vägsökning och samma policykontroller som allt annat enheten skickar. Det innebär att VPN-selektorn måste innehålla adressen som ASA:n faktiskt använder, och det är ofta dess yttre gränssnitt snarare än ett internt subnät.

Om policyn skyddar 10.20.0.0/24 och ASA:n använder sin yttre adress som källa, lämnar loggpaketet antingen i klartext mot en insamlare som det inte kan nå, eller så släpps det. Båda utfallen ser identiska ut från insamlarens sida. Samma resonemang gäller för administrationstrafik, och därför är management-access ett separat designbeslut.

Vilken källa ASA:n sätter på linjen

Hitta källan empiriskt i stället för genom antagande. En fångst på utgångsgränssnittet under ett testmeddelande visar den faktiska källan och destinationen, och det tar mindre tid än att läsa tre konfigurationsavsnitt. Jämför den adressen med tunnelns lokala selektor.

Vissa versioner låter dig fästa loggkällan vid ett gränssnitt, och kommandoreferensen för din version är auktoriteten för om det alternativet finns och vad det ändrar. Ett source-interface-kommando från en annan Cisco-plattform är inte automatiskt giltigt på en ASA.

Om du ändrar källan ska du göra det medvetet och anteckna det, eftersom insamlarens ACL:er och all korrelation som byggs på syslog beror på den.

Anpassa selektorn till loggflödet

När källan är känd, kontrollera tre saker i ordning: krypto-ACL:n eller den policybaserade selektorn som avgör vilken trafik som är intressant, vägen som avgör vart paketet tar vägen, och varje NAT-regel som kan skriva om källan före krypteringen. Ett paket som matchar vägen men inte selektorn tunnlas inte, och ett paket som skrivs om av NAT matchar kanske ingen av dem.

Insamlarsidan har egna krav: en ACL som tillåter ASA:ns källa, en returväg och en lyssnande tjänst på porten du konfigurerade. Transport spelar roll här också, eftersom TCP- och TLS-loggning beter sig annorlunda än UDP på en delvis blockerad väg. Ändra ett element i taget, annars berättar nästa fångst inte vilken ändring som spelade roll.

Verifiera hos insamlaren och anteckna sedan källan

Bekräfta att meddelandet kommer fram och skriv sedan ned källadressen som ASA:n använde, selektorn som bar den och den allvarlighetsgrad du testade med.

Den anteckningen gör nästa ACL-ändring eller selektorredigering hos insamlaren till en tvåminuterskontroll i stället för en återupptäckt. Den dokumenterar också vilket av de två flödena som någonsin validerats, och det är den delen de flesta runbooks utelämnar. Om meddelandet fortfarande inte kommer fram, sänk allvarlighetsgradströskeln tillfälligt och testa mot en enda destination.

Cisco FAQ om ASA-loggning dokumenterar ett fall med extern källa som kräver motsvarande definition av skyddad trafik, och deras exempel med intern källa omfattar både en loggvärd på insidan och management-access på insidan. Behandla den dokumenterade kombinationen och programvarukontexten tillsammans i stället för att anta att en kopierad rad passar varje konfiguration.

En tunnel som bär LAN-trafik är inte en tunnel som bär brandväggens egen röst.