ASA Troubleshooting Best Practise
anbei eine kurze Erklärung der wichtigsten Troubleshooting Techniken wenn es auf der ASA Probleme mit Sessions gibt:
1) Bei den meisten nachfolgenden Befehlen ist eine Art grep möglich - mit "|" nach dem Befehl. Nach der Pipe ("|") können dann folgende Schlüsselwörter verwendet werden:
begin Begin with the line that matches
exclude Exclude lines that match
grep Include/exclude lines that match
include Include lines that match
Bsp.: show conn | include 10.1.1.1
=> es werden nur Verbindungen angezeigt, wo 10.1.1.1 vorkommt
2) show conn
Mit diesem Befehl werden die aktiven Sessions angezeigt. Wichtig sind hier die Flags in der letzten Spalte. Die Bedeutung der Flags kann mit "show conn det" angezeigt werden.
Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,
B - initial SYN from outside, C - CTIQBE media, D - DNS, d - dump,
E - outside back connection, F - outside FIN, f - inside FIN,
G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,
i - incomplete, J - GTP, j - GTP data, K - GTP t3-response
k - Skinny media, M - SMTP data, m - SIP media, O - outbound data,
P - inside back connection, q - SQL*Net data, R - outside acknowledged FIN,
R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,
s - awaiting outside SYN, T - SIP, t - SIP transient, U - up, W - WAAS,
X - inspected by service module
Interessant ist dieser Command, wenn eine Session nicht aufgebaut werden kann - dann sieht man meist die Flags S oder s -> TCP Threeway Handshake nicht fertig - Routingproblem?
3) show local-host
Mit diesem Befehl sieht man detaillierte Infos über aktive Sessions. Am Ende kann noch eine IP Adresse angegeben werden, dann werden nur Verbindungen für diese Adresse angezeigt. Die Bedeuting der Flags ist wieder die selbe wie bei "show conn"
4) syslog
Mit syslog werden alle relevanten Sessions erfasst, egal ob erlaubt oder abgewiesen. Es kann das log entweder im Buffer oder auf einem Server angeschaut werden. Ein Syslog Server ist immer die beste Lösung, da man dort einen längeren Zeitraum beobachten kann. Der buffer für die Syslogs auf der Firewall ist begrenzt.
Eine weitere Möglichkeit mit guten Filtermöglichkeiten ist der Log Viewer im ASDM.
In den logs sieht man sehr schnell, ob eine Verbindung verboten wird, oder das NAT falsch konfiguriert ist usw.
5) show asp drop
Hier erhält man eine Statistik über Drop Ursachen - jedes Mal wenn die Firewall ein Paket verschmeißt, wird der Grund hier angezeigt. Vor dem Troubleshooten mit "clear asp drop" löschen und schauen, welcher Counter hochzählt -> für Eingrenzung interessant.
Bsp.:
zur Info: Die einzelnen Positionen werden nur eingeblendet, wenn es einen Hit gibt.
asa(config)# sh asp drop
Frame drop:
Invalid TCP Length 1
No valid adjacency 16
Flow is denied by configured rule 18346
First TCP packet not SYN 2042
TCP data exceeded MSS 6520
TCP MSS was too large 8
TCP data send after FIN 2
TCP failed 3 way handshake 5639
TCP RST/FIN out of order 182
TCP Out-of-0rder packet buffer full 3890
TCP Out-of-Order packet buffer timeout 714
TCP RST/SYN in window 1
TCP DUP and has been ACKed 18798
TCP packet failed PAWS test 4
IPSEC tunnel is down 4
Slowpath security checks failed 5
ICMP Inspect seq num not matched 766
DNS Inspect id not matched 226
FP L2 rule drop 11
Interface is down 70
Invalid ASDP packet received from SSM card 1
Flow drop:
Need to start IKE negotiation 1116
Service module failed 2
Beispiel: Wenn manche Websites nicht aufgerufen werden können, gibt es oft das Problem, dass ein Kommunikationspartner Pakete ungleich der ausgehandelten MSS schickt. Ein Indikator für das Problem ist der "TCP MSS was too large" Counter. Die Lösung dazu wird im folgenden Link beschrieben:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a00804c8b9f.shtml6) capture
Mit diesem Befehl ist es möglich, Sessions mitzusniffen. Die Traces können dann im tcpdump Format von der Firewall downgeloadet werden und z.B.: im Wireshark ausgewertet werden. Damit kann herausgefunden werden, ob Pakete an einem Interface ankommen und am anderen Interface wieder weitergeleitet werden und ob etwas verändert wurde.
Bsp:
In einer ACL wird definiert, welcher Verkehr mitgesnifft werden soll.
access-list wmcap extended permit ip host 10.1.1.133 host 10.2.3.13
access-list wmcap extended permit ip host 10.2.3.13 host 10.1.1.133
capture cap1 type asp-drop all
capture cap3 type raw-data access-list wmcap buffer 1024000 packet-length 96 interface outside
capture cap2 type raw-data access-list wmcap buffer 1024000 packet-length 96 interface inside
Der tcpdump ist dann unter der url
https://asa-ip/capture/capture-name/dump zu finden.
Mit show capture capture-name kann eine Übersicht zu den gesnifften Paketen angezeigt werden.
7) packet-tracer
Das ist eine gute Erweiterung zum capture command, denn es wird der Flow Schritt für Schritt durch die ASA angezeigt und der Grund, warum das Paket pro Schritt erlaubt/verboten wird. Es handelt sich dabei nur um eine Simulation ("Rule Tester").
Bsp.:
ciscoasa(config)#packet-tracer input outside icmp 172.22.1.6 8 0 172.16.10.1 detailed
Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow
Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 172.16.10.0 255.255.255.0 outside
Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x3bd8480, priority=111, domain=permit, deny=true
hits=0, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
8) debug icmp trace
Hier werden alle ICMP Pakete von und zur Firewall angezeigt - hilft um z.B. Routingprobleme zu finden
Wenn das Problem gefunden ist, den Debug mit "no debug icmp trace" wieder deaktivieren
9) Überlast der Firewall
Um eine Überlast der Firewall bestimmen zu können, sind "show blocks" und "show cpu" sehr hilfreich. Mit dem ersten Befehl werden die System Buffer angezeigt und mit dem zweiten die CPU Load.
