--
Sent from my Android phone with GMX Mail. Please excuse my brevity.
"Nishimura, Scott L (ESS)" <[email protected]> wrote:
But, I've run into another problem. After putting the FW rule for the 3 mandatory entries here
http://docs.oracle.com/cd/E22662_01/E22659/html/Reqs-Ports-Protocols.html
the thin client was able to connect to the SRS and display the initial screen. However, every 15 minutes or so, the TC reboots, as if a timeout of some sort was reached. The FW guy says there is nothing happening traffic-wise between the TC and SRS at the time of the reboot but he can see the session being torn down and rebuilt and the phrase "timeout" does appear, although not the source of the timeout.
/var/opt/SUNWut/log/messages shows
Sep 11 11:14:28 SRS_name utauthd: [ID 828488 user.info] Worker0 NOTICE: DISCONNECT IEEE802.002128130ace, pseudo.002128130ace discReq-or-terminated
The other interesting thing is the line that comes after the above:
Sep 11 11:14:28 rsunsu03 utauthd: [ID 291448 user.info] Worker0 NOTICE: DESTROY pseudo.002128130ace lifetime=800138
It may be coincidence, but if I assume the lifetime # is in milli-seconds, it translates to 13.7 minutes. Once I saw the lifetime # drop and I saw the time to the next disconnect drop also [not exactly proportionally but enough to tempt me into hoping for causality].
To test this theory, how would I go about altering the lifetime? I'm not even sure this is a good idea due to the effect it would have on all of the other TCs that I'm not having problems with but I at least wanted to validate my theory.
I also get the occasional "X11 connection rejected because of wrong authentication" but not every 15 minutes so I'm thinking that's some other issue.
Of course, if anyone has a clean solution, that would be even better!
TIA.
Scott
-----Original Message-----
From: Nishimura, Scott L (ESS)
Sent: Thursday, August 29, 2013 10:12 AM
To: SunRay-Users mailing list
Subject: RE: SRS + Firewall + TC: port question
Update: I got it to work by concentrating on only 1 SRS and the "mandatory" ports [see web page in my previous email]. The user reports odd dropouts before getting to the Windows login so I'm going to add the other 2 SRSs in one FW rule request and the "recommended" and "optional" ports in another.
It turns out InfoSec was OK with the "dynamic" entry because it was only going to one server [well, 3 when I get done].
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Nishimura, Scott L (ESS)
Sent: Tuesday, August 13, 2013 2:42 PM
To: SunRay-Users mailing list
Subject: EXT :[SunRay-Users] SRS + Firewall + TC: port question
I'm looking into putting some TCs behind a firewall to satisfy certain security requirements. I found a good document detailing with the ports and directional flow
http://docs.oracle.com/cd/E22662_01/E22659/html/Reqs-Ports-Protocols.html
but the two mandatory entries that say "dynamic" worry me because my InfoSec will likely reject any request that can't specify a port or, at worst, a small range of ports.
Dynamic/TCP
unicast=>>
ALP-AUTH
<=unicast
7009/TCP (utauthd)
Sun Ray Server
Mandatory
Presence, control, status
Dynamic/UDP with port number >= 32768
unicast=> or unicast=>> when NAT is in use ALP-RENDER <<=unicast or <=unicast when NAT is in use Dynamic/UDP constrained by utservices-low and utservices-high Sun Ray Server Mandatory On-screen drawing, user input, audio
Is there a way I can specify which port the communication goes over, increasing my chances that my Information Security team will approve the FW rule request?
Solaris 10/update 8
SRSS 4.2
SRWC 2.2
Thanks.
Scott
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
