On Sunday 19 May 2002 11:24 pm, you wrote: > David Douthitt wrote: > > On Saturday 18 May 2002 11:14 am, Stephen Lee wrote: > > > I tunnel imap and smtp all the time except I use stunnel.
> Perhaps ssh -g option? Don't use that: dgd $ slogin -L 143:lena:143 -L 110:lena:110 dgd@lena > I always liked the ssh description on the VNC site. Me too. > Please see the > "More advanced use" section at the bottom of the page. They have a > configuration that looks like yours. They used > ssh -g -L 5901:windows2:5900 linux2. > > This quote was troubling "...but remember that connections between > snoopy and third machine will not be encrypted..." (...not refering to the VNC docs....) This is because the ssh tunnel goes from machine A to machine B - if you are forwarding a local port, the end can go anywhere - such as to machine C. In my case, there is no machine C - or at least, machine B and C are the same. > From your original post: > Perhaps -C or +C? The VNC ssh "Compression" section has this > quote. It may apply to you because of ppp? "SSH has another > advantage. It can compress the data as well. This is particularly > useful if the link between you and the server is a slow one, such > as a modem..." My impression was that VNC performed compression, not ssh - but I will look again. But that won't solve my troubles... > Just another thought....I was playing with ssh internally. I was > testing another firewall. I was racking my brain until I realized > that the firewall rules were blocking the RFC 1918/1627/1597 > addresses. It sounds like you already took care of that issue, > however. Not quite. See discussion below. > Last idea...perhaps you are experiencing the reason cipe and I > guess stunnel were developed: > http://sites.inka.de/~bigred/devel/tcp-tcp.html. Please see the > "Practical experience" section. > "The whole problem was the original incentive to start the CIPE > project, because I used a PPP over SSH solution for some time and > it proved to be fairly unusable. At that time it had to run over an > optical link which suffered frequent packet loss, sometimes 10-20% > over an extended period of time. With plain TCP, this was just > bearable (because the link was not congested), but with the stacked > protocols, connections would get really slow and then break very > frequently." I don't think this applies - I'm running SSH over PPP, not PPP over SSH. The layers are like so: TOP ====> TCP/IP SSH PPP Phone Here is what I see happening - and it sounds just exactly like some sort of routing problem: 1. SYN Packet is sent from host1 to host2 over an SSH tunnel (which has a PPP link in the middle) 2. SYN Reply Packet is sent from host2 to host1 over unecrypted Internet links. Also, the return SYN packet conains the internal IP of the ssh tunnel in host1 (a 192.168.4.7 address apparently). Thus the private IP packet quickly reaches a router willing to kill it or ignore it. Why is host2 routing the packet away from the ssh tunnel? Note, too, that neither of the endpoints of the ssh tunnel are the endpoints of the PPP link - and that the LRP system is providing NAT for the network behind it. Of course, using ssh across this link, the NAT is not done. However, I've had situations like this (with the same setup, but not with a PPP link) that worked just fine. Of course, that was a Linux host1 to a Linux host2 - these are FreeBSD hosts. _______________________________________________________________ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
