: My UltraVNC connection operates successfully without a hitch, until I : connect the Server PC to the VPN. At that time the UltraVNC : connection is lost and I can no longer access the Server PC. The VPN : connection is established successfully (I know that, because I've : added a monitor to the Server PC). I would prefer to access the : corporate VPN via the UltraVNC connection, instead of installing the - : fairly invasive - software on my primary PC. Why does the VPN crash : the VNC connection? Is there a way to workaround this?
As others mentioned, it's an intentional security feature of most VPNs. In theory, VPN software could create a new IP with which to join your corporate net, but it's a huge secrity hole to do it that way. As also already mentioned, a way to work around it is to bounce the packets onto the corporate net and back; ie, you "submerge" your work PC into the corporate net, then use "add client" to add your home machine's vncviewer. Then you can walk over to your home machine. If this were linux/solaris/whatnot, you could do this all by script, so you wouldn't necessarily have to go to the physical work machine. Disadvantages: slow and potentially insecure (what with the packets flying back and forth on the internat and all). Another way around it (easy-ish to do under linux/solaris/whanot, not so sure how easy under windows, though with cygnus ssh it's probably do-able) is to wire the work PC to the home PC with a non-TCP/IP link; ie, a serial cable between them. Then you run ssh with ProxyCommand set to send the tunnel over that serial line and forward you home PCs localhost:5901 to the work PC's localhost:5900. Then connect to localhost:1 (remembering to allow loopback as needed). Whew. A royal pain in the patoot, but it should work. The key is, the VPN software is capturing all the TCP/IP traffic, but it can't reall capture something like a serial line. It also can't (or rather, normally doesn't) capture microsoft or novell non-TCP/IP networking packets, and doing port forwarding across such a connection is another possibility. But why isn't this a security breach? You're sending the same information over the same ethernet. That's because those protocols aren't normally "routable" on the internet, so the vulnerability is localized to your home LAN. But somebody could still zombify your home PC and hijack your connection, so you must make sure your home PC is secure enough to satisfy your corporate IP security folk. Because weakening the firewall is most often grounds for termination (though your corporate policies may vary). So. Solution to VPN capturing all TCP/IP traffic is to use something non-TCP/IP; this is perhaps easiest to do for things like file sharing and/or lan printer access. Since VNC is TCP/IP-based, you have to use port forwarding through the non-TCP/IP protocol to get your VNC sessions hooked up. The bandwidth limitations of an old-fashioned serial line may be a problem; use of a non-TCP/IP protocol over ethernet would probably require some significant hacking, but only enough to get a stream of bytes point-to-point; ssh (or a few other possibilities, see for example the obsolete program "term" from one of the source newsgroups from days long gone by, but I digress) can do the rest. Oh... one other possibility, if your corporate remote access folks provide it, is to have your entire home LAN submerged into the corporate net, by providing a VPN router to mediate your access to the internet. All the packets you send to the internet then bounce via your corporate net which VPN is active, but locally on the lan, anybody can talk to anybody freely, and VNC can thrive. A nice solution IF it's available. Wayne Throop [EMAIL PROTECTED] _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
