Technical Articles
Connectivity experiments with an SAP server and client VM – Linux router, SquidMan, dnsmasq, and SSH tunnels
Intro
This blog considers a scenario, where you would want to access an SAP instance from a client machine, but there is no direct route between client and server: we then show various ways (“experiments”) to set up indirect routes, so that a user can access SAP.
So this blog will mainly be about various networking experiments, and only secondarily about SAP technology – feel free to stop reading if computer networking isn’t your cup of tea.
The basic scenario is this: we will have a SAPGUI client installed (as well as any browser, such as Firefox or Chrome, for consuming Fiori) on an openSUSE Leap VM on VMware Fusion; this VM will be using bridged networking (so that the client VM is part of the Home Wi-fi network, but is not part of the VMware Fusion NAT network); then in another VM we have an SAP instance server (SAP NetWeaver Dev Edition, 7.52 SP04) on a variant of Ubuntu (Xubuntu desktop for Ubuntu 20.04 LTS), running on VMware Fusion’s NAT network.
The idea is that the host laptop can contact the SAP server, but the openSUSE client needs either the host laptop or a third VM, to act as a jump-server enabling the client VM to get to the SAP server VM.
[You will note that there are several “MacBook specific” aspects to the descriptions, since currently my only home laptop with enough memory to run 3 VMs concurrently, is an old but functioning MacBook Pro. I would guess that similar experiments can be run using other machines e.g. Linux or Windows, if you are using such a machine then good luck with finding similar solutions. Also please note that there is no Helpdesk backing up this blog, and I assume a reasonable level of competence in creating and managing VMs (virtual machines); if you want to try any of these experiments, then good luck with that, just remember I am highly unlikely to be able to help you: instead, you would need to bring your own debugging skills and iterative stamina!]
So, we have the SAP on Ubuntu server on the VMware subnet 192.168.108.0/24, with address 192.168.108.149:
For some reason Ubuntu doesn’t come with an SSH server as part of the standard distro, so we can add that now:
$ sudo apt install openssh-server
This command should install, start and enable the SSH server, but you can always check it is up and running (“Active”) as follows:
$ sudo systemctl status ssh
Then you need to install a basic SAP system: generally the free to install and use SAP NetWeaver Developer Edition (popularly also known as “mini-SAP”) is the right choice for doing experiments and proofs of concept at a Basis level. To install on an Ubuntu VM, I have a blog or two about that, here’s the concise guide:
Next, we briefly describe the host of our VMs, which is a MacBook Pro laptop on the Home Wi-fi subnet 192.168.8.0/24 with address e.g. 192.168.8.109 – for MacBook, in Network Preferences for the Wi-Fi connection under Advanced → TCP/IP, I set this address manually (i.e. as a static IPv4 address) to stop it from moving around via DHCP each time it joins the home router’s network:
In the next screenshot, we see that the laptop machine is also a node on the VMware Fusion NAT-network “vmnet8”, in fact as the host machine running the hypervisor, it happens to be assigned the node 192.168.108.1, such is the way vmnet8 works – this also means that the laptop has a route to the guest VMs on the vmnet8-network i.e. on the NAT-network.
The third machine in our scenario is the SAPGUI client on an openSUSE Leap VM, this one is using bridged networking, in our context that means it is also an IPv4 node on the same Home Wi-fi subnet 192.168.8.0/24 which the laptop host machine is on: let’s say the VM has IP address 192.168.8.110 (though this might also change around a bit in the following demos, this hardly matters at all as this VM is in the role of SAPGUI client, so no users or servers have any good reason to initiate a connection to this VM – though later in this blog you will need to find out the client VM’s IP, in case you want to set up a Reverse SSH tunnel as part of Experiment 3).
One quirk of using Wi-FI Bridged Networking in VMware Fusion, is that sometimes (maybe once after install of a new VMware version) when setting a Network Adapter to us this kind of networking “mode”, you might need to click on the “System Preferences” and then any pop-up-to-confirm buttons, to basically inform the host laptop that you want to use the host’s Wi-Fi connection. So do that at least as a one-time activity when specifying Wi-Fi Bridged Networking.
When you spin up a new openSUSE Leap VM, it doesn’t come with SAPGUI client installed. So, we show one way to get this client installed. Now if you have an S-user with relevant authorisations, you can download the relevant jar file for SAPGUI for Java client from SAP, and if you have the more recent versions (from about 2020 onwards, e.g. release 7.50 revision 9), then the installation comes with own SAP JRE, so it’s an easier install compared with the older versions. We don’t assume that you have an S-user though, and instead show how to do install by using the jar file provided when you downloaded and extracted all the files needed for installing SAP NetWeaver Dev Edition earlier (i.e. when you set up the SAP server).
In the demo VM’s Fusion settings, enable the shared folder that contains all the NetWeaver Dev Edition subdirectories and files:
Now from openSUSE VM we should be able to see the shared folder, but for some reason as of June 2020 VMware Fusion doesn’t quite manage this task with either Ubuntu nor openSUSE, so we fix that as follows:
On VMware Fusion and VMware Workstation Player the following works for me, in the openSUSE guest:
$ sudo nano /etc/fstab
Add a new line at the end of the table:
.host:/ /mnt fuse.vmhgfs-fuse allow_other 0 0
Save (Ctrl+O [as in the letter ‘O’], <Enter>) and close (Ctrl+X). Now to “pick up” this new fstab line, we just need to run:
$ sudo mount -a
So now for example you can open the Files app, click “Other locations”, select “Computer”, then go into the /mnt directory, where the shared folder netweaver752 is now visible, then you can move into the subdirectories:
From subdirectory /client/JavaGUI/, copy over to your home directory the zip file that contains a load of numbers, e.g. “50144807_7.ZIP”, then extract it, this gives you a new folder called something like “BD_NW_7.0_Presentation_7.50_Comp._2_ “, at least that’s what mine was called.
Then under that folder, via path /PRES2/GUI/JAVA you can find the Linux jar (as well as macOS and Windows jars). So you can copy the jar e.g. to your home directory (if you like), or you can probably cd into the shared directory and install from there.
Before starting the install, check java version (OpenJDK was installed in our distro when we created the openSUSE VM as a default JVM):
$ java -version
That should be fine. (Note that from SAPGUI for Java 7.50 revision 9 at least, you don’t even need to check java version, as the installation includes a JVM from SAP). Anyway now we can move into the directory where our installation jar is, and install it using the command:
$ java -jar PlatinGUI750Linux_1.JAR install
Assuming the install finishes successfully: in Activities, search for “SAPGUI”, right-click and Add to Favourites.
Now as of June 2020, the “free SAPGUI client” from the SAP NetWeaver Dev Edition files is version 7.50 revision 1, and unfortunately that doesn’t quite work right out-of-the-box with openJDK 11, as we see when trying to open the SAPGUI client app:
With the more recent version (7.50 revision 9) of the SAPGUI for Java client (that I got using my S-user), this issue doesn’t occur, because that client contains its own SAP JVM (so you don’t even need to have a default JVM preinstalled on your machine).
But how do we solve the issue for our older free version without own SAP JVM? I tried various workarounds to get past this error, as it was ruining my nice demo of how to install the client… installed OpenJDK 13 and switched to that java version – same kind of error occurred… installed Oracle JDK 14 and switched to that… same error for that JVM too… then I somehow, either luck or skill or maybe both, somehow guessed the solution… First, switched back to using OpenJDK 11 (command for switching between JVMs is “sudo update-alternatives –config java“ [two dashes before ‘config’ string], and then you pick which JVM is to be the active one from the list of installed JVMs), and then cd into the directory /usr/lib64/jvm/java-11-openjdk-11/lib/ – we can list the contents, of course there is no file called “javafx.properties”… well, let’s try creating an empty file called “javafx.properties”, and see what happens:
$ sudo touch javafx.properties
Now we can try opening our SAPGUI client, and hey hackaroundy it all works (our demo VM does have a direct route to an SAP instance, so we can check that the logon screen is rendered correctly):
Ok, so that was a wee detour about installing SAPGUI using a demo VM. Now let’s return to our proper openSUSE VM in the main scenario that we are using for the upcoming experiments, it is actually running a more recent SAPGUI client (7.50 revision 9), which during installation provides an SAP own JVM, so there was no error about the javafx.properties file (which as it happens only contains basic information about the JavaFX version in use by the JVM):
So in our main scenario with a host machine, an SAP server VM, and a SAPGUI client VM.. what we expect, is that the laptop as the host machine, can ssh into the SAP server VM, since both machines are on the NAT-network:
$ ssh dylan@192.168.108.149
So that’s good.
Also, we hope to be able to ssh from the SAP server VM to the host machine… this works out fine too, as it should, since VM and laptop are both nodes on the vmnet8-network:
$ ssh dylan@192.168.108.1
Next, we should establish that our SAPGUI VM, is able to ssh into the host machine; those two machines are on the Home Wi-fi subnet, so that has to work, or at least it will work after we go to System Preferences → Sharing settings of laptop where we set Remote Login checkbox to ON:
$ ssh dylan@192.168.8.109
That’s fine. Next, we want to just prove to ourselves that there is no route from the SAPGUI VM to the SAP server VM (since if there is no direct route, that is the main reason we would want to use our laptop or a third VM as jump-server). So let’s just confirm that initially no route exists… First of all exit from the ssh session previously established with laptop i.e. we make sure we are in this case on “linux-8joy”, the SAPGUI client VM, and then we can try to ssh into the SAP server VM:
$ ssh dylan@192.168.108.149
This is just what we expect: there is indeed no route to the SAP server VM.
Now the scene is set for us to set up various ways of allowing the client VM to connect to SAP server.. hey ho, let’s go…
Experiment 1: configure a third VM as a router and add the needed routes
We can set up a third VM, to act as a router, which enables connections between the SAP server and SAP client VMs. To do this, the router VM will have two network interfaces (NICs): one on the NAT subnet 192.168.108.0/24, and the other on the Home Wi-fi subnet 192.168.8.0/24.
We need any decent Linux distro, so let’s install a Debian 10 VM with e.g. Xfce GUI, with 2 network interfaces: one NIC is called in the VMware Fusion settings “Network Adapter” and will be on the NAT subnet; the other NIC is called “Network Adapter 2” and will be on Home Wi-fi subnet:
Now the Debian VM only brings one of those NICs into use initially (seems to default to whichever one was selected for the installation workflow), so to have both NICs up and running, go into the GUI settings (easiest way), and add the new network connection.
First check which NIC lacks an IPv4 address:
$ ip a
In this case we see it is ens33. Then from the Xfce menu: Applications → Settings → Advanced Network Configuration → click the “+” button to Add New Connection… then select ens33 when adding the new network connection, from the “Device” dropdown-listbox under “Ethernet” tab:
After you have saved your new connection, you might still need to activate or “Connect” the newly available NIC from e.g. the GUI menu, so that both interfaces are up and running. Then you can see using “ip a” command again, that both NICs now have an IPv4 address, in our case ens33 gets new address from NAT DHCP 192.168.108.150 and this address will be “sticky” as VMware Fusion tries to reassign the same IP to the VM’s NIC after reboot), while ens34 still has a Home Wi-fi subnet address 192.168.8.111 (this could of course easily change, it would be better to set this as a static address, but in our experiments we will just remember to change config whenever the ens34 address changes):
Also we can see using ‘ip route’ that ens33 “Ethernet connection 1” with lower (as in “better”) metric value of 100, gets to be the real i.e. selected default route:
So that’s good, now we can continue configuring this VM so that it becomes a router.
The default setting for Linux distros is that they are not able to route traffic, also here in Debian 10 we see this is the default:
$ sudo sysctl net.ipv4.ip_forward
Now ip-forwarding is just a boolean property which when switched on (value = 1), allows the computer to forward traffic to another address, and when switched off (value = 0), means the computer cannot forward such traffic:
If we wanted to switch ip-forwarding on temporarily, the command would be:
$ sudo sysctl -w net.ipv4.ip_forward=1
But we will want this ip-forwarding ability to survive reboots, so in addition to the temporary switching on above, we cd into directory /etc/sysctl.d/ and from there:
$ sudo touch 10-router.conf
$ sudo nano 10-router.conf
… and in this new config file we add the property:
net.ipv4.ip_forward=1
Now we have a VM that will forward packets from one subnet to the other, and it is connected to both the subnets of interest. Basically, that’s enough to work as a router. What we still need to do is to add a couple of temporary routes on the VMs that should connect via the router.
On Ubuntu SAP server VM, add a new route to the subnet “Home Wi-fi” which goes via the router’s IPv4 address on the Fusion NAT subnet.
On openSUSE SAPGUI client VM, add a new route to the subnet “Fusion NAT” which goes via the router’s IPv4 address on the Home Wi-fi subnet.
These will be temporary additions, since once this experiment is over we don’t need to persist these through reboots. Let’s add those routes now…
On Ubuntu, where the only relevant network device (interface) is called “ens33”
$ sudo ip route add 192.168.8.0/24 via 192.168.108.150 dev ens33
On openSUSE, where the interface we need is called “eth0”, we check from the router which DHCP IPv4 address the router currently has on the Home Wi-fi subnet, for example this evening it is on 192.168.8.114, so our command is:
$ sudo ip route add 192.168.108.0/24 via 192.168.8.114 dev eth0
Now that these two temporary routes are added, we should be able to ssh from openSUSE SAPGUI client VM to Ubuntu SAP server VM, thanks to the router forwarding traffic between the relevant subnets. Let’s test connectivity, first with ping then with ssh:
All good, we can exit from the ssh session (optional but recommended since we have no current use for this session; relevant command is just “exit”).
The next step in this experiment is to set up a SAPGUI connection in our SAPGUI client and from there we should be able to login to the SAP instance on the Ubuntu server (we assume you have your SAP instance up and running, see the SAP on Ubuntu blog for details). So here I specify the IPv4 address of the SAP Host (“H/192.168.108.149”) and the instance number 00 (“S/3200”, as the port number is 32xx where xx is the SAP instance number) all according to the special SAPGUI notation:
conn=/H/192.168.108.149/S/3200
Then we can connect to SAP by double-clicking on the connection:
Now our Debian router is not filtering on protocol or port, so if SAPGUI over port 3200 works, we could expect the Fiori Launchpad over port 44300 to work also in our browser.
The relevant URL is: https://vhcalnplci:44300/sap/bc/ui2/flp
It’s better to use the hostname instead of the dot-notation in the URL, because the Fiori apps themselves tend only to “play right” when their containing Fiori Launchpad has a proper name. So in our openSUSE VM, we can easily change the hosts file to suit this way of doing things:
$ sudo nano /etc/hosts
Add in these two lines, or at least the second line, first is just a comment (though recommended to always comment your own config):
# SAP on Ubuntu VM on Fusion-NAT subnet:
192.168.108.149 vhcalnplci vhcalnplci.dummy.nodomain
Then save and exit: Ctrl+O, <Enter>, Ctrl+X.
Now you can open, say Firefox (default browser installed with openSUSE), and click past the warning about untrusted HTTPS certificate (of course Firefox has never heard of such a website, and any self-signed certificate vhcalnplci offers will hardly be trusted).
We “Accept the Risk and Continue” since we know that it is our own VM on our own laptop, surely we would not try any dirty tricks against ourselves, and then we get to the Fiori Launchpad just fine:
First time you log in, it may take a while to load the Fiori tiles, as in the background the SAP instance is generating or activating a load of Abap code and OData Services etcetera. Also, you might load with a blank screen the first time, if so try refreshing the page, worked for me. Similarly, the first time you open a specific app, the load time may be in minutes rather than seconds, for the same reason: stuff getting compiled for the first time on the server side.
Experiment 1 successfully completed!
[Note: although SAP offers a highly useful product called SAProuter, still for this blog we won’t be using SAProuter, since (a) you need an S-user to download it, and (b) it would take a fair bit of hacking around to let an ordinary browser connect to Fiori Launchpad over HTTPS via SAProuter; generally, SAProuter is very much focused on SAPGUI and RFC connections (“Supported Scenarios”), while HTTP(S) is an “Unsupported Scenario”].
Experiment 2: using SquidMan for HTTPS, plus a bonus dnsmasq trick!
Supposing you are not that bothered about using SAPGUI (though personally I like SAPGUI and believe it will be around for many years to come)… anyway, you intend to do all your SAP stuff using the Fiori Launchpad and/or SAPGUI for HTML (← basically, with just a few server-side changes you can make almost all SAPGUI transactions available in a browser over the HTTP protocol).
Then a quick solution to the case where your client VM has no direct route to your SAP server, is to run a proxy server on the host laptop. The proxy server, you can think of it as a “router for HTTP(S) requests”, as that is what it is doing here: the client browser routes outgoing URL requests to the Squid proxy server, which then forwards those on to the SAP server on Ubuntu, and returns the response to the client browser.
Now since I am using a MacBook for these experiments, then I guess the easiest way to set up and manage a proxy server on MacBook is to install SquidMan:
https://squidman.net/squidman/index.html
SquidMan is a neat GUI wrapper on the popular Squid software for caching and proxying:
If you are running Linux or Windows as your host, I suppose you can find something similar – at least on Ubuntu I once used the non-GUI style of Squid config files edited via nano… happy days; Windows, well I haven’t done any proxy server work in that OS-realm but indeed Squid is available for that OS-family also:
https://wiki.squid-cache.org/SquidFaq/BinaryPackages
WARNING: if you are using a computer owned by an organisation, or the computer is connecting to some organisation’s network, you really need to check with the IT Security department as to whether you are allowed to run a proxy server on your machine. In some workplaces that is not allowed (I suppose because when you run a proxy server, if you are clever you can get around e.g. company whitelisting of acceptable websites to visit), or it is only allowed if you present a valid use case, e.g. “I need to test my code against a proxy server but our real one is not reachable from Dev environment”. In summary, it’s best to ask first, and to follow the organisation policy to the letter! This blog was done on a home computer never connecting to any organisation’s network, so this is the safest scenario and recommended for everyone else too.
So let’s assume you have installed SquidMan and started it running on its default port of 8080, which you can see from menu path SquidMan → Preferences → General.
Next, you should switch to the tab called “Clients” and there you can either specify the IPv4 address of your openSUSE client VM, or if we assume that none of your family members or flatmates are hackers, you can add the subnet of the Home Wi-fi that your client VM is on, that is what I went for so in my case it is the subnet 192.168.8.0/24:
Next, we need to go to the tab called “Template”, and scroll down to find the line that says:
http_access deny CONNECT !SSL_ports.
Since our Fiori Launchpad (and if switched on, SAPGUI for HTML) is/are not using secure SSL ports (because the browsers do not recognise the mini-SAP host vhcalnplci even if it would present a self-signed certificate), so anyway we need to comment this line out, by putting a ‘#’ character at the start of the line, as in the highlighted line in the screenshot:
After that is done, use the Save button to tell SquidMan to re-read the settings, at this point SquidMan should say “Squid has been reconfigured” so you know your new settings have been applied:
Now we can go to the Firefox browser in the client VM, under Settings icon…
…go to Preferences. From there you scroll down in the General section to find a heading called “Network Settings” with button “Settings”; in those settings switch to Manual Configuration, where you put the IPv4 address of your host laptop, and the port 8080, as the new Proxy settings (click the checkbox to apply to all protocols):
Press “OK” to save the settings. Now you can go for example to your Fiori Launchpad and login (we assume you have the relevant entry in your hosts file from Experiment 1 above):
https://vhcalnplci:44300/sap/bc/ui2/flp#Shell-home
So what happens here is the request is routed via the SquidMan proxy server according to the Firefox settings we just made, and the proxy server then forwards the request on to the SAP server on Ubuntu, and so the client browser manages to get a response from the SAP server.
dnsmasq for the masses!
Lastly in the Experiment 2 section, as a nerdy bonus, we show how to use a useful program called dnsmasq to offload the work of resolving the SAP server hostname vhcalnplci to be done by dnsmasq, rather than using the hosts files of a client VM or of the host laptop.
There is a nice blog for MacBook users on how to use dnsmasq config files instead of your machines /etc/hosts file, I will paraphrase all the needed steps for our experiment:
https://www.stevenrombauts.be/2018/01/use-dnsmasq-instead-of-etc-hosts/
So first of all, you need to install dnsmasq on the host laptop, that is best done using the Homebrew package manager, if you don’t already have Homebrew then go to their website and get that installed first:
Once that is done, update Homebrew and install dnsmasq (BTW the zsh shell which is default on macOS since Catalina release, uses the ‘%’ symbol as its prompt):
% brew update
% brew install dnsmasq
Then, comment out from your laptop’s hosts file any entry resolving vhcalnplci. Assuming you have nano (e.g. “% brew install nano” would likely work; or, use vi or any other test editor):
% sudo nano /etc/hosts
[comment out the vhcalnplci line, then Ctrl+O,<Enter>,Ctrl+X]
% cat /etc/hosts
Then you can start up your dnsmasq program:
% sudo brew services start dnsmasq
Now we will configure dnsmasq to resolve only our SAP server on Ubuntu, on host vhcalnplci…
% cd /usr/local/etc/
% nano dnsmasq.conf
Scroll to bottom of the file using Ctrl+V. Add the line:
conf-dir=/usr/local/etc/dnsmasq.d,*.conf
Save and close the file. Then we create the directory (if it doesn’t already exist), and create and open a new config file:
% mkdir -p /usr/local/etc/dnsmasq.d
% nano /usr/local/etc/dnsmasq.d/development.conf
We are going to try adding just this line:
address=/vhcalnplci/192.168.108.149
Save and close the file. Restart dnsmasq to see if it picks up the changes:
% sudo brew services restart dnsmasq
Let’s ask our localhost (dnsmasq) nameserver to tell us what it now knows:
% dig vhcalnplci @127.0.0.1
;; ANSWER SECTION:
vhcalnplci. 0 IN A 192.168.108.149
Looks ok so far.
Next thing to do is to let MacBook know that we only want use the dnsmasq in case of DNS requests for a domain ending with “vhcalnplci”:
% sudo mkdir /etc/resolver
% sudo nano /etc/resolver/vhcalnplci
We add the line:
nameserver 127.0.0.1
Then save and close the file.
Now let’s see if our laptop has noted the special treatment for domain vhcalnplci (two consecutive dashes before ‘dns’ in the following command, but the blogsite software seems to have a feature or bug converting two dashes to one):
% scutil –dns
Good. Now we can test that we can reach the outside world, while also being able to resolve the hostname vhcalnplci, using ping:
It works. Now, back in your client VM, you can remove the resolution of vhcalnplci from the client VM’s /etc/hosts file. Then you also need to switch your DNS nameserver to be the address of the host laptop, so for example 192.168.8.109 (we are using NetworkManager and its GUI for this, as when installing openSUSE went for NetworkManager rather than Wicked as the networking “controller”):
So now what happens is that when in the browser we enter the address of the SAP server’s Fiori Launchpad on host “vhcalnplci”, the browser gets the information from Network Settings that the DNS nameserver is the host laptop on 192.168.8.109, and when the DNS request arrives to the laptop, dnsmasq is then “capturing” the request due to the MacBook’s scutil settings assigning the vhcalnplci-“domain” to dnsmasq as resolver on localhost, and then dnsmasq is resolving the address according to the “address=..” config line we added above. And so we manage to connect successfully:
We can also see, using the program “dig”, that the client VM can resolve the host “vhcalnplci”, thanks to dnsmasq on 192.168.8.109, while it cannot resolve a host on the same Fusion-NAT subnet called “debian-router” (since there is no resolution for this hostname configured in dnsmasq, nor in the host laptop’s DNS settings or hosts file).
So there you go, that was our Experiment 2 with SquidMan, with dnsmasq as a bonus!
To stop dnsmasq, the command is:
% sudo brew services stop dnsmasq
After you have stopped dnsmasq, you might want to modify again your client VM’s Network Settings to pick up its “normal” DNS nameserver (the one that the DHCP server usually specifies, in our case 192.168.8.1) using Auto mode again instead of manual. And if you want to connect to vhcalnplci, without using dnsmasq or relying on the host laptop’s DNS resolution, then of course you can add the relevant resolution line for vhcalnplci back to the client VM’s hosts file. And inform macOS’s scutil that there is no special treatment for vhcalnplci anymore, by deleting the relevant config file:
% sudo rm /etc/resolver/vhcalnplci
Similarly, if you close SquidMan, then in Firefox in the client VM, you can switch the Network settings back to using No Proxy, since there is no proxy server when SquidMan is shut down.
Experiment 3: SSH tunnels
If you have OS-level access to the server your SAP instance is running on, as in our scenarios, and SSH port 22 is open for business on the server and on the host laptop, then you can set up SSH tunnels for e.g. port 3200 (SAPGUI) and port 44300 (Fiori), and connect to SAP from your client VM over the SSH tunnels.
Remember also to allow remote logins to your MacBook, from the Sharing settings (as described in Experiment 1).
Let’s begin with a test that doesn’t require SAP server to be running, instead we spin up a simple HTTP server on the Ubuntu VM, as follows:
$ python3 -m http.server 7777
If we call this HTTP server using e.g. a browser (or the “curl” tool is also good), it should return a list of the files and directories in the directory the server was started from. Since our host laptop has access to the Fusion-NAT subnet, this link will work:
http://192.168.108.149:7777
We can see our connection attempt went ok by viewing the live log of the python server (relevant line is the “HTTP 200” one, we don’t need to care about favicon.ico not being found, though if you are worried then the reason it isn’t found is because in this folder it does not exist, as there are currently no plans to have a nice wee icon displayed for this temporary website). You can also see here that our host laptop whose browser just called in to our HTTP server, is part of the Fusion-NAT subnet, on node 192.168.108.1:
So what we want to do next, is to be able to access this “website” using an SSH tunnel. (Remember, the openSUSE client VM does not have any direct route to the Ubuntu VM on 192.168.108.149). So we set up an SSH tunnel, which goes first from the client VM to the host laptop, and then onwards from the host laptop to the Ubuntu server, in a way that we are port-forwarding the port 7777.
In the client VM, the magic spell is:
% ssh -A -t -l hostlaptop-user 192.168.8.109 -L 7777:localhost:7777 ssh ubuntu-vm-user@192.168.108.149 -N -L 7777:localhost:7777
In this case I am not using pem files (if you are using these, you will need the “-i” flag and the filepath of the pem file, leaving that as an exercise for the reader) so need to enter the consecutive passwords in order to authenticate:
What this tunnel does is as follows: on the client VM, when we connect to port 7777 on localhost, this connection is forwarded first to port 7777 on the host laptop, and from there onwards to port 7777 on the Ubuntu VM. I’ll explain the various flags below, but first let’s check that the SSH tunnel works: with the tunnel still open, we go to Firefox and enter the URL: http://localhost:7777
It works! As we see checking the python log on Ubuntu, due to the port-forwarding, python sees that the connection was on Ubuntu-as-localhost’s port 7777, which in a sense it was, the original port and host of the client VM is not visible in this log:
So anyway, what were the various flags in the SSH command? In order of appearance, and paraphrasing or copying from the ssh man pages:
-A “Enables forwarding of connections from an authentication agent…”.
-t “Force pseudo-terminal allocation” … I guess so we can execute the nested ssh command.
-l [as in the letter after ‘k’ and before ‘m’ in the alphabet] “Specifies the user to log in as on the remote machine”.
-L “[bind_address:]port:host:hostport” … this is the flag that does the first port-forwarding from client VM to host laptop.
-N “Do not execute a remote command. This is useful for just forwarding ports.”.
-L …this does the second port-forwarding from host laptop to Ubuntu VM.
If you want to check in the client VM, that port 7777 is now listening, try e.g. the command:
$ sudo lsof -i -P -n | grep LISTEN
If you like, on the jump-server (MacBook Pro), you can check that as a result of the SSH command, port 7777 is listening on the jump-server also:
% sudo lsof -PiTCP -sTCP:LISTEN
Now that our test SSH tunnel worked, we can close the tunnel (in the terminal where you opened the tunnel, use Ctrl+C to close it, same command works if you want to close the HTTP server on Ubuntu). Then we can start up SAP on Ubuntu (if it is not already running), and on the client VM we open two new SSH tunnels, one tunnel to port-forward port 3200, the other tunnel to port-forward port 44300:
% ssh -A -t -l hostlaptop-user 192.168.8.109 -L 3200:localhost:3200 ssh ubuntu-vm-user@192.168.108.149 -N -L 3200:localhost:3200
% ssh -A -t -l hostlaptop-user 192.168.8.109 -L 44300:localhost:44300 ssh ubuntu-vm-user@192.168.108.149 -N -L 44300:localhost:44300
Then, with those tunnels open, we can test SAPGUI and Fiori Launchpad connections…
In SAPGUI for Java, we can make a new connection item using the string:
conn=/H/localhost/S/3200
Then we double-click the new connection item:
Excellent!
If we login to SAP now, and go to transaction code SM04, and view the value of “Client Host”, note that it matches the hostname of our openSUSE client VM. So the visibility of the “origin” host is preserved, even though we are connecting to SAP using the SSH tunnel and port-forwarding via the localhosts.
Next we want to login to the Fiori Launchpad, the URL we need this time is:
https://localhost:44300/sap/bc/ui2/flp#Shell-home
localhost is sensibly not really trusted to be the true provider of the Fiori Launchpad, click past the warnings as we did in Experiment 1 to get to the website:
Then we can login ok:
Although sometimes in “real S4” Fiori Launchpad scenarios I have found Fiori apps that don’t really work when the Launchpad is accessed via a URL with dot-notation IPv4 address or “localhost” as the hostname, still with the 2 demo apps in SAP NetWeaver Dev Edition, the apps seem to run ok in this experiment also:
Now we have successfully completed the main part of Experiment 3, we can close the SSH tunnels (Ctrl+C), always good practice not to leave tunnels open when idle.
Bonus track: Reverse SSH tunnels
If you would prefer to do the SSH tunnelling work when logged in to the Ubuntu server, then this is fairly easy to do. So the idea here with Reverse SSH connections is that you are on the “target” side i.e. you are logged into the future target of connections from clients. The syntax uses the “-R” flag which is like the “-L” flag but binding the ports to be forwarded in the “reverse” direction i.e. “remote-port:host:local-port”.
So with the client VM currently on 192.168.8.108 on Home Wi-fi subnet, the commands for our three ports 7777, 3200, and 44300 mentioned in Experiment 3 above, go like so, from Ubuntu VM:
$ ssh -A -t -l hostlaptop-user 192.168.108.1 -R 7777:localhost:7777 ssh opensuse-vm-user@192.168.8.108 -N -R 7777:localhost:7777
$ ssh -A -t -l hostlaptop-user 192.168.108.1 -R 3200:localhost:3200 ssh opensuse-vm-user@192.168.8.108 -N -R 3200:localhost:3200
$ ssh -A -t -l hostlaptop-user 192.168.108.1 -R 44300:localhost:44300 ssh opensuse-vm-user@192.168.8.108 -N -R 44300:localhost:44300
The only difference really is that the Ubuntu SAP server’s system admin or BOFH is the one setting up the tunnels, rather than the user of the client VM having to do the SSH work. After entering the SSH commands on Ubuntu, switch to the openSUSE client VM and check that the 3 new tunnels are working fine:
All good. Let’s close the SSH tunnels, and with that also end this blog.