Hello friends,

Let's assume I have established a VPN tunnel using Vpnc from the N900 to a Cisco PIX (the VPN endpoint). Once I am on the VPN, my N900 is assigned an internal IP address from the VPN pool. Using this IP address I have full access to other machines on my LAN (ping, telnet, ssh, etc.) All seems normal.

The problem comes in when I want to use a Linux machine on my internal LAN as my 'gateway' to the internet using "ssh -D" from the VPN'd host (the N900, in this case). I make the "ssh -D" connection from my VPN'd in N900 to the LAN linux machine, but any attempts to browse the web from the N900 fail (I have set up the N900's Firefox browser to listen using SOCKS on localhost (127.0.0.1) on a specific port). (For those familiar with Easy Debian, I have even tried the "Links" text-only browser inside the Easy Debian image, using the proper SOCKS configuration with no luck, so I know it's not a browser issue).

I have also tried this entire setup using the Cisco native VPN client on a WIndows XP machine with the same results (I can ping, ssh, telnet, etc, but 'ssh -D' doesn't do anything), so I know the problem is not the N900.

For background information, the "ssh -d" is supposed to specify a local ''dynamic'' application-level port forwarding. This works by allocating a socket to listen to port on the local side, bound to a specified bind address. Whenever a connection is made to this port, the connection is forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. In essence, I am trying to create a tunnel using SSH to my linux box so I can browse the web over the VPN.

Additionally, this entire setup works perfectly when my N900 is sitting locally on the LAN (bypassing the VPN altogether), so it seems my "ssh -D" command is correct. I am missing one crucial piece, but I am not sure what this piece is.

Considering the caliber of IT knowledgeable individuals on this forum, I am hoping someone can share their ideas.

Thank you

Can you change your default route on the N900 so that all traffic goes to the VPN, or does your VPN not forward traffic destined for outside addresses?

The way I understand it, all traffic does go the VPN (there is no split-tunneling) when I connect to the VPN. You are exactly correct in that my VPN (Cisco PIX) does not forward traffic destined for outside (internet) addresses, which is precisely why I am forced to use a local Linux machine running SSH to forward my web traffic between my VPN hosts and the internet.

It's possible that this setup is entirely flawed, I would be grateful to hear other suggestions on getting my VPN hosts to reach the Internet.

Sounds like your frame size is too big with all the extra encrypted wrapping. I experienced this before in the past with actual SSH'ing through VPN tunnels.

I am fairly certain that the issue is not the frame size, but to check how would I adjust the frame size? When I connect to the VPN I get a new interface called "tun0' which supposedly handles my VPN traffic.

check your pix, suspect the problem is passing packets back out the same interface that you came in on the vpn.

Last time I wanted to do this I had to put a policy route on, just can't remember the details.

oh yes, if you're running ver 7.1.x or newer on the pix, enable hairpinning and it'll work

I have thought through the concept of 'passing packets out the same interface that they came in on the PIX', but I am fairly certain this is not the issue either. Rather, this is the reason WHY I have to come up with the SSH tunneling workaround. If the Cisco PIX could pass packets back out the same interface then we wouldn't have this challenge, I think.

Unfortunately I am running IOS version 6 something, so the added support available in version 7+ is not an option for this setup. But thanks for your response.

you can achieve it anyway by using a route map to force the traffic back out the interface, it just uses the cpu more than hairpinning

check out route map pix out same interface vpn on google