SAProuter as an example
We have recently pointed out the advantage of a reverse invoke configuration and explored this for the SAP Web Dispatcher component, see the following link here. In this blog we will now zoom in on the SAProuter component and show this in a concise test setup.
As mentioned earlier, in our experience the reverse invoke option is not often used and quite unknown to SAP consultants. This goes for the SAP Web Dispatcher and perhaps even more so for the SAProuter component. Which is a pity, because it is an interesting option to explore for enhanced security of a setup where more than 1 component is involved.
Test setup
Note that we will focus on the reverse invoke setup of the SAProuter component and will not go into other security details, although the below setup has also been tested in combination with SNC. For this SNC configuration, see the following page for reference. See our previous blog where we have written extensively about security and the SAProuter.
Our test setup resembles the setup example from SAP Help, see link further below and following picture:
The setup is a DMZ like scenario but can be any setup with 2 SAProuter components and in-between network separation. The SAProuter 1 and 2 components are technically installed within docker containers which have the following inbound characteristics:
- SAProuter1: only accepting incoming TCP connections from port 4001 and 5001.
- SAProuter2: accepting NO incoming TCP connections.
Both SAProuters run with a basic SNC configuration and following parameters for reverse invoke:
| SAPROUTER1 | SAPROUTER2 |
| Start command: saprouter -K p:CN=SAPROUTER1 -S 4001 -V 2 -i cf1 & | Start command: saprouter -K p:CN=SAPROUTER2 -V 2 -i cf2 & |
| saprouttab: # Allow outbound connections to SAProuter host2 with use of SNC KT “p:CN=SAPROUTER2” 172.17.0.3 5002 P * 172.17.0.3 5002 | saprouttab: # accept incoming connections from SAProuter1 # with destination sapdp00 and 4001 on any host KP “p:CN=SAPROUTER1” * sapdp01 KP “p:CN=SAPROUTER1” * 4001 |
| Reverse invoke configuration parameters: client = true client_service= 5001 | Reverse invoke configuration parameters: server = true client_hostname = 172.17.0.2 client_service = 5001 reg_service = 5002 |
Further, there is an SAP ABAP backend system running in the local network, with an active dispatcher on service sapdp01 (port 3201). This is the connection that is used for an SAP GUI connection for example.
Now comes the testing of connectivity! This is done from the SAProuter1 container.
Test 1: direct connections
Result: only connection to SAProuter1 is open on port 4001. Performed with basic telnet <IP> <port> commands.
Test 2: niping test to SAProuter2 host directly
Result: failed connection because there is no open port (as also shown by telnet test).
Test 3: niping test via SAProuter1 host
Result: successful connection.
Conclusion
The above tests clearly demonstrate the effect and advantage of a reverse invoke configuration. There are no ports opened to any of the components in the local network. Still, using reverse invoke, the local components are reachable but only via the configured SAProuter component in the DMZ zone.
The setup of reverse invoke can be more complex and should – naturally – always be tested thoroughly for a given scenario. But a successful implementation can certainly contribute to a more secure setup!
See the following SAP Help page as starting point for configuration:
For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn!
Try out Protect4S for 1 month for free or request a demo!
