ASA sporadisch laut Monitoring unerreichbar
Regelmäßig verschwindet eine ASA aus dem Monitoring per SNMP. Die Maschine läuft allerdings anstandslos durch, nur auf SNMP antwortet sie nicht. Überlastung? Keine Spur. Es ist NAT im Spiel.
Was haben wir nicht alles probiert: Capture der Datenpakete, Statistiken über die Nichterreichbarkeit, … Alles ohne Erfolg. Schließlich besteht der Zustand nur kurz. Gerade lange genug, um nach einem Alarm nicht mehr zu existieren.
Heute war es anders. Heute war der Ausfall stabil. Und da konnte man endlich mal suchen. Ein packet-tracer offenbarte, daß NAT im Spiel ist und das Paket auf ein internes Interface weitergereicht werden sollte.
Mehr erstaunt als überrascht zeigte die NAT-Tabelle tatsächlich einen solchen Eintrag:
# sh xlate gport 161
2123 in use, 8541 most used
Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice
e - extended
UDP PAT from inside:192.0.2.101/123 to outside:203.0.113.17/161 flags ri
idle 0:02:03 timeout 0:00:30Was zur Hölle soll das? Wieso benutzt die ASA diese reservierten Ports für normale Nutzung?
Die Dokumentation erwähnt zu den PAT Regeln:
PAT translates multiple real addresses to a single mapped IP address by translating the real address and source port to the mapped address and a unique port. If available, the real source port number is used for the mapped port. However, if the real port is not available, by default the mapped ports are chosen from the same range of ports as the real port number: 0 to 511, 512 to 1023, and 1024 to 65535. Therefore, ports below 1024 have only a small PAT pool that can be used.
Liegt also der Quellport im Bereich 0-511, so wird dieser in den Bereich 0-511 genattet. Dort reserveriert die ASA aber nicht die Ports, die sie selbst braucht und fertig ist das Chaos.
Mit neueren Versionen kann man pat-pool benutzen. Dieses Kommando kann explizit Portbereiche auswählen und damit auch ausschließen. Man könnte also direkt pat-pool interface flat einsetzen, wenn damit nicht der komplette Bereich 0-1023 gesperrt würde.
Unglücklicherweise es gibt einige Anwendungen, die Annahmen über die Quellports ihrer Kommunikationspartner machen. Dazu gehört IPSec. Man kann also nicht einfach den kompletten Bereich sperren.
Man müßte die lokal benutzten Ports einzeln freihalten. Und das scheint im Bugfix für CSCty16661 tatsächlich geschehen zu sein.
Oder man spricht gleich SNMP über IPv6 …