Contributed by jose on from the testing-patchwork dept.
Finally a single BSD box can act as a VPN gateway for more than one computer on the internet/LAN. This is perfect for accessing data on remote production servers over samba tunneled from the loopback addr.
Could this be a good future feature for OpenSSH?
Our little report and OpenBSD patch along with some ssh tunneling help for da noobies (like myself) is here: http://research.vovoid.com
Enjoy :)
/The furries at Vovoid Software & Multimedia" Looks interesting. Obviously this is an unofficial patch, but if you're feeling like testing something out this may be useful to you.
(Comments are closed)
By Anonymous Coward () on
Comments
By jonatan wallmander () jonatan@vovoid.com on http://www.vovoid.com
Comments
By blkwolf () on http://blkwolf.dyn.ca
By nickf3 () on
By Charles Hill () charles.e.hill@attbi.com on mailto:charles.e.hill@attbi.com
The big issue that keeps popping up is that SSH is TCP only, and won't truely tunnel UDP. You then end up with TCP over TCP which has generated a lot of heat in the arguments. Extra TCP ACKs, and TCP retransmission are the likely culprits.
SSH thru NAT is a real pain, whereas IPSec has an actual IETF drafts covering it. And it works -- I've done it on a daily basis with different vendors hardware/software.
SSH doesn't really have any sort of key exchange mechanism like IKE for IPSec.
Whiles adding the ability to specify the port used will be great -- don't let it fool you into thinking SSH is a full-blown VPN. That wasn't what it was designed for.
Comments
By mra () on
I cross NAT boundaries all the time with SSH. The only issue I've ever run into is that the NAT be setup to send SSH to the right place. This is hardly SSHs fault, it is a configuration issue with NAT.
I certainly agree with you that SSH isn't, and shouldn't be, a VPN, but blaming SSH for an issue that is intrinsically part of NAT seems misplaced.
As for key exchange there are some mechanisms being drafted in the IETF right now to help with that. Granted they are storing the host keys in DNS, and this gets into other issues, but it should further reduce the threat from MitM attacks. Personally I find that using user based public/private keypairs is the best way around this issue. If you get a password prompt instead of the pubkey you were expecting you know something is not right.
By grey () on
Meanwhile, dealing with particular vendor NAT and IPSec implementations I continually run into [just to pull some names that steal my time when I need to walk a user through setting up a VPN connection how about: Checkpoint VPN-1 paired with Windows SecuRemote paired with a Linksys home DSL 'router' doing braindead NAT - and trying to explain to Joe Consumer User how to turn on port forwarding on their "router's" web GUI isn't as straight forward as it should be either]. And that's even when things are set up to only use ESP (are there IETF drafts for AH + NAT traversal? I haven't paid attention in a while). The VPN industry is having a field day with new products touting "NAT traversal" because most vendors didn't get it right the first time around.
Keep in mind, the VPN world is -primarily- [not exclusively] oriented at windows users as well. There aren't many unix applications that can't be run from a terminal as provided by ssh.
And, really IPSec is complete overkill for a lot of things. In this case, if you only want to do port forwarding - building a whole tunnel, dealing with policies and so on is a waste, the default use of ssh already allows for a simple solution to tunnelling just smb, and this paper merely builds upon that slightly.
IPSec still has its place, and should really be used more widely. But, just because IPSec makes more sense for some things doesn't mean that it should always be used. Case in point, for say 802.11 IPSec is a perfect fit but instead we have EAP and LEAP and now WPA to replace WEP. But that doesn't mean that it's always a good fit. There are many applications for which ssh or stunnel and the like are more than sufficient.
A bigger problem to bitch about (vs say using ssh or IPSec) is that vendors should be picking the right tool to use as an encryption layer from the get go, and making it mandatory and thus transparent. Instead we get protocol after protocol which just didn't even think about security. And then, when the finally do, they tend to reinvent the wheel instead of making use of what is already out there. I'd bitch to no end on things like that. The less time I need to waste as an admin setting up and configuring individual clients, or talking users through problems which they don't even understand the better; the VPN industry still has a long way to go there. Meanwhile for _certain_ things, ssh (and by extension scp) is just transparent to the user, it's just another application they run, security is more or less accounted for, and there are no gotchas.
Sorry, I did get off into that bitch a little bit longer than expected. Vendors should be tunnelling things to begin with (I think I've seen a VNC release out there which automatically tunnels with ssh), making it optional in a non-default behaviour. (I'll shut up now)
Comments
By andy () on
"
EAP-TLS is a pain in the ass to work with an openbsd server with freeradius and he just support XP and windows 2k is not so easy with xsuplicant for BSD and linux.
wpa is just not widely deployed.
security on 802.11b ...not an easy job to support connection and security for the masses
By djm () on
> exchange mechanism like IKE for IPSec
Actually, it does.
By markus () markus@openbsd.org on mailto:markus@openbsd.org
-L laddr:lport:raddr:rport,
http://bugzilla.mindrot.org/show_bug.cgi?id=413
and perhaps other protocols.