Using a SOCKS5 Proxy to Replicate GoldenGate to Azure Cloud Services

Edward Whalen

Replicating to the Azure cloud is like any other replication with one exception.  In order to connect to the Azure server, you must setup a proxy that uses a PKI key for authentication and set up a SOCKS5 proxy to port tunnel from on-prem to the Azure cloud.  Using a SOCKS5 Proxy to Replicate GoldenGate to Azure Cloud Services is described below. This will allow the GoldenGate pump to replicate data to the Azure cloud via a tunnel through port 22 on the Azure cloud.

The Azure cloud is limited on the number of ports that can be opened to the outside world.  In addition, the IP addresses within the Azure cloud are NATed (Network Address Translation).  To the outside world you will see a normal internet IP address, but inside you will see that the server has been assigned a private address such as 10.10.1.2.

So, in order to connect from the on-prem GoldenGate to Azure cloud, you will have to tunnel through an available port (22) and translate to the Azure local (or other) host.  This method is used for Azure as well as for tunneling to the Oracle Cloud.

Prior to setup you should have installed the Oracle Client on the Azure hub server as well as the GoldenGate software.

The Azure server should be configured to accept ssh connections from your on-prem DMZ server by using the public ssh key of that server during the Azure configuration.  Prior to configuring the SOCKS5 proxy you should test passwordless connectivity to the Azure server from the DMZ server.  For this example, the oracle user is configured for Azure.  Once this has been done, configure the SOCKS5 proxy for a test connection.

This is straight-forward and easy to setup.  Using the ssh command on your DMZ server you will setup a listening port and a forwarding address to connect incoming GoldenGate pump requests to the GGCS server.

The ssh command is setup to forward requests via a static connection.  The following command is used to setup the SOCKS5 proxy.

ssh -v -N -f -D <DMZ>:<Port> <user>@<Azure> -E socks.out

The following parameters are used in my example:

-v                     verbose

-N                     do not execute remote command

-f                      go in to background (like nohup)

-D                     bind address IP and port to listen on

Addr                 Connection information.  This is where it will tunnel to using PKI

-E                     logging file

Here is an example for connecting to the Azure cloud.

ssh -v -N -f -D ptc02:9008 oracle@40.78.129.64 -E socks.out

Once the SOCKS proxy is in place, the GoldenGate pump process is modified to use the SOCKS5 proxy by changing the RMTHOST line in the parameter file like this:

RMTHOST localhost, COMPRESS, MGRPORT 7809, SOCKSPROXY ptc02:9008

Since the SOCKS5 proxy forwards the request to the Azure server it is essentially connecting to a manager process on the server it is running on.  Thus, the target hostname from the forwarded pump perspective is localhost or the local IP address.  The SOCKSPROXY is the DMZ server and port.

With this configuration you will not have to open any access other than the SSH access defined using the PKI key.  This was done during the initial configuration of the Azure VM.  Once this is working, replicating to the cloud is easy.

If you have multiple cloud instances just setup multiple SOCKS5 proxies on different ports.  If you have multiple pumps going to the same hub server then one proxy should be sufficient.

Note:  If you are running the Linux firewalld you will need to open the proper port(s)

firewall-cmd –zone=public –add-port=9008/tcp –permanent

firewall-cmd –reload