Firewall Troubleshooting

General

In all scenarios it can be helpful to look at the syslog (application and kernel messages).
There is usually also a specific note about the relevant problem.
For IPSec, the log must be set to “Verbatic”.
In addition, the log on the UTMs must be enlarged. The following CLI command can be used for this:

syslog backlog set type messages limit 500000

Firewall cannot be reached

If the firewall becomes inaccessible, you can troubleshoot the firewall using the console connection (https://manage.terracloud.de/):

Here the access data can be used like on the web interface.


The network configuration is displayed using the command interface address get


The network objects (nodes) are output using the command node get


The first comparison can take place here. Among the nodes, the address of the internal interface must match eth1 under the network configuration.
Alternatively, the value “eth1” can be entered as the address.

If there is a difference here, as in the following example, it can be adjusted with a command:



The following command makes the new address available and sets the old one to “dynamic” so that further work can be carried out if necessary.
Interface address set id “5” address “192.168.140.254/24”


Then two more commands must be made:
system update interface

With this command the new IP goes online.

Last but not least, run system config save to save the configuration

OpenVPN S2S problems

If the tunnel does not build, check the following on both sides:

• Certificates
• Cipher + Hash

The firmware version is also crucial here.
New versions may no longer support old ciphers.
Therefore, both sides should ideally be on the same firmware version.
Otherwise, you can explicitly reactivate old ciphers for a connection using the “Allowed ciphers for automatic negotiation (NCP)” option.

• IP + port of the remote station
• Can the client reach the OpenVPN server?

This may not be allowed in the port filter or a DESTNAT directs the traffic past the server.

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:

Grundsätzlich sollten die aktuellen Einstellungsempfehlungen gesetzt werden.
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.