[NCLUG] ssh question

Scott Scriven nclug at toykeeper.net
Thu Oct 9 21:54:08 MDT 2008


The short version: The ssh / proxy approach is less powerful, but 
gives you fewer opportunities to shoot yourself in the foot.

Everything below is just my rambling about the details, in case 
Jim is interested.

* Bob Proulx <bob at proulx.com> wrote:
> For one ssh tunnels don't show up on a list of system 
> interfaces and don't show up in routing tables.  This might be 
> more of a steganography issue.

Yeah, if someone audits your computer from inside, a VPN would be 
visible.  OTOH, the proxy-over-ssh approach is visible too, by 
looking at Firefox settings.  And in either case, any history or 
cache on your work computer could contain inappropriate data.

Looking from the outside, such as a company router, an openVPN 
connection would normally look a bit different than an ssh 
connection.  If that matters, it's possible to change its 
appearance, but that involves non-default settings so it's less 
convenient.

I've occasionally had to run openVPN over a ssh tunnel, due to 
extremely limited outside access.  It's less efficient, but also 
invisible from the outside.

> Setting up a full vpn with network routing and everything would 
> almost certainly raise some red flags if this is a corporate 
> desktop.

If your work doesn't allow you to bypass their network, you're 
asking for trouble.  Maybe that's okay where you work, but don't 
try to sneak data out of the top secret military labs at Lockheed 
Martin.  :)

> For another in that same case setting up a fully routed VPN 
> while still maintaining access to the local network is a more 
> complicated situation.

Yes, it helps to have a basic understanding of routing.

The way the routing table works, it's a series of targets, going 
from most specific to least specific.  The destination of each 
packet falls through the table from the top until it hits 
something which matches, and then the packet does whatever that 
entry says.

A typical desktop on a large internal network will generally have 
a routing table like this:  (run 'ip route show' or 'ip ro')

  # direct link to internal corporate network
  10.0.0.0/8 dev eth0  proto kernel  scope link  src 10.1.1.101
  # everything else goes over corporate router
  default via 10.0.0.1 dev eth0

This says, basically...  If your destination is on the local 
network, talk to it directly.  Otherwise, send the packets to the 
gateway (10.0.0.1) for further processing.

But with openVPN set up how you might want, the routing is more 
complicated:

  # static route to home
  74.95.87.113 via 10.0.0.1 dev eth0
  # direct link to openVPN
  192.168.8.13 dev tun0  proto kernel  scope link  src 192.168.8.14
  # static route to home network (optional)
  192.168.1.0/24 via 192.168.8.13 dev tun0
  # static route to openVPN network (optional)
  192.168.8.0/24 via 192.168.8.13 dev tun0
  # static route to external corporate network (optional)
  129.82.0.0/16 via 10.0.0.1 dev eth0
  # direct link to internal corporate network
  10.0.0.0/8 dev eth0  proto kernel  scope link  src 10.1.1.101
  # everything else goes over openVPN
  default via 192.168.8.13 dev tun0

This may be a little more than you'd really need, and it may not 
be completely accurate (just spewing some data from the top of my 
head), but it should at least be fairly close.  Some entries are 
redundant, but make it easier to change the default route if 
desired.

Basically, this routing table talks normally to your corporate 
servers, and sends everything else over an encrypted tunnel.

> You would need to make sure the routing is correct for two sets 
> of networks.  Doing this incorrectly can compromise the 
> security of the local network.

Definitely watch out for that.  The defaults are pretty safe, but 
you could accidentally create a back door into either your 
corporate network or your home network.  You should specifically 
make sure your workstation is not forwarding packets -- the two 
networks should stay separate.  Otherwise, your Windows box at 
home could get compromised and launch attacks on the internal 
servers at work.  So, make sure your workstation is not a router.


Hopefully this helps explain some of the details.


-- Scott



More information about the NCLUG mailing list