vCloud Director Edge Gateway Syslog Events

Es ist leider eine besondere Herausforderung für Service Provider die vCloud Director Edge Gateway Syslog Events der Tenants einzusammeln. Diese Logs sind zum Beispiel für eine Diagnose der Edge Gateway Firewall Aktionen notwendig. VMware beschreibt eine mögliche Lösung, wenn auch sehr oberflächlich, in dem vCAT-SP Guide Architecting a VMware vCloud Director® Solution for VMware vCloud Air™ Network unter dem Begriff Service Network. Ein anderer Ansatz den ich aber direkt verworfen habe ist, dass der Tenant innerhalb seines VMware vCloud Director VDC selbst eine VMware vRealize Log Insight Appliance bereitstellt und die Firewall und NAT Regeln für die Weiterleitung selbst erstellt.

Der Grundgedanke des Service Network ist, den Tenants, wenn ein Edge Gateway vorhanden ist, ein zusätzliches Netzwerk als External Network anzubinden. In diesem Netzwerk können dann Services wie Syslog oder andere Management Systeme untergebracht werden. Für einige Services genügt es, in diesem Netzwerk eine einzelne Instanz ohne weitere Anbindung zu haben. Für andere wiederum ist die Anbindung an globale Management Systeme notwendig. Syslog soll in meinem Fall unbedingt an ein übergeordnetes vRealize Log Insight Cluster angebunden werden, erfordert daher weitreichendere Konfigurationen als in dem vCAT-SP Guide beschrieben.

vCloud Director Edge Gateway Syslog Events – Konzept

Um die VMware vCloud Director Edge Gateway Syslog Events der Kunden sicher in das übergeordnete VMware vRealize Log Insight Cluster zu transportieren habe ich mir das folgende Konzept in meinem Lab erarbeitet.

  • Syslog Events werden an einzelne vRealize Log Insight Appliance im Service Network gesendet
  • einzelne vRealize Log Insight Appliance leitet an übergeordneten Cluster im Management Netzwerk weiter

Die einzelne vRealize Log Insight Appliance sitzt dabei auf einem NSX Logical Switch, kann also mit Distributed Firewall (DFW) geschützt werden und die Daten von einem Distributed Logical Router (DLR) in das globale Management Netz (klassisches VLAN) weitergeleitet werden.

vCloud Director Edge Gateway Syslog Events - Konzept

vCloud Director Edge Gateway Syslog Events – Umsetzung

NSX Logical Switch

Als „DMZ“ für die weiterleitende VMware vRealize Log Insight Appliance habe ich einen eigenen Logical Switch angelegt. Dieses Netz steht zu diesem Zeitpunkt erst einmal nicht im VMware vCloud Director zur Verfügung.

vCloud Director Edge Gateway Syslog Events - Logical Switch

NSX Distributed Logical Router

Um die vCloud Director Edge Gateway Syslog Events an das  übergeordnete VMware vRealize Log Insight Cluster weiterzuleiten, welches sich in einem klassischen VLAN (Name: VLAN1095) befindet habe ich einen DLR zum Routing zwischen diesen beiden Netzen angelegt.

vCloud Director Edge Gateway Syslog Events - DLR

vCloud Director Edge Gateway Syslog Events - DLR Interfaces

Das Routing Logging sollte genauso wie die Edge Gateway Syslog Einstellungen konfiguriert werden:

Die Routen aus dem übergeordneten Management Netz zu dem Netz 10.10.100.0/24 müssen in meinem Lab leider als Statische Routen auf den Relevanten Systemen (vRealize Log Insight Appliances, DNS Server, NTP Server) gesetzt werden.

NSX Distributed Firewall

Um die weiterleitende VMware vRealize Log Insight Appliance (Name: VLI10) best möglich zu schützen habe ich mit der Distributed Firewall nur die notwendigsten Services freigegeben.

  • Das Netz 192.168.95.0/24 ist in meinem Lab das übergeordnete Management Netz
  • Das Netz 10.10.100.0/24 ist in meinem Lab das Service Network

vCloud Director Edge Gateway Syslog Events - DFW

vCloud Director Default Syslog Servers

Damit neue Edge Gateways direkt den Syslog Server gesetzt bekommen kann im vCloud Director ein Default Syslog Server konfiguriert werden.

vCloud Director Edge Gateway Syslog Events - Default Syslog

Bereits bestehende Edge Gateways müssen einmal von Hand Synchronisiert werden.

vCloud Director Edge Gateway Syslog Events - Syncronize Edge

Die Synchronisation kann auch per VMware PowerCLI für alle Edge Gateway im vCloud Director Bestand gestartet werden:

Search-Cloud -QueryType EdgeGateway -Name * | Get-CIView | %{$_.SyncSyslogServerSettings()}

vCloud Director External Network

Um das zusätzliche External Network für die Edge Gateways im vCloud Director  zur Verfügung zu haben, muss das Netz mit dem passenden Subnet angelegt werden.

vCloud Director Edge Gateway Syslog Events - External Network

Dann kann den Tenant Edge Gateways der zusätzliche Uplink hinzugefügt werden. Das Default Gateway bleibt das „echte“ externe Netz.

vCloud Director Edge Gateway Syslog Events - Edge Uplink

vRealize Log Insight Forwarding

Die weiterleitende VMware vRealize Log Insight Appliance benötigt in meinem Setup keine weitere Konfiguration außer NTP und DNS. Nur die Weiterleitung muss natürlich eingerichtet werden.

vCloud Director Edge Gateway Syslog Events - Event Forwarding

Kleines Manko an meinem Lab Setup ist das fehlende SSL für die Weiterleitung. Ab VMware vRealize Log Insight 4.5 kann Weiterleitung per SSL das nur mit einem sauberen Zertifikat aktiviert werden.

vCloud Director Edge Gateway Syslog Events in Log Insight

Damit Log Einträge für bestimmte Firewall Aktionen überhaupt generiert werden, muss an der Firewall Regel unter Action noch die Zusatzoption „Log“ gesetzt werden – Standard ist „Do not log“.

Um mir schnell einen Überblick über die aktuellen Log Einstellungen der einzelnen Edge Firewall Regeln zu machen ist das PowerShell Modul PowerNSX absolut genial.

Alle vorhanden Edge Firewall Regeln anzeigen (ohne System Regeln):

Get-NsxEdge | Get-NsxEdgeFirewall | Get-NsxEdgeFirewallRule | where { $_.ruleType -notmatch 'internal' } | ft

vCloud Director Edge Gateway Syslog Events - PowerNSX - Get Edge Firewall Rules

Um für alle Edge Firewall User-Regeln das Logging zu aktivieren, habe ich mir dieses kleine PowerShell Skript erstellt:

foreach ( $Rule in (Get-NsxEdge | Get-NsxEdgeFirewall | Get-NsxEdgeFirewallRule | where { $_.ruleType -match 'user' })) {
    $URI = "/api/4.0/edges/$($Rule.EdgeID)/firewall/config/rules/$($Rule.ID)"
    $req = Invoke-NsxWebRequest -URI $URI -method get
    $Content = [xml]$req.Content
    $Content.firewallRule.loggingEnabled = "true"
    $response = Invoke-NsxWebRequest -URI $URI -method put -body $Content.firewallRule.OuterXml
}

Ein Update der Edge Firewall Rule per API in Postman könnte übrigens so aussehen:

vCloud Director Edge Gateway Syslog Events - PowerNSX - NSX API - Update Edge Firewall Rule

Leider kann im VMware vCloud Director 8.20 der Tanant die Option zum Loggen nicht immer selbst aktivieren, in der HTML5 UI fehlt diese Option bei den Firewall Aktionen. Also muss der Service Provider für alle Edge Gateways mit aktivierten Advanced Services diese Option selbst bei Bedarf setzen.

Ist das Log für eine Firewall Regel aktiviert (hier im Beispiel Drop) ist das Event auch in vRealize Log Insight zu finden.

Wer das NSX Content Pack kennt, dem ist eventuell aufgefallen, dass der benutzte Filter ein selbst erstelltes Field ist. Der originale funktioniert leider nicht.

Mein Field:

Content Pack Field:

Wer das ebenfalls gerne behoben hätte, darf gerne für meinen Log Insight Community Request Voten.

vCloud Director Distrubuted Firewall Syslog Events in Log Insight

Für diese Events ist keine besondere Konfiguration der Umgebung erforderlich, diese Daten werden direkt aus den ESXi Logs ausgelesen.

Das Problem mit der fehlende Option für das Log in der HTML5 UI ist aber ebenfalls vorhanden. Der Provider muss auch hier selbst eingreifen für die DFW Log´s.

Um mir schnell einen Überblick über die aktuellen Log Einstellungen der einzelnen DFW Regeln zu verschaffen ist das PowerShell Modul PowerNSX wieder absolut genial.

Alle vorhanden DFW Regeln mit PowerNSX anzeigen:

Get-NsxFirewallSection | %{Get-NsxFirewallRule -Section $_} | ft

vCloud Director Edge Gateway Syslog Events - PowerNSX - Get DFW Rules

Um bei allen DFW Regel bis auf die „Default Section“ das Logging zu aktivieren, hat Nick Bradford ein PowerNSX Beispiel Skript in dem GitHub Repository zur Verfügung gestellt:

foreach ( $section in (Get-NsxFirewallSection | ? { $_.name -notmatch 'Default Section Layer3' })) {
    $req = Invoke-NsxWebRequest -URI "/api/4.0/firewall/globalroot-0/config/layer3sections/$($section.id)" -method get
    $content = [xml]$req.Content
    foreach ($rule in $content.section.rule) { $rule.logged = "true" }
    $AdditionalHeaders = @{"If-Match"=$req.Headers.ETag}
    $response = Invoke-NsxWebRequest -URI "/api/4.0/firewall/globalroot-0/config/layer3sections/$($section.id)" -method put -extraheader $AdditionalHeaders -body $content.section.outerxml
    if ( -not $response.StatusCode -eq 200 ) {
        throw "Failed putting section $($section.name) ($($section.id)).  $($response.StatusCode) : $($response.StatusDescription)"
    }
    else {
        write-host "Enabled logging on all rules in Section $($section.name) ($($section.id))"
    }
}

Weiterführende Links

 

Leave a Reply