IBM Support

QRadar on Cloud: Troubleshooting Data Gateway appliance connectivity

How To


Summary

When a Data Gateway loses connection to the QRadar on Cloud Console, the Data Gateway reports as 'Unknown'or 'Offline' to users. This technical note can assist administrators with troubleshooting connectivity and OpenVPN issues.

Objective

The objective of this technical note is to troubleshoot OpenVPN tunnels on the Data Gateway appliance that report Unknown of Offline.

Environment

QRadar on Cloud Data Gateway appliances or virtual machines.

Steps

The first troubleshooting step that can be done b support is often to restart the OpenVPN service. 
  1. Use SSH to log in to the Data Gateway appliance.
  2. Type the following command: 
    systemctl restart openvpn@client.service
  3. Confirm the service status: 
    systemctl status openvpn@client.service
    If the service is started, we can confirm the tunnel is started. The tunnel is the VPN we build that is used to communicate between the console and the data gateway.
  4. To check for the tunnel status, type: 
    ifconfig tun0
    The output must display information for the tun0 interface. 
    tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 32000
        inet X.X.X.X  netmask 255.255.255.0  destination X.X.X.X  
        inet6 fe80::aaaa:bbbb:1111:cccc  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets XXXXXXXX  bytes XXXXXXX (1 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets XXXXXXXX  bytes XXXXXXX (1 TiB)
        TX errors 0  dropped 104597 overruns 0  carrier 0  collisions 0
  5. When the tunnel fails to start, the following error is displayed: 
    Tun0: error fetching interface information: Device not found
Troubleshooting a failed connection
If the tunnel is failing to start, then the Console is unable to connect and the Data Gateway is listed as 'Unknown' or 'Offline' in the user interface. When you experience tunnels that fail to start, review the latest logs in /var/log/openvpn.log.
For example, when a VPN tunnel is unable to connect, the following error is likely to display in the logs:
{Date} us=384745 [SIEM VPN Server] Inactivity timeout (--ping-restart), restarting
{Date} us=422380 TCP/UDP: Closing socket
{Date} us=437454 SIGUSR1[soft,ping-restart] received, process restarting
{Date} us=438359 Restart pause, 5 second(s)
{Date} us=438498 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
{Date} us=438583 Re-using SSL/TLS context
{Date} us=438627 LZO compression initializing
{Date} us=577909 Control Channel MTU parms [ L:32124 D:1210 EF:40 EB:0 ET:0 EL:3 ]
{Date} us=640781 Data Channel MTU parms [ L:32124 D:32124 EF:124 EB:5490 ET:0 EL:3 ]
{Date} us=640947 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 32052,tun-mtu 32000,proto TCPv4_CLIENT,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client'
{Date} us=640965 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 32052,tun-mtu 32000,proto TCPv4_SERVER,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-server'
{Date} us=641033 TCP/UDP: Preserving recently used remote address: [AF_INET] X.X.X.X:443
{Date} us=641077 Socket Buffers: R=[87380->87380] S=[16384->16384]
{Date} us=641096 Attempting to establish TCP connection with [AF_INET]X.X.X.X:443 [nonblock]
{Date} us=641270 TCP connection established with [AF_INET]x.x.x.x:443
{Date} us=641322 TCP_CLIENT link local: (not bound)
{Date} us=641332 TCP_CLIENT link remote: [AF_INET]X.X.X.X:443
{Date} us=122416 Connection reset, restarting [-1]
Review for the following lines in the log:
  • Attempting to establish TCP connection with [AF_INET]X.X.X.X:443
  • Connection reset, restarting
These errors in the logs prove that the Data Gateway is not able to connect to the Console to establish a tunnel. When the VPN tunnel is unable to connect the first thing to check is to make sure the public IP is correct.
How to confirm your IP address for the Data Gateway
  1. Use SSH to log in to the Data Gateway appliance.
  2. To confirm the IP address, type: 
    curl ifconfig.me
  3. One of the two outcomes can occur:
    • The IP address of the Data Gateway is displayed. Confirm the public IP address is correct and in the allowlist in the Self-serve app. 
    • No results are displayed or a connection error. You must have the public IP for the Data Gateway appliance to ensure the allowlist is correct for your Data Gateway. You can get the public IP from your local network team.
  4. Add the public IP to the allowlist. For more information, see How to add an IP address to the allowlist.
  5. After you add the IP address to the allowlist, type the following command to restart hostcontext: 
    systemctl restart hostcontext

    Results
    Wait for hostcontext to restart. Log in to the QRadar on Cloud Console to confirm the status of the Data Gateway appliance. If you continue to network connection issues with your Data Gateway appliance, confirm you are using a transparent proxy or you did not assign a 192.168.x.x IP address. For a full list of requirements, see the QRadar on Cloud Support FAQ. If you require further assistance, open a case with QRadar on Cloud Support.

Additional Information

Related Information

Allowlisting an IP address

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSKMKU","label":"IBM QRadar on Cloud"},"ARM Category":[{"code":"a8m0z000000cwsyAAA","label":"Admin Tasks"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Product Synonym

QROC; QRADAR

Document Information

Modified date:
31 March 2022

UID

ibm16563001

Page Feedback