Einleitung

Der Zustand err-disable ist ein Schutzmechanismus von Cisco-Switches. Erkennt der Switch ein kritisches Problem auf einem Port, wird dieser in den Status err-disabled gesetzt und automatisch administrativ deaktiviert. Der Port verarbeitet ab diesem Zustand keinen Traffic mehr. Im Gegensatz zu einem normalen shutdown wurde der Port dabei nicht manuell, sondern durch eine interne Schutzfunktion deaktiviert.

Für Außenstehende wirkt das oft zunächst wie ein kaputter Port, tatsächlich handelt es sich aber im Regelfall um eine bewusst ausgelöste Sicherheits- oder Schutzfunktion. Häufig tritt dann der Fall ein, dass mehrere Ports am Switch getestet werden und somit eine große Zahl an Ports unabsichtlich gesperrt werden.

Typische Symptome

• Geräte verlieren plötzlich die Verbindung
• Der Link scheint „down“
• LEDs verhalten sich ungewöhnlich
• Der Port erscheint im Status err-disabled

Switch# show interface status

Port       Name        Status         Vlan
Gi1/0/1                err-disabled   10

Ziel und Zweck

Der err-disabled-Status ist also in vielen Fällen ein Schutzmechanismus für das gesamte Netzwerk.

• Netzwerkschleifen verhindern
• Broadcast-Stürme verhindern
• Fehlkonfigurationen erkennen
• Port-Security-Verstöße
• Hardwareprobleme isolieren

Ursachen

Diagnose

Prüfung der Err-Disabled-Konfiguration

show errdisable detect zeigt die aktuellen Einstellungen der Errdisable-Erkennung sowie, falls sich Ports derzeit im err-disabled-State befinden, den jeweiligen Grund für die automatische Deaktivierung des Ports an.

Switch# show errdisable detect
ErrDisable Reason             Detection Mode
-----------------             --------- ----
arp-inspection                Enabled  port
bpduguard                     Enabled  port
channel-misconfig             Enabled  port
community-limit               Enabled  port
dhcp-rate-limit               Enabled  port
dtp-flap                      Enabled  port
evpn-mh-core-isolation        Enabled  port
gbic-invalid                  Enabled  port
iif-reg-failure               Enabled  port
inline-power                  Enabled  port
invalid-policy                Enabled  port
l2ptguard                     Enabled  port
link-flap                     Enabled  port
link-monitor-failure          Enabled  port
loopback                      Enabled  port
loopdetect                    Enabled  port
lsgroup                       Enabled  port
oam-remote-failure            Enabled  port
mac-limit                     Enabled  port
pagp-flap                     Enabled  port
port-mode-failure             Enabled  port
pppoe-ia-rate-limit           Enabled  port
psecure-violation             Enabled  port/vlan
security-violation            Enabled  port
sfp-config-mismatch           Enabled  port
sgacl_limitation:enforcem     Enabled  port
sgacl_limitation:multiple     Enabled  port
storm-control                 Enabled  port
udld                          Enabled  port
psp                           Enabled  port
dual-active-recovery          Enabled  port
evc-lite input mapping fa     Enabled  port
vsl-and-non-vsl-port-pair     Enabled  port
fasthello-and-non-fasthel     Enabled  port
mvrp                          Enabled  port
mrp-miscabling                Enabled  port

show errdisable recovery zeigt den Zeitraum an, nach dem Ports bei bestimmten Errdisable-Ursachen automatisch wieder aktiviert werden. Außerdem werden die konfigurierten Errdisable-Recovery-Mechanismen angezeigt.

Switch# show errdisable recovery

ErrDisable Reason              Timer Status
-----------------              --------------
arp-inspection                 Disabled
bpduguard                      Disabled
channel-misconfig              Disabled
dhcp-rate-limit                Disabled
dtp-flap                       Disabled
evpn-mh-core-isolation         Disabled
gbic-invalid                   Disabled
inline-power                   Disabled
l2ptguard                      Disabled
link-flap                      Enabled
mac-limit                      Disabled
link-monitor-failure           Disabled
loopback                       Disabled
loopdetect                     Disabled
oam-remote-failure             Disabled
pagp-flap                      Disabled
port-mode-failure              Disabled
pppoe-ia-rate-limit            Disabled
psecure-violation              Disabled
security-violation             Disabled
sfp-config-mismatch            Disabled
storm-control                  Enabled
udld                           Enabled
psp                            Disabled
dual-active-recovery           Disabled
evc-lite input mapping fa      Disabled
mrp-miscabling                 Disabled

Timer interval: 900 seconds

Interfaces that will be enabled at the next timeout:

Status des Ports prüfen

Zunächst sollte geprüft werden, in welchem Zustand sich die Ports befinden.
Mit folgendem Befehl erhält man eine Übersicht aller Ports und deren aktuellen Status:

Switch# show interface status

Oder man lässt sich einen Port im Detail anzeigen.

Switch# show interface Gi1/0/1

Dabei lassen sich unter anderem folgende Zustände erkennen:

• err-disabled
• connected
• notconnect
• disabled

Err-disabled Ports gezielt anzeigen

Um ausschließlich Ports im err-disabled-Status inklusive Ursache anzuzeigen, kann folgender Befehl verwendet werden:

Switch# show interfaces status err-disabled

Port      Name        Status         Reason                Vlans
Gi1/0/1   ERRORPORT   err-disabled   psecure-violation     10

Event- und System-Logs prüfen

Für die eigentliche Fehleranalyse sind die System- und Event-Logs besonders wichtig. Dort protokolliert der Switch in der Regel sehr genau, warum ein Port in den err-disabled-State versetzt wurde.

Die Logs können mit folgendem Befehl angezeigt werden:

Switch# show logging

Die Logmeldungen liefern meist bereits den entscheidenden Hinweis auf die eigentliche Ursache des Problems und sollten daher immer als einer der ersten Schritte geprüft werden.

Entstörung

Fehlerursache beheben

Vor einem manuellen oder automatischen Recovery sollte immer zuerst die eigentliche Ursache des err-disabled-Status behoben werden, da der Fehler ansonsten unmittelbar erneut auftreten kann.

Ports manuell reaktivieren

Um einen Port aus dem Fehlerstatus zu befreien, muss der betroffene Port einmal deaktiviert und anschließend wieder aktiviert werden.

Switch# configure terminal

Switch(config)# interface Gi1/0/1
shutdown
no shutdown

Ports automatisch reaktivieren

Die folgenden Befehle zeigen, wie die automatische Entstörung konfiguriert wird.

Zunächst lassen wir uns die möglichen Optionen bzw. Ursachen anzeigen, welche wir konfigurieren können.

Switch# configure terminal
Switch(config)# errdisable recovery cause ?
  all                   Enable timer to recover from all causes
  arp-inspection        Enable timer to recover from arp inspection error
                        disable state
  bpduguard             Enable timer to recover from BPDU Guard error disable
                        state
  channel-misconfig     Enable timer to recover from channel misconfig disable
                        state
  dhcp-rate-limit       Enable timer to recover from dhcp-rate-limit error
                        disable state
  dtp-flap              Enable timer to recover from dtp-flap error disable
                        state
  gbic-invalid          Enable timer to recover from invalid GBIC error disable
                        state
  l2ptguard             Enable timer to recover from l2protocol-tunnel error
                        disable state
  link-flap             Enable timer to recover from link-flap error disable
                        state
  link-monitor-failure  Enable timer to recover from link monitoring failure
  loopback              Enable timer to recover from loopback disable state
  mac-limit             Enable timer to recover from mac limit disable state
  oam-remote-failure    Enable timer to recover from remote failure detected by
                        OAM
  pagp-flap             Enable timer to recover from pagp-flap error disable
                        state
  psecure-violation     Enable timer to recover from psecure violation disable
                        state
  security-violation    Enable timer to recover from 802.1x violation disable
                        state
  storm-control         Enable timer to recover from storm-control error
                        disable state
  udld                  Enable timer to recover from udld error disable state
  unicast-flood         Enable timer to recover from unicast flood disable
                        state
  vmps                  Enable timer to recover from vmps shutdown error
                        disable state

Danach definieren wir diese dann entweder einzeln oder allgemeingültig über den all-Parameter.

Switch(config)# errdisable recovery cause bpduguard

Über die zuvor genannten show-Befehle lässt sich die nun gültige Konfiguration anzeigen.

Quellen

• cisco.com – Wiederherstellung aus dem errdisable-Portstatus auf Cisco IOS-Plattformen
• firewall.cx – Cisco Catalyst Err-disabled Port State, Enable & Disable Autorecovery Feature

Der Beitrag Cisco – Err-Disabled-Status erschien zuerst auf Maximilian Krieg.

Problem

Fehlermeldung

Die folgende Meldung wird den Anwendern angezeigt. Im Browser ist weder ein Zertifikat sichtbar noch eine Fehlermeldung zu Zertifikaten ersichtlich, was darauf hindeutet, dass die Verbindung bereits vorher abbricht. Auffällig ist, dass nicht alle Webseiten betroffen sind und auch nicht alle Browser-Varianten. Der Edge-Browser in der aktuellen Version zeigt dieses Problem nicht, ebenso wenig ein älterer Firefox. Aktualisierte Versionen verschiedener Browser führen jedoch zu dem beschriebenen Fehler.

Betroffene Browser

Fortinet hat derweil eine Liste betroffener Browser veröffentlicht. Diese lassen sich wie folgt zusammenfassen.

• Google Chrome 131
• Firefox 132
• Microsoft Edge 131.0.2903.48 (Stable)

Ursache

Der Auslöser für dieses Problem hängt mit der Einführung von Modular-Lattice Key Encapsulation Mechanism (ML-KEM) für den post-quantenfähigen TLS-Schlüsselaustausch zusammen. Diese Methode hat kürzlich X25519Kyber768 für hybriden post-quantenfähigen Schlüsselaustausch in Chromium-basierten Browsern ersetzt. Das Problem wird derzeit bei Fortinet im Case #1097642 untersucht.

SSL-Inspection in den UTM/NGFW-Modes

Fortinet hat angekündigt, an Lösungen innerhalb der IPS-Engine (Versionen 7.0 bis 7.6) zu arbeiten, was darauf hindeutet, dass der Support für die ML-KEM-Methode derzeit speziell in der IPS-Engine problematisch ist. Ein von Fortinet empfohlener Workaround besteht darin, auf den Proxy-Modus umzuschalten, da in diesem Modus die Entschlüsselung außerhalb der IPS-Engine stattfindet.

Dies ist eine gute Gelegenheit, die Unterschiede zwischen den verschiedenen Betriebsmodi der SSL-Inspection zu beleuchten. Hierzu führe ich aus den Herstellerdokumenten die Flow-Diagramme auf und verweise den jeweiligen Anwendungspunkt der SSL-Inspection und IPS-Engine.

Lösungen

Fortinet bietet mehrere Workarounds für das beschriebene Problem an. In meinem Blog möchte ich mich jedoch auf die FortiGate-basierten Lösungen konzentrieren, da diese aus meiner Sicht einfacher umzusetzen sind und keine Änderungen an Browsern oder Betriebssystemen erfordern. Der Fokus liegt darauf, praktikable Lösungen direkt auf der Firewall-Ebene anzuwenden, um die Sicherheit und Funktionalität so effizient wie möglich sicherzustellen.

Inspection-Mode auf Proxy-based umstellen

Das aus meiner Sicht einfachste und effektivste Verfahren zur Lösung des Problems ist die Umstellung des Modus auf Proxy-based. Der Fehler tritt ausschließlich in Kombination mit Flow-based-Policies und aktivierter SSL-Deep-Inspection auf. Durch die Umstellung auf den Proxy-Modus bleibt die Prüfung der SSL-Verbindung vollständig erhalten, ohne dass Ausnahmen definiert werden müssen.

Zusätzlich bietet der Proxy-Modus potenzielle Vorteile, da er die gründlichste Inspektion für UTM- und NGFW-Funktionen ermöglicht. Insbesondere bei Richtlinien, die den Schutz vor bösartigen Inhalten gewährleisten sollen, wird grundsätzlich empfohlen, den Proxy-Modus einzusetzen. Er sorgt für eine umfassendere Sicherheitskontrolle und reduziert das Risiko, dass Bedrohungen unbemerkt bleiben.

SSL-Inspection-Ausnahme festlegen

Fortinet schlägt als zweite Variante vor, eine Ausnahme für die betroffenen oder relevanten Webseiten im SSL-Inspection-Profil einzurichten. Dadurch wird die SSL-Inspection für diese Seiten komplett deaktiviert, selbst wenn die zugehörige Firewall-Regel diese Funktion ursprünglich verlangt. Diese Methode kann jedoch zu einem erhöhten administrativen Aufwand führen, da kontinuierlich Anpassungen erforderlich sind, bis ein langfristiger Fix von Fortinet bereitgestellt wird.

SSL-Inspection abschalten

Anstatt für einzelne Webseiten nun Ausnahmen zu definieren oder den Inspektionsmodus auf Proxy-based umzustellen, besteht auch die Möglichkeit, die SSL-Inspektion vollständig zu deaktivieren oder auf das Verfahren der einfachen Zertifikatsüberprüfung (Certificate Inspection) umzustellen. Diese Ansätze verringern jedoch das allgemeine Sicherheitsniveau erheblich. Daher sollten sie nur in gut begründeten Ausnahmefällen in Betracht gezogen werden, da es sicherere und effektivere Alternativen gibt.

Quellen

• ERR_SSL_PROTOCOL_ERROR when using Flow-based Deep Inspection due to ML-KEM post-quantum TLS key exchange
• Google Online Security Blog: A new path for Kyber on the web
• UTM/NGFW packet flow: flow-based inspection | Fortinet Document Library
• Inspection mode feature comparison | Fortinet Document Library
• Exempting applications/domains/websites from SSL Inspection | Fortinet Community

Der Beitrag FortiGate – ERR_SSL_PROTOCOL_ERROR nach Browser-Updates mit aktiver SSL-Deep-Inspection erschien zuerst auf Maximilian Krieg.

Fortinet FortiGate

Die FortiGate-Firewall ist ein Next Generation Firewall (NGWF), die von Fortinet entwickelt wurde. Sie bietet umfassenden Schutz für Netzwerke, indem sie den Datenverkehr überwacht, analysiert und steuert.

Allgemein

• Network Interface Card NIC commands
• How to clear interface counters from CLI

FortiOS 6.4

• FortiOS v6.4 Cheatsheet | Tech Blog (boll.ch)
• FortiOS v6.4 CLI reference | Fortinet Document Library

FortiOS 7.0

• FortiOS v7.0 Cheatsheet | Tech Blog (boll.ch)
• FortiOS v7.0 CLI reference | Fortinet Document Library

FortiOS 7.2

• FortiOS v7.2 Cheatsheet | Tech Blog (boll.ch)
• FortiOS v7.2 CLI reference | Fortinet Document Library

FortiOS 7.4

• FortiOS v7.4 Cheatsheet | Tech Blog (boll.ch)
• FortiOS v7.4 CLI reference | Fortinet Document Library
• FortiOS v7.4 CLI troubleshooting cheat sheet | Fortinet Document Library

FortiOS 7.6

• FortiOS v7.6 CheatSheet | Tech Blog (boll.ch)
• FortiOS v7.6 CLI reference | Fortinet Document Library

Fortinet FortiAnalyzer

Der FortiAnalyzer ist eine leistungsstarke Plattform für Protokollverwaltung, Analysen und Berichterstattung. Er bietet Organisationen eine einzige Konsole zur Verwaltung, Automatisierung, Orchestrierung und Reaktion.

FortiAnalyzer 6.4

• FortiAnalyzer v6.4 Cheatsheet | Tech Blog (boll.ch)
• FortiAnalyzer v6.4 | Fortinet Document Library

FortiAnalyzer 7.0

• FortiAnalyzer v7.0 Cheatsheet | Tech Blog (boll.ch)
• FortiAnalyzer v7.0 CLI reference | Fortinet Document Library

FortiAnalyzer 7.2

• FortiAnalyzer v7.2 CLI reference | Fortinet Document Library

FortiAnalyzer 7.4

• FortiAnalyzer v7.4 CLI reference | Fortinet Document Library

Fortinet FortiManager

Der FortiManager ist eine zentrale Plattform zur Verwaltung von Fortinet-Geräten und Richtlinien in verschiedenen Umgebungen. Er ermöglicht die zentrale Administration von unter anderem FortiGate-Firewalls, FortiAnalyzer, FortiSwitches, FortiAPs und FortiExtender-Geräten.

FortiManager 6.4

• FortiManager v6.4 CLI reference | Fortinet Document Library

FortiManager 7.0

• FortiManager v7.0 Cheatsheet | Tech Blog (boll.ch)
• FortiManager v7.0 CLI reference | Fortinet Document Library

FortiManager 7.2

• FortiManager v7.2 CLI reference | Fortinet Document Library

FortiManager 7.4

• FortiManager v7.4 CLI reference | Fortinet Document Library

Der Beitrag Fortinet – Cheatsheets für CLI-Befehle erschien zuerst auf Maximilian Krieg.

Zur Kontextualisierung, die Infrastruktur besteht aus Cisco Email Security Appliances (ESAs) und Cisco Security Management Appliances (SMAs). Die ESA ist eine virtuelle All-in-One-Appliance, die Schutz vor Spam, Malware, Viren und anderen ein- und ausgehenden E-Mail-Bedrohungen und Belästigungen bietet . Die SMA hingegen wird zur Zentralisierung von Diensten von ESAs verwendet. Die zentralisierten Dienste sind: Externe Spam-Quarantäne. Zentralisierte Richtlinien-, Viren- und Ausbruchsquarantänen.

Die Störung betrifft daher nach vorheriger Definition somit die SMA und nicht die ESA. Da der Kunde einen Fehler auf den vorgeschalteten Systemen ausschließt, beginnen wir mit der Untersuchung auf der aktiven SMA-Einheit. Bei der ersten Prüfung stellt sich bereits heraus, dass ein System-Backup ausgeführt wird, wodurch Dienste eingeschränkt oder pausiert sind. Dies ist ein normales und erwartetes Verhalten; jedoch läuft das Backup üblicherweise täglich, und dieser Fehler tritt zum ersten Mal auf.

Wir überprüfen daher die Backup-Einstellungen und -Status auf der Kommandozeile der SMA, indem wir in die Backup-Konfiguration navigieren. Da die SMA die gleichen Befehle im Folgenden immer wieder präsentieren wird, schneide ich diesen Auszug aus den folgenden Ausgaben heraus. Die relevanten Befehle sind hier VIEW, VERIFY, SCHEDULE, CANCEL, STATUS und SETUP.

SMA01> backupconfig

Choose the operation you want to perform:
- VIEW - View scheduled backups
- VERIFY - Verify if backup can be scheduled to a remote machine
- SCHEDULE - Schedule backup to an appliance
- CANCEL - Cancel a scheduled backup
- STATUS - Show the status of a backup in progress.
- SETUP - Configure backup parameters.

Zunächst überprüfen wir die laufenden Backup-Jobs und stellen fest, dass die Backups täglich um 2 Uhr von der aktiven SMA01 zur passiven SMA02 durchgeführt werden. Wir verifizieren ebenfalls, dass ein Backup-Job noch aktiv ist, wie in der AdminGUI angezeigt wird.

[]> view

Scheduled Backups:
# Name                 IP                  Schedule           Features
= ==================== =================== ================== ==================
1 SMA01_to_SMA02       To 10.10.10.2       In Progress        Email Tracking
                                                              Web Tracking
                                                              Spam Quarantine
                                                              Reporting
                                                              Policy Quarantine
                                                              Safelist/Blocklist
2 SMA01_to_SMA02       To 10.10.10.2       every day at       Email Tracking
                                           02:00              Web Tracking
                                                              Spam Quarantine
                                                              Reporting
                                                              Policy Quarantine
                                                              Safelist/Blocklist

Aus diesem Grund überprüfen wir den Status des laufenden Backup-Jobs. Obwohl das Backup wie geplant um 2 Uhr gestartet ist, läuft es nun bereits seit über zwei Stunden. Normalerweise sind die Backups innerhalb weniger Minuten abgeschlossen. Um sicherzustellen, dass alles korrekt verläuft, warten wir etwa 10 Minuten. Bei einer Datentransferrate von 14 MB/s sollte eine messbare Veränderung im übertragenen Datenvolumen von 81 GB auftreten.

[]> STATUS

Backup Name: SMA01_to_SMA02
Begin Time: 29 Dec 2023 02:00    Time elapsed: 2hr 32min
Transfer Rate: 14MB/s
Phase: Two
Data Transferred: 81GB (44%)
        Web Tracking: Completed
        Reporting: Completed
        Email Tracking: Completed
        Policy Quarantine: Completed
        Spam Quarantine: In Progress  Transferred: 0GB (0%)
Phase: One
Data Transferred: 0GB
        Web Tracking: Completed
        Reporting: Completed
        Email Tracking: Completed
        Policy Quarantine: Completed
        Spam Quarantine: Completed
        Safelist/Blocklist: Completed

Bei der nächsten Kontrolle ergibt sich, dass bei angeblich anhaltenden 14MB/s keine Veränderung am transferierten Datenvolumen stattgefunden hat. Es ist wahrscheinlich, dass das Backup hängengeblieben ist und nicht fortgesetzt wird.

[]> STATUS

Backup Name: SMA01_to_SMA02
Begin Time: 29 Dec 2023 02:00    Time elapsed: 2hr 45min
Transfer Rate: 14MB/s
Phase: Two
Data Transferred: 81GB (44%)
        Web Tracking: Completed
        Reporting: Completed
        Email Tracking: Completed
        Policy Quarantine: Completed
        Spam Quarantine: In Progress  Transferred: 0GB (0%)
Phase: One
Data Transferred: 0GB
        Web Tracking: Completed
        Reporting: Completed
        Email Tracking: Completed
        Policy Quarantine: Completed
        Spam Quarantine: Completed
        Safelist/Blocklist: Completed

Wir brechen das Backup manuell ab, damit der Wartungsmodus beendet wird und die SMA wieder ihre normale Operation aufnimmt.

[]> CANCEL

Scheduled Backups:
# Name                 IP                  Schedule           Features
= ==================== =================== ================== ====================
1 SMA01_to_SMA02       To 10.10.10.2       In Progress        Email Tracking
                                                              Web Tracking
                                                              Spam Quarantine
                                                              Reporting
                                                              Policy Quarantine
                                                              Safelist/Blocklist
2 SMA01_to_SMA02       To 10.10.10.2       every day at       Email Tracking
                                           02:00              Web Tracking
                                                              Spam Quarantine
                                                              Reporting
                                                              Policy Quarantine
                                                              Safelist/Blocklist

Select the name or number of the backup
[]> 1

Canceling a backup in progress is not recommended. The data will be incomplete
and may not be usable until a subsequent backup is completed, especially if you
receive an error. If you must cancel a backup in progress, be sure to run a
complete backup as soon as possible to ensure that you always have a usable
current backup.

Do you really want to cancel the backup? [N]> Y

Backup "SMA01_to_SMA02" has been cancelled.

Wir lassen uns nochmals den Status anzeigen, um den korrekten Abbruch zu verifizieren.

[]> STATUS

No backup in progress

Auf der AdminGUI ist die Fehlermeldung nun verschwunden und der Zugriff auf die Spam-Quarantäne-Seite ist wieder erfolgreich. Um das versäumte Backup nachzuholen, planen wir ein einmaliges Backup und führen dieses durch.

[]> SCHEDULE

Enter the IP address of a machine to transfer data to.
[]> 10.10.10.2

Enter a name to identify the remote appliance
[]> SMA02

Please enter username and passphrase:
Username:
[]> admin

Passphrase:
[]>
Would you like to backup all the data, including Email Tracking, Web Tracking,
Spam Quarantine, Reporting, Policy Quarantine, Safelist/Blocklist ? [Y]> Y

Verifying target machine for version compatibility and disk space...
1. Set up a repeating backup schedule
2. Schedule a single backup
3. Start a single backup now
[1]> 3

Please enter a name for this backup job:
[]> Test-Backup

Backup "Test-Backup" has been initiated and will begin in a few seconds.

Das temporäre Backup ist, wie erwartet, innerhalb weniger Minuten durchgelaufen. Als abschließende Maßnahme überprüfen wir die Schedules, um sicherzustellen, dass die Backups auch am Folgetag ordnungsgemäß durchgeführt werden, sowie den Zugriff auf die Spam-Quarantäne-Seite.

Quellen

• Ansetzen einer Sicherung eines aktiven Datensets von einer primären SMA zu einer sekundären SMA – Cisco

Der Beitrag Cisco SMA – Spam-Quarantäne-Seite ausgefallen erschien zuerst auf Maximilian Krieg.

Die globalen Einstellungen betreffen die Admin-Oberfläche. Wir haben hier zuvor manuelle Parameter gesetzt für die TLS-Mindeststandards, wechseln nun jedoch auf den Strong-Crypto-Befehl. Das Verbot von RSA-Chiffren ist zwar implizit durch die anderen Parameter gegeben, wurde jedoch bei einem Audit als wünschenswert festgelegt und wird daher beibehalten. Ebenfalls werden mehrere Hash-Verfahren deaktiviert, um das unsichere AES-128-CBC abzuschalten. Wie in einem Technical Tip beschrieben, kann AES-128-CBC nicht selbst deaktiviert werden, weshalb ein Workaround über die Hash-Verfahren genutzt werden kann. Einen exklusiven Umstieg auf TLS 1.3, welches die unsicheren Chiffren nicht mehr unterstützt, haben wir auch diskutiert, jedoch noch nicht ins Auge gefasst.

config system global
    set strong-crypto enable
    set ssl-static-key-ciphers disable
    set admin-https-ssl-banned-cipher RSA SHA1 SHA256 SHA384
    set dh-params 8192
end

Wenn die starke Verschlüsselung (Strong-Crypto) aktiviert ist, sind nur noch TLS 1.2 und TLS 1.3 zulässig. Der Strong-Crypto-Befehl hat jedoch keine Auswirkung auf die SSL-VPN-Verschlüsselungsstufe oder -Chiffren. Für die SSL-VPN-Einstellungen setzen wir daher TLS 1.2 als Mindeststandard und verbieten die gleichen Chiffren wie zuvor. Über den Algorith-High-Befehl werden ebenfalls ältere und unsichere Chiffren verboten.

config vpn ssl setting
    set algorithm high
    set ssl-min-proto-ver tls1-2
    set banned-cipher RSA SHA1 SHA256 SHA384
end

Abschließend kontrollieren wir mithilfe von Qualys den neuen Status und führen einen erneuten Scan durch. Es ergibt sich nun eine Bewertung mit A+ mit voller Bewertung in drei Kategorien.

Quellen

• Technical Tip: Disable AES CBC ciphers for SSL VPN and Admin GUI (HTTPS) Access
• Technical Tip: Cipher suites offered by FortiGate
• Hardening | FortiGate / FortiOS 7.4.0 | Fortinet Document Library
• FortiGate encryption algorithm cipher suites | FortiGate / FortiOS 7.4.2 | Fortinet Document Library
• BSI-TR-02102.pdf (bund.de)

Der Beitrag Fortinet – Chiffren für SSL VPN und Admin GUI härten erschien zuerst auf Maximilian Krieg.

Analyse

Zunächst unterziehen wir die letzten Ereignisse im Zusammenhang mit dem betroffenen Zertifikat einer sorgfältigen Prüfung, um mögliche weiterführende Hinweise zu identifizieren.

diagnose sys acme status-full <Certificate’s CN domain>

In diesem Kontext fällt auf, dass seit der Ausstellung beziehungsweise dem letzten Erneuerungsvorgang keine relevanten Ereignisse aufgezeichnet wurden. Ebenfalls interessant ist, dass der Error-Counter den Wert 0 aufweist. Die Ausgabe wurde selbstverständlich aus Gründen der Vertraulichkeit durch die Anpassung von Geräte- und Kundennamen modifiziert.

FGT # diagnose sys acme status-full fgt.customer.com
{
  "name": "fgt.customer.com",
  "finished": true,
  "notified": false,
  "last-run": "Tue, 24 Oct 2023 11:07:21 GMT",
  "valid-from": "Tue, 24 Oct 2023 10:07:29 GMT",
  "errors": 0,
  "last": {
    "status": 0,
    "detail": "The certificate for the managed domain has been renewed successfully and can be used (valid since Tue, 24 Oct 2023 10:07:29 GMT). A graceful server restart now is recommended.",
    "valid-from": "Tue, 24 Oct 2023 10:07:29 GMT"
  },
  "log": {
    "entries": [
      {
        "when": "Tue, 24 Oct 2023 11:07:31 GMT",
        "type": "message-renewed"
      },
      {
        "when": "Tue, 24 Oct 2023 11:07:31 GMT",
        "type": "finished"
      },

Im folgenden Schritt überprüfen wir, ob eine erfolgreiche PING-Kommunikation mit den für das Erneuerungsvorhaben zuständigen LetsEncrypt-Servern möglich ist. Ebenfalls prüfen wir die korrekte Funktionalität der Namensauflösung auf der Firewall, die für diesen Zweck erforderlich ist.

execute ping acme-v02.api.letsencrypt.org
PING 172.65.32.248 (172.65.32.248): 56 data bytes
64 bytes from 172.65.32.248: icmp_seq=0 ttl=255 time=22.3 ms
64 bytes from 172.65.32.248: icmp_seq=1 ttl=255 time=22.2 ms
64 bytes from 172.65.32.248: icmp_seq=2 ttl=255 time=22.2 ms
64 bytes from 172.65.32.248: icmp_seq=3 ttl=255 time=22.2 ms
64 bytes from 172.65.32.248: icmp_seq=4 ttl=255 time=22.2 ms
--- 172.65.32.248 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 22.2/22.2/22.3 ms

Sowohl die Namensauflösung als auch die Erreichbarkeit sind gewährleistet. Daher führen wir eine erneute Überprüfung des Status des ACME-Clients durch und stellen bei genauer Inspektion fest, dass überhaupt kein Interface definiert ist.

FGT # get system acme status
Listening on interfaces:        None
ACME certificates registered:   1
ACME challenge type:            http-01

Wir gleichen dies erneut mit der Konfiguration ab, und die Überprüfung bestätigt die fehlerhafte Konfiguration.

FGT # config system acme
FGT (acme) # show
config system acme
    config accounts
        edit "ACME-.letsencrypt.org-0000"
            set status "valid"
            set ca_url "https://acme-v02.api.letsencrypt.org/directory"
            set email "mail@customer.com"
        next
    end
end

Auch hier erkennen wir, dass kein Interface konfiguriert ist, über das der ACME-Client die Zertifikatsvalidierung durchführen soll. Zur Fehlerbehebung setzen wir daher das entsprechende Interface im ACME-Client.

FGT # config system acme
FGT (acme) # set interface wan
FGT (acme) # end

Renewal-Prozess

Nachdem wir das Renewal manuell initiiert haben, überprüfen wir den Status des Zertifikats erneut mithilfe des Diagnose-Befehls. Der folgende Auszug veranschaulicht den vollständigen und korrekten Zertifizierungsdialog.

FGT # diagnose sys acme status-full fgt.customer.com
{
  "name": "fgt.customer.com",
  "finished": true,
  "notified": false,
  "next-run": "Wed, 27 Dec 2023 08:54:24 GMT",
  "last-run": "Tue, 26 Dec 2023 09:54:20 GMT",
  "valid-from": "Wed, 27 Dec 2023 08:54:24 GMT",
  "errors": 0,
  "last": {
    "status": 0,
    "detail": "The certificate for the managed domain has been renewed successfully and can be used from Wed, 27 Dec 2023 08:54:24 GMT on.",
    "valid-from": "Wed, 27 Dec 2023 08:54:24 GMT"
  },
  "log": {
    "entries": [
      {
        "when": "Tue, 26 Dec 2023 09:54:26 GMT",
        "type": "finished"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:26 GMT",
        "type": "progress",
        "detail": "The certificate for the managed domain has been renewed successfully and can be used from Wed, 27 Dec 2023 08:54:24 GMT on."
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:25 GMT",
        "type": "progress",
        "detail": "Retrieving certificate chain for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:25 GMT",
        "type": "progress",
        "detail": "Waiting for finalized order to become valid"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:24 GMT",
        "type": "progress",
        "detail": "Submitting CSR to CA for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:24 GMT",
        "type": "progress",
        "detail": "Creating CSR for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:24 GMT",
        "type": "progress",
        "detail": "Finalizing order for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:23 GMT",
        "type": "progress",
        "detail": "Waiting for order to become ready"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:23 GMT",
        "type": "progress",
        "detail": "Monitoring challenge status for fgt.customer.com: domain authorization for fgt.customer.com is valid"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:23 GMT",
        "type": "progress",
        "detail": "Monitoring challenge status for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:22 GMT",
        "type": "progress",
        "detail": "Starting challenges for domains"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:22 GMT",
        "type": "progress",
        "detail": "Loaded order from staging"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:21 GMT",
        "type": "progress",
        "detail": "Selecting account to use for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:21 GMT",
        "type": "progress",
        "detail": "Driving ACME protocol for renewal of fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:20 GMT",
        "type": "progress",
        "detail": "Contacting ACME server for fgt.customer.com at https://acme-v02.api.letsencrypt.org/directory"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:20 GMT",
        "type": "progress",
        "detail": "Assessing current status"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:20 GMT",
        "type": "progress",
        "detail": "Checking staging area"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:20 GMT",
        "type": "progress",
        "detail": "Monitoring challenge status for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:20 GMT",
        "type": "starting"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:19 GMT",
        "type": "progress",
        "detail": "Monitoring challenge status for fgt.customer.com: domain authorization for fgt.customer.com is valid"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:19 GMT",
        "type": "progress",
        "detail": "Monitoring challenge status for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:18 GMT",
        "type": "progress",
        "detail": "Setting up challenge 'http-01' for domain fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:18 GMT",
        "type": "progress",
        "detail": "Starting challenges for domains"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:17 GMT",
        "type": "progress",
        "detail": "Creating new order"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:16 GMT",
        "type": "progress",
        "detail": "Selecting account to use for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:16 GMT",
        "type": "progress",
        "detail": "Driving ACME protocol for renewal of fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:16 GMT",
        "type": "progress",
        "detail": "Resetting staging for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:15 GMT",
        "type": "progress",
        "detail": "Contacting ACME server for fgt.customer.com at https://acme-v02.api.letsencrypt.org/directory"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:15 GMT",
        "type": "progress",
        "detail": "Assessing current status"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:15 GMT",
        "type": "progress",
        "detail": "Resetting staging area"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:15 GMT",
        "type": "progress",
        "detail": "Checking staging area"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:15 GMT",
        "type": "starting"
      }
    ]
  }
}

Das Zertifikat ist somit erfolgreich neu verifiziert und ausgestellt worden. Es ist jedoch zu beachten, dass das Startdatum des neuen Zertifikats nicht sofort wirksam wird, sondern erst im Rahmen des nächsten Durchlaufs des ACME-Clients übernommen wird. Die relevanten Termine sind im Header des Auszugs angegeben.

• last-run: Tue, 26 Dec 2023 09:54:20 GMT
• next-run: Wed, 27 Dec 2023 08:54:24 GMT
• valid-from: Wed, 27 Dec 2023 08:54:24 GMT

Daher überprüfen wir am 27. Dezember 2023 den Status des Zertifikats auf der FortiGate. Durch das Aufrufen der durch dieses Zertifikat geschützten Inhalte bestätigen wir, dass nun das korrekte Zertifikat verwendet wird. Es ist jedoch zu beachten, dass die Zeitzone GMT verwendet wird.

Weitere Ursachen

Während meiner Recherche und Analyse identifizierte ich die folgenden Fehlerquellen als häufige Ursachen:

1. Falsche Konfiguration des ACME-Clients oder fehlende Definition von Interfaces.
   • Überprüfen Sie die Einstellungen des ACME-Clients und stellen Sie sicher, dass die relevanten Interfaces ordnungsgemäß konfiguriert sind.
2. Fehlende oder nicht funktionierende DNS-Server.
   • Prüfen Sie, ob DNS-Server der FortiGate korrekt konfiguriert sind und Namensauflösung möglich ist.
3. Probleme mit der Certificate Authority (CA) von LetsEncrypt und der Vertrauensstellung der FortiGate.
   • Stellen Sie sicher, dass die FortiGate das CA-Zertifikat von LetsEncrypt korrekt vertraut.
4. Explizite Verbote durch Local-In-Policy für Verbindungen zu Port 80/443.
   • Überprüfen Sie die Local-In-Policy, um sicherzustellen, dass keine Einschränkungen für die Kommunikation zu Port 80/443 bestehen.
5. Konflikte mit anderen Diensten auf Port 443, wie SSL-VPN, Virtual Server oder Virtual IP.
   • Stellen Sie sicher, dass keine Konflikte mit anderen Diensten auf demselben Port bestehen.
6. Vorhandensein von Proxy- und Firewall-Diensten vor der FortiGate mit restriktiven Regelwerken.
   • Überprüfen Sie die Konfiguration von Proxy- und Firewall-Diensten vor der FortiGate auf mögliche Restriktionen in deren Regelwerken.
7. Firmware-Bugs, insbesondere in Version 7.2.3 mit Problemen bei mehreren hinterlegten Interfaces.
   • Überprüfen Sie, ob bekannte Bugs in der Firmware, insbesondere in der Version 7.2.3, vorliegen und ggf. auf eine aktualisierte Firmware-Version upgraden.
8. Generelle Bugs in der eingesetzten Firmware.
   • Konsultieren Sie die Release Notes der Firmware, um festzustellen, ob bekannte Bugs existieren und prüfen Sie gegebenenfalls auf verfügbare Updates.

Quellen

• https://community.fortinet.com/t5/FortiGate/Technical-Tip-Expiring-Let-s-Encrypt-Certificates/ta-p/198419
• https://letsencrypt.org/docs/allow-port-80/
• https://blog.pingus.de/2022/01/28/enable-lets-encrypt-certificate-on-ssl-vpn-enabled-fortigate-interface/
• https://blog.andreas-schreiner.de/2021/08/31/lets-encrypt-zertifikat-fuer-fortigate-ssl-vpn-vips-und-web-ui/

Der Beitrag Fortinet – LetsEncrypt-Zertifikat erneuert sich nicht erschien zuerst auf Maximilian Krieg.

Monitoring-Schwellwerte

Dem Monitoring-Team stellen wir folgende Schwellwerte als Empfehlung für sämtliche LetsEncrypt-Zertifikate des Kunden, unabhängig davon welches System sie präsentiert oder verlängert, zur Verfügung:

• Warnung – Ab 28 bis 30 Tagen
• Fehler – Ab 5 bis 7 Tagen

Erst bei Eintreten des Fehlerzustands im Monitoring-System sollte ein Ticket erzeugt werden. 5 bis 7 Tage sollten genug Zeit sein den Prozess manuell zu starten oder in die Fehleranalyse zu gehen, warum der Automated Certificate Management Environment (ACME)-Client das Zertifikat nicht korrekt innerhalb des Standard-Intervalls erneuert hat. Standardmäßig hat ein LetsEncrypt-Zertifikat eine Laufzeit von 90 Tagen und erst ab 60 Tagen ist es eigentlich zum Renewal vorgesehen. Mehr Informationen hierzu findet man in der ACME Renewal Information (ARI).

Die oben genannte Werte sind bereits individuell angepasst auf die Konfiguration der Kunden-spezifischen Umgebung. Ebenfalls denkbar wären folgende, allgemeinen Schellwerte, wenn nur einmal am Tag eine Prüfung der Laufzeiten erfolgt:

• Warnung – Ab 30 Tagen
• Fehler – Ab 28 Tagen

Renewal-Prozess

Die FortiGate-Firewalls sehen im Standard vor, dass ein Zertifikat 30 Tage vor Ablauf den Renewal-Prozess initiieren.

config vpn certificate local
    edit <ACME_certificate_name>
        set acme-renew-window 30
    end

Über folgende Befehle kann man dann ein Zertifikat manuell, auch vor den 30 Tagen, erneuern.

ACME-Status prüfen:

get system acme status
get system acme acc-details

Zertifikate erneuern:

diagnose sys acme regenerate-client-config
diagnose sys acme restart

2-3 Minuten warten, danach neue Laufzeiten je Zertifikat kontrollieren:

get vpn certificate local details <Local certificate name>
diagnose sys acme status-full <Certificate’s CN domain>

Quellen

• Improving Resiliency and Reliability for Let’s Encrypt with ARI – Let’s Encrypt (letsencrypt.org)
• Troubleshooting Tip: Let’s Encrypt certificate did… – Fortinet Community
• draft-ietf-acme-ari-02 – Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension

Der Beitrag Fortinet – LetsEncrypt-Zertifikate manuell erneuern erschien zuerst auf Maximilian Krieg.

Umgebung

Die Infrastruktur besteht aus zwei autarken FortiGate-Clustern, einem Cisco ISE-Cluster mit zwei Nodes sowie einem Entrust Identity Essentials-Cluster aus zwei Servern. Alle Systeme sind auf zwei getrennte Rechenzentren verteilt. Die folgende Darstellung ist stark vereinfacht und bezieht sich darauf, welches System jeweils den primären Zugriffsweg darstellt. Die Cisco ISE Nodes und die Entrust-Server sind zwar geclustert, aber haben eigene IP-Adressen und lassen sich eigenständig ansprechen. Über Prioritäten beziehungsweise Sequenzreihenfolgen werden die Primär- und Sekundärsysteme festgelegt.

Bei einer Anmeldung für das RAVPN sendet das jeweilige FortiGate Cluster einen RADIUS-Access-Request zur primären Cisco ISE. Diese leiten es ihrerseits die Anfrage weiter an die Entrust-Server, welche dann nach korrekter AD-Authentifizierung den Code versendet.

Analyse und Anpassung

Im Troubleshooting-Prozess wird nun geprüft, ob zunächst die Firewall-Regeln zwischen allen Systemen korrekt aufgebaut sind und die Kommunikationswege jeweils zugelassen sind. Dies gilt auch für die Cluster-interne Kommunikation, da hier die Cluster in jeweils Standort-spezifischen Subnetzen stehen und das Forwarding über die Firewalls erfolgt. Hier kann kein Fehler festgestellt werden.

Da die Anmeldungen, egal ob an das VPN-Gateway im Datacenter A und Datacenter B an der primären Cisco ISE ankommen und protokolliert werden, können die beiden Firewall-Cluster aus der Fehlerbetrachtung ausgeschlossen werden. Ebenfalls werden die Cisco ISE unter den RADIUS-Servers als erreichbar gemeldet.

Wir ändern unseren Fokus nun daher auf die Cisco ISE. Ein früherer Ausfalltest der ISE zeigt, dass auch hier kein Unterschied darin besteht, welche Cisco ISE der aktive Node ist. Beide Cisco ISE sind hinsichtlich der RADIUS-Einstellungen identisch respektive synchronisiert zum Zeitpunkt der Fehleranalyse.

Wir sehen jedoch im Firewall-Log sowie im Live Capture, dass keine RADIUS-Requests von der Cisco ISE zum sekundären Entrust-Server erfolgen. Wir prüfen daher nun die Einstellungen auf der Cisco ISE im Detail. Hier gibt es bereits erste Auffälligkeiten, denn der sekundäre Entrust-Server taucht in keiner der RADIUS-Konfigurationen auf. Wir korrigieren dies und fügen ihn als External RADIUS Server hinzu und nehmen in auch gleich in die RADIUS Server Sequences auf.

Zuletzt ergänzen wir den sekundären Entrust-Server noch in den External Identity Sources in den RADIUS Tokens als Secondary Server, da hier der primäre Entrust-Server auch hinterlegt ist. An dieser Stelle sei angemerkt, dass die Shared Secrets an beiden Stellen nochmals mit den dokumentierten Werten kontrolliert sind und übereinstimmen.

Ab jetzt sehen wir auch Netzwerkverbindungen zum sekundären Server. Diese werden jedoch negativ mit einem Reject von dem Server beantwortet.

Wir gehen daher nun zuletzt auf die beiden Entrust-Server und kontrollieren hier die Konfiguration im Entrust Identity Essentials – Configuration Tool. Hier gleichen wir die Einstellungen ab. Parallel prüfen wir das Windows Event Log, da hier Ereignisse zum Windows NPS-Dienst und Entrust protokolliert werden. Sicherheitshalber prüfen wir auch, ob die beiden Cisco ISE als RADIUS-Clients im Windows NPS hinterlegt sind und die korrekten Shared Secrets verwendet werden. Die NPS-Einstellungen sind jedoch unauffällig.

Wir stellen allerdings fest, dass der zweite Entrust-Server exklusiv den primären Entrust-Server als Authentication backed service host referenziert. Der primäre Entrust-Server verweist ebenfalls exklusiv auf sich selbst. Aus diesem Grund können auch Codes versendet werden, wenn wir der Cisco ISE die Verbindung zum primären Entrust-Server verbieten, aber die Kommunikation zwischen den Entrust-Servern noch zulassen. Wir nehmen daher beide Server in die Konfiguration des jeweils anderen Servers auf und stellen ein, dass jeder der Server sich selbst mit höchster Priorität verwendet.

Wir wiederholen nun die Tests in verschiedenen Konstellationen, diese verlaufen nun positiv und der Code wird versendet. Der Ausfalltest kann nun erfolgreich abgeschlossen werden.

Zusammenfassung

Zusammenfassend sind nun folgende Schritte erfolgt:

1. FortiGate-Firewalls
   • Kontrolle der Firewall-Regeln
   • Kontrolle der VPN- und RADIUS-Einstellungen
2. Cisco ISE
   • Kontrolle des ISE-Cluster-Status
   • Kontrolle der RADIUS-Konfiguration
   • Anlage des sekundären Entrust-Servers in der ISE an mehreren Stellen
   • Kontrolle des Shared Secrets auf Korrektheit
3. Entrust-Server
   • Kontrolle Windows NPS-Dienst und Shared Secrets auf Korrektheit
   • Kontrolle Windows Event Log auf beiden Entrust-Servern
   • Kontrolle Entrust-Konfiguration auf beiden Entrust-Servern
   • Anlage des sekundären Entrust-Servers im Configuration Tool

Der Beitrag Entrust Identity Essentials – Failover auf zweiten Member im Cluster schlägt fehl erschien zuerst auf Maximilian Krieg.

Symptom

Ein Desktop-PC ist physisch direkt mit dem Management-Interface eines Layer-3-Switches verbunden. Der Ping von dem PC zum Switch auf die IP-Adresse 192.168.1.1 funktioniert problemlos. Ein Ping vom Switch zum PC auf die IP-Adresse 192.168.1.3 hingegen nicht. Dieses Problem bleibt auch bestehen, wenn die Firewall des PCs deaktiviert wird. Mit Hilfe eines zweiten Switches kann verifiziert werden, dass der PC generell auf einen Ping anspricht.

Mit diesen Informationen übernehme ich das Problem. Ich überprüfe alle getätigten Einstellungen und rekonstruiere dann das beschriebene Verhalten. Das Problem wird vermutlich auf dem Switch und in seiner Konfiguration zu suchen sein. Ich pinge zunächst selbst den PC und versuche dann die eigene Adresse zu pingen.

switch# ping 192.168.1.3
PING 192.168.1.3 (192.168.1.3): 56 data bytes
ping: sendto 192.168.1.3 64 chars, No route to host
Request 0 timed out
ping: sendto 192.168.1.3 64 chars, No route to host
Request 1 timed out

(...)

--- 192.168.1.3 ping statistics ---
5 packets transmitted, 0 packets received, 100.00% packet loss

switch# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
ping: sendto 192.168.1.1 64 chars, No route to host
Request 0 timed out
ping: sendto 192.168.1.1 64 chars, No route to host
Request 1 timed out

(...)

--- 192.168.1.1 ping statistics ---
5 packets transmitted, 0 packets received, 100.00% packet loss

Letzteres Resultat habe ich nicht erwartet. Wieso sollte sich der Layer-3-Switch nicht auf seinem eigenen Interface pingen können? Es erhärtet meinen Verdacht, dass bei der Konfiguration etwas schiefgegangen ist.

Problem

Zunächst hole ich mir Informationen über die Netzwerkschnittstellen des Layer-3-Switches ein. Mich interessiert, ob das Management-Interface überhaupt aktiv gelistet wird. Ich weiß natürlich, dass es aktiv sein muss, damit der Ping vom PC aus überhaupt funktioniert, aber irgendwo muss ich die Fehlersuche beginnen.

switch# show interface brief

------------------------------------------------------------------------------------------
Ethernet 	VLAN	Type	Mode	Status	Reason			Speed	Port Ch
Interface#	
------------------------------------------------------------------------------------------
Eth1/1		1	eth	access	down	SFP not inserted	10G(D)	--

(...)

Eth2/6		1	eth	access	down	SFP not inserted	40G(D)	--

------------------------------------------------------------------------------------------
Port	VRF	Status	IP Address					Speed	MTU
------------------------------------------------------------------------------------------
mgmt0	--	up	192.168.1.1					1000	1500

Offensichtlich ist das Interface aktiv und auch mit der korrekten IP-Adresse versehen. Auf den ersten Blick scheint es doch nicht an der aktiven Konfiguration zu liegen. Um dies zu verifizieren, lasse ich mir die aktuelle Konfiguration anzeigen

switch# show running-config

(...)

vlan 1
vrf context management

(...)

interface Ethernet1/1

(...)

interface mgmt0
  vrf member management
  ip address 192.168.1.1/24

line console
line vty

boot kickstart bootflash:/n6000-uk9-kickstart.7.0.2.N1.1.bin
boot system bootflash:/n6000-uk9.7.0.2.N1.1.bin

poap transit

Ich bin nun mehrmals über die Abkürzung VRF gestolpert, die mir bisher auch nicht bekannt ist. Eine kleine Recherche hierzu ergibt auch schon des Rätsels Lösung.

Lösungsstrategie

Die Abkürzung VRF steht für Virtual Routing and Forwarding. Eine VRF-Instanz bezeichnet eine im Cisco IOS und Routing Hardware anderer Hersteller implementierte Funktion, die einen neuen virtuellen Router auf einem physischen Router anlegt. Durch das Anlegen eines virtuellen Routers entsteht ein komplett neues Netz, d. h. in der VRF-Instanz 1, 2, 3, …, n kann jedes mal der komplette Adressraum vergeben werden und jedes ausgehende Interface einer jeder Instanz mit der gleichen IP-Adresse vergeben werden, obwohl für die angeschlossenen Hosts nur die Hosts derselben Instanz sichtbar sind. Eine Kommunikation zwischen Instanzen ist ohne internes, explizites Routing nicht möglich.Wikipedia

Ein genauer Blick in die Hilfe zum ping-Befehl zeigt mir, dass man als optionalen Parameter auch die VRF-Instanz angeben kann.

switch# ping -help
usage: ping {<host> | multicast <group>} [count <count>]
        [packet-size <size>] [vrf <vrf>] [interval <interval] [df-bit]

Ich passe meine Eingabe an und ergänze diese um den den Parameter VRF-Context.

switch# ping
Vrf context to use [default] :management
Target IP address or Hostname: 192.168.1.1
Repeat count [5] : 5
Packet-size [56] :
Timeout in seconds [2] :
Sending interval in seconds [0] :
Extended commands [no] :
Sweep range of sizes [no] :
Sending 5, 56-bytes ICMP Echos to 192.168.1.1
Timeout is 2 seconds, data pattern is 0xABCD

64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=0.298 ms

(...)

--- 192.168.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.156/0.195/0.298 ms

switch# ping
Vrf context to use [default] :management
Target IP address or Hostname: 192.168.1.3
Repeat count [5] :
Packet-size [56] :
Timeout in seconds [2] :
Sending interval in seconds [0] :
Extended commands [no] :
Sweep range of sizes [no] :
Sending 5, 56-bytes ICMP Echos to 192.168.1.3
Timeout is 2 seconds, data pattern is 0xABCD

64 bytes from 192.168.1.3: icmp_seq=0 ttl=127 time=0.659 ms

(...)

Sowohl der Ping auf die lokale und die entfernte Schnittstellenadresse funktioniert. Es wurde einfach vergessen anzugeben von welcher Instanz der Ping abgesetzt werden soll. Die Kurzform für diesen Befehl wäre ping 192.168.1.3 vrf management.

Der Beitrag Layer-3-Switch kann keinen Ping absetzen erschien zuerst auf Maximilian Krieg.