Analysis of the SAP HANA Internal Communication Interface

SAP HANA is a very fast growing product in many SAP environments, that has moved away from just an in-memory database to a complete application plus database system. In today’s blogpost we’ll talk about the SAP HANA internal communication interface, discuss its use in different scenarios, the configuration parameters involved and the different options that SAP HANA administrators should consider to secure their systems. We’ll also perform an analysis of the default configuration introduced in SPS 12 reviewing different parameters and how they impact overall security.


For scalability and availability reasons, SAP HANA can be deployed in one or multiple hosts. As you may know an SAP HANA system is comprised by several processes working together as the following image shows:

Image 1: Only relevant processes for this blogpost are shown

These processes can run in the same host (single-host deployment) or across multiple hosts (multi-host deployment). In both cases these processes need to communicate to each other, and this is done through an interface called “SAP HANA internal communication”.

Single-Host Scenario

In single host scenarios all processes are running in the same host, and they use the loopback interface to communicate with each other.

In the image above we can see each process with the TCP port that’s used for the internal communication interface.

In this scenario the default configuration for SPS > 06 is secure as all the processes are bound only to the loopback interface and are not reachable from the external network. We’ll discuss later how this default configuration works and how it was implemented by SAP.

Multi-Host Scenario

In the case that the SAP HANA system is comprised of more than one host, each host will have a subset of the processes needed to run the system. The following image show this:

Here each process communicates with other processes in the same host but also with processes in other hosts as well.

The protocol used by these interfaces is internally called TrexNet as the following log lines show:

It’s a proprietary protocol developed by SAP, with the following characteristics: it’s undocumented, doesn’t have any authentication mechanism and it seems to be inherited from another SAP product called Trex.

Listen Interface Modes

SAP HANA internal communication interfaces can be configured in three different ways: local, Internal and Global.

In local mode the internal communication interfaces are bound only to localhost, this means that they are not reachable from the network. This is the default configuration for single host deployments as there isn’t any requirement for this type of communications.

Choosing Internal option the internal communication interfaces are bound to an specific network which should be isolated from the external network and only be used to allow the communication of the different SAP HANA hosts and processes. This is the most secure configuration but also the most difficult one to implement due to the network requirements.

Finally, the last option, called “global”, binds internal communication interfaces to the same interface that’s used for general purpose usage which means that any attacker that is able to reach the SAP HANA system could also reach the internal interfaces as well. To avoid this is strongly recommended to enable encryption if this configuration is chosen. Later we’ll discuss how to do it.

How SAP hana is configured regarding the internal communication interfaces is governed by the value of the “[communication] listeninterface” parameter. As explained before, it can take three different values, “.local”, “.internal” and “.global”. You can check the current value executing the following SQL sentence:

SELECT * FROM "PUBLIC" . "M_INIFILE_CONTENTS" WHERE SECTION = 'communication' AND KEY = 'listeninterface';

Encryption and Authentication

Additionally it is possible to enable encryption for the internal communication interfaces. Depending on the SPS version this can be achieved in different ways.

For SAP HANA SPS < 10 the process of enabling encryption had to be performed manually, in this blogpost we’ll focus in SAP HANA SPS => 10.

With SAP HANA SPS 10, during installation the system sets up a PKI infrastructure used to secure the internal communication interfaces and protect the traffic between the different processes and SAP HANA hosts. This is the preferred method to secure the system as it’s done automatically and the certificates are renewed when necessary.

An important point to mention is what is explained in the SAP Security note 2175672.  Encryption is turned off by default. It can be enabled changing the parameter “[communication] ssl” to “systempki”.

Through the use of the PKI infrastructure each host part of the SAP HANA system has a pair of certificates that are used to mutually authenticate each endpoint before starting any communication. The following image illustrates all the scenarios that are protected using this configuration:


With the new default configuration internal communications for different scenarios are authenticated, for example:

  • Inter-process communications in single-host deployments
  • Host-to-Host communications in multi-host deployments
  • Communications between tenants DBs and in multi-tenant deployments


Knowing what interfaces are exposed and what risks they could represent is vital to keep your SAP HANA systems protected. With this post, we learned about the internal communication interfaces and how to properly assess their state. As always, keeping systems up the date is highly important, for example in SAP HANA latest SPS the default configuration is secure, helping customers to achieve a good security level without much effort. In further blog posts we’ll continue analyzing different aspects of SAP HANA security. Stay tuned.


Leave a comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.