Firewall Fehlerdiagnose

Allgemein

Bei allen Szenarien kann es hilfreich sein, das Syslog (Applikations- und Kernelmeldungen) zu sichten.
I.d.R steht dort auch ein konkreter Hinweis zu dem entsprechenden Problem.
Bei IPSec muss das Log auf „Ausführlich“ gestellt werden.
Zudem muss das Log auf den UTMs vergrößert werden. Hierzu kann folgender CLI Befehl genutzt werden:

syslog backlog set type messages limit 500000

Firewall ist nicht erreichbar

Sollte es zu einer Unerreichbarkeit der Firewall kommen, können Sie per Konsolenverbindung (https://manage.terracloud.de/) auf der Firewall, ein Troubleshooting durchführen:

Hier können die Zugangsdaten wie auf der Weboberfläche verwendet werden.


Über den Befehl interface address get wird die Netzwerkkonfiguration angezeigt


Über den Befehl node get werden die Netzwerkobjekte(Nodes) ausgegeben


Hier kann der erste Abgleich stattfinden. Unter den Nodes muss die Adresse des internal-interface mit eth1 unter der Netzwerkkonfiguration, übereinstimmen.
Alternativ kann als Adresse der Wert „eth1“ eingetragen werden.

Insofern hier ein Unterschied, wie im folgenden Beispiel besteht, lässt sich dieser mit einem Befehl angleichen:



Mit folgendem Befehl wird die neue Adresse zur Verfügung gestellt und die alte auf „dynamic“ gesetzt, damit ggf. weitere Arbeiten vorgenommen werden können.
Interface address set id „5“ address „192.168.140.254/24“


Anschließend müssen noch zwei weitere Befehle vorgenommen werden:
system update interface

Durch diesen Befehl geht die neue IP online.

Zu guter Letzt noch system config save ausführen, um die Konfiguration zu speichern

OpenVPN S2S Probleme

Baut sich der Tunnel nicht auf, ist folgendes auf beiden Seiten zu prüfen:

• Zertifikate
• Cipher + Hash

Hier ist auch die Firmwareversion entscheidend.
Neue Versionen unterstützen unter Umständen keine alten Cipher mehr.
Daher sollten beide Seiten am besten auf demselben Firmwarestand sein.
Ansonsten kann man mit der Option “Erlaubte Cipher für automatische Aushandlung (NCP)“ alte Cipher wieder explizit für eine Verbindung aktivieren.

• IP + Port der Gegenstelle
• Kann der Client den OpenVPN Server erreichen?

Ggf. ist dies im Portfilter nicht erlaubt oder ein DESTNAT leitet den Traffic am Server vorbei.

Wenn der Tunnel steht, aber kein Traffic durchgeht, ist folgendes auf beiden Seiten zu prüfen:

• Routen
• Portfilter / Implizite Regeln
• Paketfilter-Log
• Über TCPDUMP nachvollziehen, dass auch wirklich kein Traffic über den Tunnel geht. (Muss über Support@terracloud.de angefragt werden)

Oft antworten auch Endgeräte trotz Traffic einfach nicht.

Wenn Traffic über den Tunnel läuft, aber es allgemeine Verbindungsprobleme gibt, ist folgendes zu prüfen:

• Internetverbindung zwischen beiden Endpunkten
• Zusätzlich gibt es ein paar Stellschrauben, um trotz schlechter Internetanbindung noch eine gute VPN-Qualität zu erzielen.

Hier muss man sich etwas durchtesten und schauen, was den gewünschten Effekt erzielt.
Dazu zählen:

1. MTU → Wert testweise auf 1400 oder niedriger reduzieren
2. Replay-Werte erhöhen – am besten direkt verdoppeln
3. Protokoll von UDP auf TCP umstellen

IPSec S2S Probleme

Baut sich der Tunnel nicht auf, ist folgendes auf beiden Seiten zu prüfen:

• Zertifikate
• Cipher + Hash – generell die IKE-Werte, PSK usw. aus Phase 1 und 2 vergleichen

Hier ist auch die Firmwareversion entscheidend.
Neue Versionen unterstützen unter Umständen keine alten Cipher mehr.
Daher sollte Client und Server im besten Fall auf demselben Firmwarestand sein.

• IP + Ids + Startverhalten in Phase 1 des Tunnels

Wenn der Tunnel steht, aber kein Traffic durchgeht, ist folgendes auf beiden Seiten zu prüfen

• Portfilter / Implizite Regeln

Besonders NAT macht bei IPSEC Probleme.
Dafür sollte in den „impliziten Regeln“ am besten immer „Kein NAT für IPSec Verbindungen“ aktiv sein.

• Paketfilter-Log
• Auch hier kann es sein, dass das Paket in den Tunnel geht aber das Endgerät nicht antwortet.
  • IPSec hat allerdings kein dediziertes Interface, auf dem man einen TCPDUMP ausführen könnte.

Ob ein Paket in den Tunnel geht, prüft man daher am besten so:

1. Auf einem Gerät, dass sich im lokalen Netz der UTM befindet, einen Ping zum Remote Netzwerk mit einer Paketgröße absetzen.
   1. Bei Windows : ping $Ziel-IP$ -l 1000
   2. Bei Linux: ping $Ziel-IP$ -s 1000
      
2. Nun setzt man einen TCPDUMP auf dem UTM Interface, über das der Tunnel aufgebaut ist ab. Hier müssten dann Pakete mit der entsprechenden Größe zu sehen sein.
3. Beispiel für TCPDUMP: tcpdump -i $Interface$ -nnp port 500 or port 4500 or esp and host $IP_der_Gegenstelle$

Wenn Traffic über den Tunnel läuft aber es allgemeine Verbindungsprobleme gibt, ist folgendes zu prüfen:

Ich würde grundsätzlich dazu raten, unsere aktuellen Einstellungsempfehlungen zu setzen.
Die Eckdaten dafür sind:

• IKEv2
• Startoption Route + flag GENERATE_TRAFFIC
• „ike_lifetime“ auf „0“ und „ike_rekeytime“ auf „2“ setzen

Wenn möglich eine DH Gruppe aus „ecp“

Beispiel für CLI Änderungen

Für Route + Generate Traffic:

1. Mit „ipsec get“ die id des Tunnels herausfinden, den man ändern möchte
2. Befehl absetzen
   1. ipsec set id $tunnel_id$ flags [ ROUTE DPD GENERATE_TRAFFIC MULTI_TRAFFIC_SELECTOR ]
3. Mit „system config save“ die config speichern
4. Am besten zur Sicherheit noch einmal den IPsec Dienst neu starten.

Für Lifetimes:

1. Mit „ipsec get“ die id des Tunnels herausfinden, den man ändern möchte
2. Befehle absetzen, hierbei ist zu beachten, dass „ike_lifetime“ größer sein muss als „ike_rekeytime“ sofern „ike_lifetime“ nicht „0“ ist.
   1. ipsec set id $tunnel_id$ „ike_lifetime“ 3
   2. ipsec set id $tunnel_id$ „ike_rekeytime“ 2
   3. ipsec set id $tunnel_id$ „ike_lifetime“ 0
3. Mit „system config save“ die config speichern
4. Am besten zur Sicherheit noch einmal den IPSec Dienst neu starten.