FYI, here is what we did (for those interested).
We created a static pool of addresses to map to the student machines. Then
we created a conduit allowing only the server to access any machine in the
classroom via port 6000.
Works like a charm.
Thanks to all for the advice.
Wes Noonan, MCSE/MCT/CCNA/NNCSS
Senior QA Rep.
BMC Software, Inc.
(713) 918-2412
[EMAIL PROTECTED]
http://www.bmc.com
-----Original Message-----
From: Reckhard, Tobias [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 19, 2001 00:38
To: 'Noonan, Wesley'
Cc: '[EMAIL PROTECTED]' '
Subject: RE: Permiting X through a PIX
> Unfortunately, I am being told that Solaris does not ship with SSH and it
> would take making some changes to the classrooms that they aren't prepared
> to make right now.
>
OpenSSH should work, I suppose.
> I think this is something that we will probably pursue as
> a long term solution though, based on what I am hearing in this thread and
> from the trainers involved. In the short term though, I need to get access
> working. Would those conduits do the trick?
>
I doubt it. The problem is that in X the identities of the client and the
server are opposite to what most people expect, i.e. the machine that
displays the graphics is the server and the one that the application is
running on is the client. This makes sense, since we're talking about
serving display services. Now, as in any other client-server communication
scheme, the client initiates the connection to the server, while the latter
listens for it. So the actual X connection is made by the servers in DMZ1 to
the machines in DMZ2. Your PIX appears to be set up to allow only initiative
traffic from DMZ2 to DMZ1, so it'll drop those connections. A further
problem is that your DMZ2 is NATed, so the DMZ1 hosts don't know which
destination IP address to connect to. However, from what I know you usually
access remote X clients using XDMCP, so before the X connection is
initiated, XDMCP traffic flies the other way. I don't know if this is
possible on the PIX, but you could use XDMCP traffic from machine A in DMZ2
to machine B in DMZ1 to trigger a rule allowing connections back to TCP
ports 6000+ on the NATed address of machine A and to set up an appropriate
entry in the NAT table.
The nice thing about SSH's port forwarding is that you tunnel everything
through the SSH connection, so you don't need to worry about the directions
in which connections are initiates. Though I won't guarantee that NAT can't
still play stupid tricks on you. Why do you NAT anyway?
> Am I correct in thinking that it
> isn't working because the server needs to send data back on different
> ports
> to the clients and those ports are closed? Would it be better to use the
> established command?
>
Yes and no, see above.
HTH
Tobias
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
