IBM Support

QRadar: Understanding NAT Groups and implementation scenarios

Question & Answer


Question

How do NAT Groups work in QRadar®?

Answer

To understand QRadar® NAT Groups the following concepts must be explained:
Public IP:
The IP that will be used to reach the appliance's private IP. It can be any IP configured in the NAT configuration and not necessarily a Public IP as per the RFC 1918.
NAT Group:
The QRadar® NAT Groups has the following features:
  1. QRadar® uses the default id (NAT Id 0) unless otherwise specified by the administrator.
  2. Each NAT Group configured is a different "location" with a different ID.
  3. Newly created NAT Groups increments by 1 the ID. For example, the first NAT Group configured by the administrator will be NAT Id 1, the next NAT Id 2, and so on.
  4. Appliances in the same NAT Group connect each other with their respective Private IP.
  5. Appliances in different NAT Groups connect each other using the Public IP addresses.
  6. QRadar® configures the IP Tables service to include connections going and coming from the respective Public IP addresses.
Deployment Overview
The following deployment (Console, Event Processor, and Event Collector) example will explain the usage of QRadar® NAT Groups in different scenarios:
Note: The following IP addresses are only meant to illustrate the example scenarios. All of them are considered "Private IP addresses" by the RFC 1918.
Console Private IP = 10.11.12.254
Console Public IP = 172.16.12.100
Console NAT Group (Location) = Main Office

Event Processor (EP) Private IP = 192.168.12.101
Event Processor (EP )Public IP = 172.16.12.101
Event Processor (EP) NAT Group (Location) = Branch1

Event Collector (EC) Private IP = 172.16.12.102
Event Collector (EC) Public IP = <None>
Event Collector (EC) NAT Group (Location) = Branch1
Scenario #1 - Appliances in the same NAT Group or "location".
This is the default implementation in QRadar®.
Connections Breakdown:
The Console and the Event Processor connect and expect the connection to each other through their Private IP addresses.
The following screenshot illustrates this scenario:
Figure01

 
Scenario #2 - One of the appliances in a different NAT Group or "location".
In this scenario, the Event Processor is in a different NAT Group.
Connections Breakdown:
The Console connects to the Event Processor through its Public IP and expects the connection from the Event Processor's Public IP.
The following screenshot illustrates this scenario:
Figure02
The following technote provides a step-by-step guide to configure this scenario: QRadar: How to add a managed host reachable through a different IP

 
Scenario #3 - Both appliances in different NAT Groups or "location".
In this scenario, the Console and Event Processor are in different NAT Groups.
Connections Breakdown:
  1. The Console connects to the Event Processor through its Public IP and expects the connection from the Event Processor's Public IP.
  2. The Event Processor connects to the Console through its Public IP and expects the connection from the Console's Public IP.
The following screenshot illustrates this scenario:
Figure03
The following technote provides a step-by-step guide to configure this scenario: QRadar: Configure the Console to be reachable through a different IP.
Scenario #4 - Console in one NAT Group. Event Collector and Event Processor in another.
This scenario is similar to scenario #3. The only difference is that the Event Collector is in the same NAT Group as the Event Processor.
Connections Breakdown:
  1. The Console connects to the Event Processor through its Public IP and expects the connection from the Event Processor's Public IP.
  2. The Event Processor and Event Collector connect to the Console through its Public IP and expect the connection from the Console's Public IP.
  3. The Console connects to the Event Collector through its Private IP and expects the connection from the Event Collector's Private IP.
  4. The Event Processor and Event Collector connect both through their respective Private IP addresses as they are both within the same NAT Group.
The following screenshot illustrates this scenario:
Figure04
The following technote provides step-by-step guidance to configure this scenario: QRadar: How to add a managed host to an existing NAT Group for private IP communication

[{"Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwtNAAQ","label":"Deployment"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"All Version(s)"}]

Document Information

Modified date:
07 May 2021

UID

ibm16416419