Cluster thru firewall - what ports to enable?

[Paul Jerrom]

Howdy,

My lord and master wants me to set up a cluster with the principal nodes each behind their own firewalls. Is this possible, and is there anything I need to do to enable clustering and shadowing to talk between the servers via the firewalls? ANything else to be aware of?

Thanks
PJ

[Jeremy Begg · Accepted solution]

Hello Paul,

VMScluster does not use TCP/IP or any other routable network protocol. So your firewall has to allow ethernet traffic between the cluster members.

The OpenVMS I/O User's Reference Manual (LAN device drivers chapter) says that VMScluster uses a range of ethernet multicast addresses, AB-00-04-01-00-00 through AB-00-04-01-FF-FF. (And my guess is that the final two octets will be based on the SCSSYSTEMID.) The manual also says that VMScluster uses ethernet protocol 60-07 (aka "SCA").

Regards,

Jeremy Begg

[Paul Jerrom]

Awesome Jeremy, thanks for your help.

Regards,

PJ

[Thomas Ritter]

Paul, your on collision course towards a disaster. No cluster communications or any internode communications, DECNET, LAT or other should be going through a firewall. In our four node cluster, we have backend networks and frontend networks. All firewall connectivity is frontend and everything else is backend. You should be looking at having multiple ethernet cards and seperating your access.

[Hoff]

To strengthen what Thomas Ritter writes: if and when SCS passes through a firewall and becomes exposed, then anyone on the same LAN can join the "party"; the cluster is wide-open.

The SCS cluster protocols and cluster network traffic must be protected from packet sniffing, and from rogue nodes. (You can run a rogue cluster node on your average laptop, using widely-available emulation, if you're so included.)

If you want to operate one of these clusters and bridge together firewall-protected OpenVMS nodes across an untrusted network, then an encrypted and closed VPN or other such would probably be employed.

[Robert Gezelter]

PJ,

I agree with all of the posts so far, this is a far from recommended course (please read this as a diplomatic "DO NOT DO IT").

SCS does not go over either DECnet or TCP/IP, but uses Ethernet directly. Most firewalls will simply not do this correctly. Second, the traffic will be "en claire" between the two nodes, so it will not be protected between the firewalls. People have, I am sure, run SCS traffic over encrypted, tunneled Ethernet bridges, but that is not a beginner project and must be done with care.

The operative question is actually: What are the firewalls protecting against? If it is accesses from the outside world, then the correct configuration, IMHO, is to use a separate cluster LAN on separate adapters. If the idea is to protect the two nodes from each other, this is not a productive concept concept, because cluster nodes share too many intimate details.

I hope that the above is helpful. If I have been unclear, please let me know.

- Bob Gezelter, http://www.rlgsc.com

[Willem Grooters]

[quote]
(You can run a rogue cluster node on your average laptop, using widely-available emulation, if you're so included.)
[/quote]

Hopefully, this is limited by the cluster_id and password that goes with it.

Otherwise, you wouldn't be able to run separate clusters - on the same LAN (it's another question whether you would want to do that - but it can be done)

May I extend LAN to Wireless? I run my emulated Alpha on my laptop (with a number of protective programs active) and cluster it with the real VMS box on the wired LAN - over wireless access point (inluding stealth SSID, WEP protection and encryption).
No intermediate firewall though.

However - The Clustering roadmap states that SCS over IP has been foreseen in VMS 8.4, and that will have it's impact in this area.
Hopefully, it will be just an option, not a requirement. In case you want to use SCS over IP, a separate LAN is IMHO mandantory.

[Hoff]

[quote]
(You can run a rogue cluster node on your average laptop, using widely-available emulation, if you're so included.)
[/quote]

[[[Hopefully, this is limited by the cluster_id and password that goes with it.]]]

SCS network data must be protected.

In deference to HP and ITRC, I'm not going into any particular details here.

[[[Otherwise, you wouldn't be able to run separate clusters - on the same LAN (it's another question whether you would want to do that - but it can be done)]]]

Again, SCS network data must be protected.

[[[May I extend LAN to Wireless? I run my emulated Alpha on my laptop (with a number of protective programs active) and cluster it with the real VMS box on the wired LAN - over wireless access point (inluding stealth SSID, WEP protection and encryption).
No intermediate firewall though.]]]

If you have a device that provides an access point (AP), likely yes. If you have the typical WiFi IP router, no.

[[[However - The Clustering roadmap states that SCS over IP has been foreseen in VMS 8.4, and that will have it's impact in this area.]]]

We'll have to wait for public discussions of what HP plans to release here, beyond the general statements from the roadmap.

It's already feasible to operate a cluster over IP given widely available networking gear; basically an encapsulating bridge. FCIP is another approach that's available, where a FC SAN can be extended over IP.

[[[Hopefully, it will be just an option, not a requirement. In case you want to use SCS over IP, a separate LAN is IMHO mandantory.]]]

I'd personally doubt the existing SCS design is going to be changed when IP-capable clustering is deployed, nor would I expect to see a forced migration -- compatibility being longstanding tradition with OpenVMS. But then, we'll just have to wait to learn what HP has up its sleeve with IP clustering.

[Willem Grooters]

[quote]
SCS network data must be protected.
[/quote]
Fully agreed on that; My impression was that ANY VMS server could join the cluster, and AFAIK this is prevented by CLUSTER_AUTHORIZE.DAT - and that file, of course, must be inaccessible (except for the node itself)

[Louis in Michigan]

[[quote]]
SCS network data must be protected.
[[/quote]]
[[[quote]]]
Fully agreed on that; My impression was that ANY VMS server could join the cluster, and AFAIK this is prevented by CLUSTER_AUTHORIZE.DAT - and that file, of course, must be inaccessible (except for the node itself)
[[[/quote]]]

The ability to run multiple distinct clusters on one LAN is based, AFAIK, on a gentlemenâ s agreement since all ethernet packets are sent in the clear. Everyone involved agrees to use only their own cluster number and password. If I want to crash the party I merely lie in wait sniffing the SCS packets until I have obtained the needed cluster number, cluster password and list of active nodes. Then I forge my own credentials and join in the fun.
If the above is true, then I would never let anything untrusted connect to the LAN carrying SCS.