Single Access Point Concept 
SAP NetWeaver Enterprise Search consists of several components that run on different servers and different stacks. Each of these components communicates with the other components through a closely-linked network of RFC, HTTP, and Web Service connections. It is important to have only one single and controlled point of access to SAP NetWeaver Enterprise Search for the following reasons:
To hide the internal complexity from the customer network
To allow a maximum of automation, pre-installation, and pre-configuration
To ensure maximum security while the system is running, in particular the security of the data extracted from the source systems
In the case of SAP NetWeaver Enterprise Search, the master blade is used as the central access point. This groups together services required to run AS ABAP and AS Java, such as SAP Message Server, SAP Gateway, SAP Web Dispatcher, and SAProuter, as part of the SCS executed on the master blade and is also used to configure IP redirecting and filtering rules. Furthermore, many parts of the installation and configuration of the operating system can be controlled through the master blade.
It is important to understand that all communication from outside SAP NetWeaver Enterprise Search must occur through the master blade. There is no direct connection between the customer network and the internal network of the system. All hosts/blades within the appliance are configured to use a local (private) subnet and only know each other within this subnet. On the other hand, the system appears with only one IP and host name within the customer network. (If the customer distinguishes between user LAN and server LAN, the Enterprise Search appliance has one IP and host name in each of these networks).
SAP Web Dispatcher – HTTPS/SSO
The SAP Web dispatcher is a reverse proxy that handles all incoming HTTP(S) traffic. It is closely linked to the application servers, responsible for balancing the load between the central and dialog instances, and ensures a secure SSL (HTTPS) connection between the search clients and the SAP NetWeaver Enterprise Search system.
From a technical perspective, it is important to understand that the SSL tunnel is created between the search client and the SAP Web dispatcher and not between the search client and the ABAP application server. Otherwise load balancing would not be possible. However, the route between the Web dispatcher and the application server goes through a separate (private) network segment, therefore, this does not increase the security risk. Furthermore, it is important to keep in mind that all absolute URLs generated by the application and the SSL certificate itself must be configured to use the external host name under which the SAP Web dispatcher is known in the customer network.
SAProuter – RFC/JCo
While the SAP Web dispatcher serves only for HTTP(S) connections, the SAProuter opens a secure and controlled channel for other protocols used by SAP applications. These include RFC, SAPGUI, and so on. The list of allowed hosts that can be accessed and the protocols that can be used is managed in the saprouttab file on the blade for the SCS instance, that is, the master blade.
As soon as this has been completed, all communication between a client or another SAP system in the customer network and a server within the SAP NetWeaver Enterprise Search system must use the SAProuter string. These tokens replace the direct addressing of the host names, for example in SM59. If you normally connect to <abap_external_hostname> via SAP Logon or SM59 directly, you now have to enter the SAProuter string as follows: /H/<master_blade_external_hostname>/H/<abap_internal_hostname>
The standard IP forwarding through NAT must be configured in order to handle other protocols, such as LDAP, that neither of these two technologies (SAProuter and SAP Web Dispatcher) support. It can be used for direct outbound connections. However, we strongly recommend using the SAProuter for all other outbound RFC connections to SAP systems, for example, to an ERP 2005 system in the customer landscape.
Note
To investigate Enterprise Search problems, SAP support might require a connection to hosts in the local (private) subnet. This connection can either be established through a remote desktop connection to a separate Windows/Linux client according to SAP Notes 1087671 and 789026 or through a direct CSS connection (without requiring an additional Windows/Linux client) as described in SAP Note 1058533. In this case, the saprouttab file must be edited as described and SAProuter must be restarted
IP Forwarding/NAT
As already mentioned, IP forwarding and network access translation (NAT) are needed to access other required resources within the customer network. These include the LDAP server and file systems that are to be indexed by SAP NetWeaver Enterprise Search. While this works for all outgoing TCP/IP-based communication, only the incoming NC host is accessible by it external host name for external clients. Administrative connections to other hosts in the private network of the SAP NetWeaver Enterprise Search system can be created only through the console for the master blade or the port redirect functions of an SSH client. Example:
Accessing the DBMS via its DB Management Tool
Running the TREX Administration Tool (Python)
Performing administration tasks at the operating system level
We strongly advise against redirecting the master blade ports permanently to internal servers using IP port forwarding. We expect that everyone who really needs to connect to the internal servers of the Enterprise Search appliance has a local X-Server (such as Exceed, ReflectionX, or Cygwin) and an SSH client installed on their local system. (This includes customer administrators as well as the hardware partners who are performing the installation.)
After creating an SSH connection to the master blade using activated X11 and port forwarding, you can perform the following activities:
Open another SSH connection in this window: Open a second connection from your local client to localhost:<Port>, which is then forwarded through the secure SSH tunnel directly to the <XYZ> server.
Open the database management tool and establish a connection to localhost:<Port> that is then redirected to the DBMS running on the <XYZ> server.
Note
All communication through SSH (secure shell) is always secure and encrypted; it can be further restricted by configuring the SSH daemon on the master blade, for example, to allow only public-key-pair authentication instead of user name and password.