I agree that both methods you've suggested are valid ones for connection DTUs to Sun Ray servers over the Internet, but I'm keen to understand why the un-complying Sun Ray server is handling the ALP traffic in the way that it does.
On a separate note, regarding your method (2), did you use an external VPN client or did you use one built in to the Sun Ray 2 DTU itself? Cheers, Etienne -----Original Message----- From: Jim Klimov [mailto:[email protected]] Sent: 13 December 2011 12:46 To: SunRay-Users mailing list Cc: Ing Etienne V. Depasquale Subject: Re: [SunRay-Users] SRS 4.1 attempts to open ALP traffic to DTU behind a NAT 2011-12-13 15:07, Ing Etienne V. Depasquale пишет: > Good day, > > This question is also posted at the oracle.com communities. > > My Sun Ray 2 DTU sits behind a NAT agent. It is therefore pointless for > my Sun Ray Server 4.1 to do what it is currently doing, specifically: it > is trying to open the ALP UDP connection, rather than wait for the DTU > to open it. Can anyone tell me how to convince the server to wait for > the UDP connection - not initiate it? Another server that I manage does > not pose the same problem with the DTU - it waits for the connection. > Both the servers have the same authentication policy: -r card –z pseudo > –k both I've done this a couple of times with sunrays at home, I am not sure if the solutions were correct by the books - but they did work: 1) One router (DLink DIR-655) allowed to publish a "DMZ host", so that all incoming packets from WAN were NATed to the same ports of the designated LAN IP - SunRay DTU. 2) Later we played with SunRay2 VPNs and set that up. I believe this way ALU is no longer dependant on NAT, as long as the VPN channel works ok - ALU connects servers to DTUs both ways. HTH, //Jim _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
