Site-VPN werkt, maar ASA-logs komen niet aan: controleer het bronadres

Interne hosts bereiken de externe collector en hun syslog-regels verschijnen. De eigen berichten van de ASA over dezelfde sessies komen nooit aan. Er is niets mis met de collector of met de tunnel, en dat is het verwarrende deel. De firewall verstuurt zijn logs vanaf een bron die de tunnel nooit had moeten beschermen.

Wat aankomt en wat niet

Begin met twee stromen te scheiden die op een dashboard identiek lijken. Doorgestuurd verkeer gaat door de ASA: een LAN-host stuurt naar de collector, de ASA vergelijkt het met het tunnelbeleid, versleutelt het, en de collector ziet het adres van de host. Gegenereerd verkeer begint op de ASA zelf: het apparaat bouwt een syslog-pakket, kiest een uitgangsinterface en bron en vraagt pas daarna of enig tunnelbeleid past. De eerste stroom bewijst dat de tunnel werkt, en hij zegt niets over de tweede.

Een gebufferde gebeurtenis op het apparaat is ook geen bewijs van externe aflevering, want de log kan lokaal bestaan en nooit zijn verzonden. Controleer de ontvangsttellers van de collector voordat u de tunnel de schuld geeft, want een lege teller is een andere bevinding dan een die groeit.

Een gegenereerd bericht is geen doorgestuurd verkeer

Wanneer de ASA zelf een pakket genereert, is hij niet aan het proxyen voor een LAN-host. De bron komt van de uitgangsinterface of van een expliciete broninstelling, en het pakket gaat door dezelfde routeopzoeking en dezelfde beleidscontroles als alles wat het apparaat verstuurt. Dat betekent dat de VPN-selector het adres moet bevatten dat de ASA werkelijk gebruikt, en dat is vaak zijn buiteninterface in plaats van een intern subnet.

Als het beleid 10.20.0.0/24 beschermt en de ASA gebruikt zijn buitenadres als bron, dan verlaat het logpakket ofwel in platte tekst richting een collector die het niet kan bereiken, ofwel het wordt weggegooid. Beide uitkomsten zien er vanaf de collectorkant identiek uit. Dezelfde redenering geldt voor beheerverkeer, en daarom is management-access een aparte ontwerpbeslissing.

Welke bron de ASA op de lijn zet

Vind de bron empirisch in plaats van door aanname. Een opname op de uitgangsinterface tijdens een testbericht toont de werkelijke bron en bestemming, en dat kost minder tijd dan drie configuratiesecties lezen. Vergelijk dat adres met de lokale selector van de tunnel.

Sommige releases laten u de logbron aan een interface vastmaken, en de commandoreferentie voor uw versie is de autoriteit over of die optie bestaat en wat hij verandert. Een source-interface-commando van een ander Cisco-platform is niet automatisch geldig op een ASA.

Als u de bron wijzigt, doe dat dan bewust en noteer het, want de ACL’s van de collector en elke correlatie op basis van syslog hangen ervan af.

Laat de selector bij de logstroom passen

Zodra de bron bekend is, controleer drie dingen in volgorde: de crypto-ACL of op beleid gebaseerde selector die bepaalt welk verkeer interessant is, de route die bepaalt waar het pakket heen gaat, en elke NAT-regel die de bron vóór versleuteling kan herschrijven. Een pakket dat bij de route past maar niet bij de selector wordt niet getunneld, en een pakket dat door NAT is herschreven past mogelijk bij geen van beide.

De collectorkant heeft eigen eisen: een ACL die de bron van de ASA toestaat, een retourroute en een luisterende dienst op de poort die u hebt geconfigureerd. Transport is hier ook van belang, want TCP- en TLS-logging gedragen zich anders dan UDP op een gedeeltelijk geblokkeerd pad. Wijzig één element per keer, anders vertelt de volgende opname u niet welke wijziging ertoe deed.

Controleer bij de collector en noteer daarna de bron

Bevestig dat het bericht aankomt, noteer dan het bronadres dat de ASA gebruikte, de selector die het droeg en de ernst waarmee u hebt getest.

Die vastlegging maakt de volgende ACL-wijziging of selector-aanpassing op de collector een controle van twee minuten in plaats van een herontdekking. Ze documenteert ook welke van de twee stromen ooit is gevalideerd, en dat is het deel dat de meeste runbooks overslaan. Als het bericht nog steeds niet aankomt, verlaag tijdelijk de ernstdrempel en test tegen één bestemming.

De FAQ over ASA-logging van Cisco documenteert een geval met externe bron dat de bijbehorende definitie van beschermd verkeer nodig heeft, en het voorbeeld met interne bron omvat zowel een loghost aan de binnenkant als management-access aan de binnenkant. Behandel de gedocumenteerde combinatie en de softwarecontext samen, in plaats van aan te nemen dat één gekopieerde regel bij elke configuratie past.

Een tunnel die LAN-verkeer draagt, is geen tunnel die de eigen stem van de firewall draagt.