Jump to:navigation, search
Wiki






























De.png
En.png
Fr.png






Securepoint UTM error analysis
Last adaption: 02.2024
New:
  • General layout adaption
notempty
This article refers to a Resellerpreview

11.7


Introduction

In the event of an error, the following steps are necessary so that a correct error analysis can be carried out by our support team.


Notes

To ensure proper operation, the UTM system must not be de-energized without a proper shutdown, otherwise damage or impairments may occur. The UTM can be shut down properly as follows.

  • Using the web interface (Configuration -> Shutdown)
  • Use the power button on the device
  • Via SPCLI (system poweroff)
  • Via SSH (poweroff)
  • A stands for the Enter key
  • It is not possible to create a "root" user on Terra-Cloud firewalls, please contact support for this.
  • The command spcli calls up the Securepoint CLI of the UTM via the root user. This command does not have to be used if it is already open. Exit the Securepoint CLI with the command: exit. The command can also be placed directly in front of a command: spcli interface address get.


  • Preparation

    A user with root authorizations is required. It is strongly recommended to use a Support user , as this always has an expiration date and a permanent root user represents a security risk.


    Increasing the syslog entries

    The following commands can be used to increase the maximum number of syslog entries. This is useful for error analysis, as it allows a longer period of time to be analyzed.
    spcli syslog backlog set type messages limit 100000
    spcli system config save


    Release of the Securepoint IP

    For an external error analysis, the IP must be released by Securepoint for the Admin Interface:
    spcli manager new hostlist securepoint.de
    Then disconnect the SSH connection.

    notempty
    It must be ensured that ports 11115 and 22 are forwarded to the UTM by a router in front of it.


    Error analysis

    In the event of an error, please test and document the following.

    • Ping test to the IP of the UTM (eth1)
    • Traceroute to the IP of the UTM (eth1)
    • Login UTM via SSH
    • Login UTM via Webbrowser (Please test with at least two browsers)
    • Login UTM via monitor and keyboard on the UTM

    Wenn der Login via SSH oder Monitor und Tastatur klappen sollte, bitte Folgendes durchführen.


    Checking the interfaces

    The command ip a can be used to check the interfaces. The output of this should look similar (IP addresses, interfaces and MAC addresses may differ) to the following. Special attention should be paid to whether the ports display NO-CARRIER, DOWN or UP.

    root@firewall:~# ip a 5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff inet 10.10.10.2/24 scope global eth0 valid_lft forever preferred_lft forever 7: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 21:22:23:24:24:26 brd ff:ff:ff:ff:ff:ff inet 192.168.175.1/24 scope global eth1 valid_lft forever preferred_lft forever 8: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 31:32:33:34:35:36 brd ff:ff:ff:ff:ff:ff


    Checking the interface addresses

    The interface addresses can be checked with the following commands:
    spcli interface address get
    The output should look similar (IP addresses and interfaces may differ) to the following. Special care should be taken to ensure that the interfaces are ONLINE.
    firewall.foo.local> interface address get id|flags |device|address –+——-+——+——- 16|ONLINE |eth0 |10.10.10.2/24 5 |ONLINE |eth1 |192.168.175.1/24


    PING test to the Internet

    If the Securepoint CLI (spcli) is open, it must now be closed with exit .

    You can then use the command tcpdump -i A1 -nnp proto 1 to ping the IP "9.9.9.9" from a device that is located behind eth1 and has entered the UTM as a gateway.

    The following information should be displayed here, although the IPs may differ. Please check here whether the ICMP echo request and the ICMP echo reply arrive at the interface.
    root@firewall:~# tcpdump -i eth1 -nnp proto 1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 08:32:43.051837 IP 192.168.175.101 > 9.9.9.9: ICMP echo request, id 36620, seq 9, length 64 08:32:43.070499 IP 9.9.9.9 > 192.168.175.101: ICMP echo reply, id 36620, seq 9, length 64 08:32:44.051886 IP 192.168.175.101 > 9.9.9.9: ICMP echo request, id 36620, seq 10, length 64 08:32:44.070340 IP 9.9.9.9 > 192.168.175.101: ICMP echo reply, id 36620, seq 10, length 64



    Dokumentation

    The results must be documented, even if they fail. It is also important that messages that may be displayed when logging in to the UTM are also documented.

    Please then create a support ticket via the reseller portal and have the log ready.