Connecting to EMC Smarts domains through a NAT-ing firewall

It's not unusual to have to connect the IONIX Smarts consoles to the Smarts servers by way of a NAT-ing firewall. This means the that IP address of the servers on which the Smarts broker and domains run are not the same as those that the consoles must use to connect to them.

In this situation, the "standard" use of the Smarts broker gets in the way of normal operation. In order to help understand why this is, we need to understand the way the broker, the domains and console interoperate. The process works like this..

  • When the broker starts, it registers itself to listen on all the interfaces on the server.
  • When a domain manager starts, it registers with the broker using an internal API which communicates the server IP address, port and process number. The IP address is determined with reference to the server's host name, and hosts file (or DNS). The broker stores these details in it's internal repository.
  • When a console wants to connect to a domain, it first contacts the broker (which will, or course, have to be via the NATted address in our situation) to determine the IP address and port to use. The IP address that the broker passes to the console is the one that the server originally used to register itself.
  • The console then attempts to connect to that IP address and port.

However .. the problem with this process in the presence of NAT is that; the console needs to use a different IP address from the one that the broker stores for the domain - and so: the connection fails.

Some users resort to using the fully-qualified domain name syntax when logging in to bye-pass the issue. However, this trick doesnt allow the console to auto-connect to other domains when operations like "browse detail" are used - this will mean that the user has to enter the domain IP, port and name each time the console connects to another domain on his/her behalf.

Luckily there IS a solution to this annoying problem by using a local broker. The way to get this working is as follows...

    • Start a broker on your workstation PC (where the console GUI is installed and invoked), or some other computer on the same "side" of that NATting firewall as you are that your PC can connect to. Use the relevant options on the "brstart" command or service to allow the broker to save (on shutdown) and restore (on startup) the domain details.
    • Now you should have two brokers running - one on the Smarts domain server platform, and one on your workstation PC.
    • Make a note of the names, IP addresses and ports of the domains listed in the broker on the Smarts server. You can do this using the command from your workstation using commands such as..
C:
cd \InCharge80\CONSOLE\smarts\bin
brcontrol -b {natted-broker-IP-address}::{broker-port-number}
    • Now add these noted domains details into the local broker, but replace the "real" server platform IP addresses with the NATted ones. This is done by typing commands in the following syntax at the workstation PC's cmd.com prompt.
brcontrol add_dm {domain-name} {IP-address} {port-num} {process-id}
for example:
brcontrol add_dm INCHARGE-AM 192.168.0.20 9100 32131

For convenience I suggest saving these commands in a Windows batch file to make it easier to repeat them in future, if needed.

With luck - the job is now done. All you need to do is start the console GUI application and use the local broker instead of the one on the Smarts server when you log in.

However there is another "gotcha" that can trip you up when firewalls are in the way.You may find that your console session continually disconnects and re-connects from/to the Smarts server. This typically happens every minute or so. If you experience this odd behaviour then you probably need to turn off the Smarts internal "keep alive" handshake for both the local broker and the console or configure the firewall to allow TCP urgent data through. You do this by taking two steps, like this...

  • Setting SM_DISABLE_KEEPALIVES to 1 in the local\conf\runcmd_env.sh file (on your workstation) that the local boker uses before starting it (you probably need to stop and restart it). See the "system_admin.pdf" file for more details if you need them.
  • Set the com.smarts.disable_keepalives property to 1 in the local\console\properties.conf file on your workstation (or use the -D option when starting the GUI to set this property). See "sa_operator.pdf" for more details if needed.

Problem solved!

I hope this helps.

Scroll to Top