As an easier alternative to ipsec vpn's, trumpet the arrival of SSH's new "-w" option.

With openBSD(4.2) and openSSH(4.3+), there's a "-w" option, and with it an ip forwarding feature. Classically, ssh(8) is a port forwarder. Not so classically, the "-w" feature is an IP forwarder. The IP can be point to point or point to subnet(s), or subnet(s) to subnet(s) and, thusly, its applicability and efficacy as a [truer] VPN.

Client side is as follows.

(N.B.: My sshd-as-a-vpn listens on port 443, not 22, to allow the client to traverse any intermediate firewalls that may block certain ports.)

I use this for road warrior client-to-gateway vpn, not site to site; and

Nothing stopping you your uses, though.

The challenge may be scaling, as you need a tun[0,...,n] interface for each concurrent connection on the gateway machine. This isn't a problem for my use, as three concurrent sessions is the upper need limit.

The feature of ssh -w (for me) is that,

the needed wares are already on every box I operate, therefore, nothing extra to install or maintain;

I use ssh already;

configuring the vpn tunnel is a whole heck of a lot easier then ipsec; and

so far, I can easily pass through tight firewalls and nat setups that are not under my control.

/S

__________________Never argue with an idiot. They will bring you down to their level and beat you with experience.

Awesome feature! So just to clarify once I'm in a public hotspot I can ssh -w into my OBSD firewall assuming it has the proper firewall rules. Once I'm connected I can surf the net like I was connected at home?

Awesome feature! So just to clarify once I'm in a public hotspot I can ssh -w into my OBSD firewall assuming it has the proper firewall rules. Once I'm connected I can surf the net like I was connected at home?

Yep.

But the -w just -- and I mean j-u-s-t -- brings up the ssh encrypted tunnel. How you use the tunnel depends on what you do next. On the CLIENT side...

Code:

ifconfig tun0 10.3.0.2 255.255.255.252 10.3.0.1,
where .2 is the client and .1 is the gateway tunnel endpoint.

Where (1) you MUST preserve the route to your gw machine via the hotspot dhcp-obtained gateway ip, (2) route crypto to your work/home subnet; and (3) route crypto to the gateway and then off the gateway to the world.

These route commands can be scripted easily and may be built into the hostname.tun0 with the "!" prefix.

__________________Never argue with an idiot. They will bring you down to their level and beat you with experience.

I'm dredging up this old thread to ask a clarifying question: what happens when your laptop is on the same RFC1918 subnet as the private LAN you're attempting to route to?

e.g.: In your example, s2scott, the destination subnet is 192.168.2/24. But ... what happens if where you're connecting from is in the same or an overlapping subnet? e.g.: connecting from 192.168.2.221? or 192.168.50.100 when the netmask is 255.255.0.0?

I ask because I happened to see the IPSec/NAT article just pubbed in the Journal, and thought about address collisions with NAT. Would NAT via the tun(4) device be a possible play?

Having experimented, I have determined it is possible to avoid RFC1918 collisions or interference with any other IPv4 address: Use IPv6 addressing on the tun device instead of IPv4. But unless you also set up a gif(4) tunnel for IPv4, NAT is the only way to ensure no routing problems.

Having played with tunneling ipv4 over ipv6 with gif; I find it easier to set up IPSec.

Having experimented, I have determined it is possible to avoid RFC1918 collisions or interference with any other IPv4 address: Use IPv6 addressing on the tun device instead of IPv4. But unless you also set up a gif(4) tunnel for IPv4, NAT is the only way to ensure no routing problems.

Having played with tunneling ipv4 over ipv6 with gif; I find it easier to set up IPSec.

I hate "howtos" -- even if I use them as a learning tool, myself. But ok, I will find some time to sit down with four virtual machines and run this again (since I'd promptly forgotten what I did, once I did it). I'll take notes.

As I'd stated above, IPSec is easier because one doesn't need to deal with a virtual subnet on the tunnel itself, as we do with SSH. When I tested this, I just used NAT on tun0 -- but this more robust solution, below, is a possibility. I may use BINAT and NAT in combination, if I determine it makes a simpler solution.

I'll be testing this and coming up with sample scripts and config files this week, but I thought I would publish an initial architecture beforehand... just in case I've missed something obvious. And it's easy to miss something; there are six virtual IP subnets in the solution.