12-08-2014 11:47 PM
Our server installation of SAS under Windows Server 2012 R2 establishes client connections only when the Windows Firewall is turned off.
Client access is over a VPN using SSTP.
What are the default rules that are needed by Windows Firewall for the client to use RSUBMIT with the server instance?
I don't want to turn off Windows Firewall to enable clients to interact with the server instance of SAS.
Thanks in advance.
12-09-2014 03:17 AM
You need to find out what ports your SAS server is communicating over with your SAS clients. Also don't forget you will need to identify ports required to communicate with other servers such as database servers as well.
These are usually defined in your site's SAS Server design documentation done prior to installation. Since these might be customised from what SAS might recommend as a default, no accurate list can be supplied.
Once you have identified these ports, then firewall open port rules need to be defined, along with an appropriate timeout default for inactivity. I suggest at least 8 hours as this covers a typical working day.
12-09-2014 04:09 AM
Indeed, is as SASKiwi says. You can check with your SAS Administrator or System Administrator at your company which ones are those ports.
I can imagine that is a recent SAS installation or migration. Your administrator probably have documentation related to the ports that need to be open and the exact rules.
For RSUMMIT, you make use of SAS/Connect, that is the specific port.
Hereby the default port list: SAS(R) 9.4 Intelligence Platform: Installation and Configuration Guide
12-09-2014 12:27 PM
Thank you for the replies.
I did a default install to be able to use SAS Foundation over a VPN from a dedicated server for SAS.
From the port list above, I created incoming rules for TCP 7541 and 7551. Also an outgoing rule for TCP 7551.
This is not enough to allow a client version of SAS to connect to the server through Windows Firewall. Clearly, it is the firewall, since if I turn it off, the workstations can connect without a problem.
Are there other critical ports that need to be enabled to use SAS Foundation.
12-09-2014 01:11 PM
Mitch, SAS Foundation is local direct access by terminals oriented. You do not want to use that.
The SAS/connect is one of the many services and coming now by the classic listener (default 7541) and one that is based on a series of script-files (7551 default first one) as part of the EIP platform starting with the Metadata-server (default 8561) it will start a port/port communication using generated ones as of 0-64k oeps that are all ports ipv4.
Limiting in ranges is possible. Better go for designing ranges that can be managed in cooperation with you platform admin.
12-09-2014 01:40 PM
Thanks, but I would prefer not to use the SAS Metadata Server.
We only need to be able to run SAS and do statistical processing. That was why I chose the default installation.
12-09-2014 02:51 PM
Once a SAS client connects to the SAS server via the SAS spawner, a SAS workspace server session is started. This could involve port 8591.
I suggest you test out your SAS server's communications with a network traffic analysis tool. This should identify any blocked attempts and the ports SAS is using.
12-09-2014 03:13 PM
There is some understanding on the business needs necessary.
Yes you can do all processing on desktops with no servers being involved, that is a situation where firewalls/network segmentation would become meaningless. The best cost saving action would be to abandon all things around firewalls and network segmentation an accept the risks of a desktop only approach.
You could go for server-based processing having critical data controlled and monitored in the datacenter, but in this case you will need to understand server environments and server based processing. What are your requirements? What clients are you thinking of, as it can be:
- full desktop processing (sas foundation on the desktop)
- thin/medium clients like Eguide
- browser based clients like the SAS-studio
Do not think the browser is free of choice, also there are some (minimal) requiements
SAS studio and Eguide are Metadata based at least you are needing the object spawner with SAS Integration technologies.
12-09-2014 03:27 PM
We have a literal handful of team members. They need to be able to access SAS data extracts to run statistical analysis. It is not practical to replicate the data on every workstation. Nor is it practical for the data to go back and forth via a file server. Therefore, the team members need to be able to use RSUBMIT to initiate SAS statistical analysis on the server and then obtain the SAS output on their workstation.
That's why I selected the default installation.
This works fine, as long as I turn off the Windows Firewall. I don't want to do that. Even though they are accessing the server across a VPN which employs a NAT, once they are connected to the domain, a virus on their machine could attempt to port scan. I need to get the default functionality to work wit the Windows Firewall in Windows Server 2012 R2.
Thanks for trying to help.
12-09-2014 04:17 PM
I still do not understand your environment, the sspi is found at the object-spawner SAS(R) 9.3 Intelligence Platform: Application Server Administration Guide. That is a server based process not communicating to your desktop. the sspi is for IWA (Integrated Windows Authentication) where the SAS server is going to communicate with decicated security provisoners (NTLM). That should be allowed by the firewall when that is between those.
You are stating using the Rsubmit command that one is belonging to sas foundation on the desktop communicating to a server. That assumes having data on the desktop doing file-transfers. At the same sentence you are saying you are not wanting to do that. That are a lot of contradictions. Either confusion of words or of the situation.
12-09-2014 04:40 PM
By default, Windows Firewall blocks Telnet. Adding an incoming port 23 enabled SAS on the workstation to connect with the server.
12-09-2014 04:47 PM
With SAS/Connect, you can submit a job to a remote server. Then allow the workstation to block for the results (synchronous) or run asynchronously. With SAS/Connect, the job submitted through RSUBMIT should run on the server. Only the results are returned to the workstation. That's my understanding and what we desire.
12-09-2014 05:04 PM
Mitch, thanks for your update,
if you make use of the default configuration, maybe this can help you with your needs:
Also, if you are concerned about the security within SAS/CONNECT (very understandable), maybe you would like to read:
A little bit technical: http://support.sas.com/resources/papers/proceedings11/359-2011.pdf
More general: Encryption in SAS(R) 9.4, Third Edition and next chapters on the same document.
But, basically, the first link should be able to help you with the configuration of your firewall, so you can keep your firewall on.
Just an addition: apart from SAS indications - I believe it would fit in your case -, if we speak about network issues, Process Monitor and network analysis tools always help on the right way (tools commonly used by system and network administrators).
Message was edited by: Juan L. Sanchez
12-10-2014 01:40 PM
Mitch, your approach is: using that SAS/Base Foundation meant to do data-analysis on your desktop. A tiny part of that is the SAS/connect usage. It is meant for data-exchange between machines (upload/download) and using RLS (remote librarie services). A part of that is using it as terminal with remote-submit where you must retrieve the data (rget) in a real terminal mode.
Hmmm suppose you are needing a vehicle for going to work. You could go by a 40-tns truck Mack or by eg a http://en.wikipedia.org/wiki/Smart_(automobile). That is big difference for a fit the job to be done. Of course you could go for an image building and choose a Maserati or as in the cloud use the underground.