On Fri, Jul 28, 2006 at 02:19:46AM -0700, jeraklo wrote:
> Hi there,
>
> for the first time during my employment I have the
> opportunity to introduce OpenBSD into a production of
> the corporate environment as an VPN concentrator i.e.
> remote access server. The problem is, all folks here
> are very Linux biased and introducing OpenBSD for such
> an important task is looked at using ultra-magnifying
> glasses meaning any failures will not be tolerated at
> all, but if OpenBSD proves to be worth its job it will
> be considered approved for use even in future services
> as well. So, this is the one-time chance I wouldn't
> like to miss. :)
>
> I never before worked with VPN deployment, but now
> think of using IPsec since it is an open standard and
> it is implemented in OpenBSD.
>
> The VPN scenario looks to me pretty default and
> straightforward:
>
> - client machines will be connecting to VPN server
> anywhere from the internet using several OS flavors
> (99% winbloze laptops, 1% winCE PDA + linux laptops),
>
> - VPN software on client machines must be freely
> obtainable (preferably bundled with OS itself),
There is something in the archives about usable IPsec clients for
Windows. The built-in one certainly isn't.
> - VPN solution must be unique (i.e. using the same
> protocol regardless of the client type).
Should be doable with IPsec, though some Windows solutions might use
3DES; I'd strongly urge you to consider offering AES for those clients
that support it, as its quite a bit faster.
> - VPN server must be relatively easy to administer and
> configure, and it must have local firewall (pf) which
> can filter VPN traffic and tunneled traffic as well.
Done.
> The network layout looks like following:
>
> CLIENT (can have public IP or private IP)
> | (private client IP assumes default gateway uses NAT)
> |
> |
> INTERNET
> |
> |
> NIC_0_FIREWALL_0 (public IP)
> FIREWALL_0
> NIC_1_FIREWALL_1 (public IP, subnet_A)
> |
> |
> NIC_0 (public IP, subnet_A)
> VPN_SERVER (OpenBSD)
> NIC_1 (public IP, subnet_B)
> |
> |
> NIC_0_FIREWALL_1 (public IP, subnet_B)
> FIREWALL_1
> NIC_1_FIREWALL_1 (public IP, subnet_C)
> |
> |
> DESTINATION SUBNET (public IP network, subnet_C)
>
> The goal would be for client to reach destination
> subnet (subnet_C) using VPN.
>
> It is not possible for VPN server to reside directly
> into destination subnet (subnet_C) because of
> administrative reasons, but if you give me a _very_
> good reason to do so, maybe it could be arranged.
> As you can see, there is almost none use of any
> address translation (except when client connects to
> some provider which uses private adressess for
> access).
> Also firewalls don't perform any address translation
> either, they just permit/deny traffic and route it.
> Neither firewall is aware of any VPN traffic.
>
> So please, could anyone help and provide me with the
> needed guidelines to accomplish this scenario ? As I
> said before, success of this VPN scenario definitely
> would be a very good advocacy for OpenBSD.
This shouldn't be too difficult. Start by installing -current, which has
a very neat new configuration interface - ipsec.conf(5). (Of course,
you also get the newest and most shiny bugs.)
Then, configure firewall 0 to pass ESP traffic (or AH, if authentication
is desired but encryption is not required), plus UDP port 500 and 4500,
to the VPN box. The only real problem you are going to run into is if
subnet C overlaps with a network the client is already connected to,
however, since you mentioned 'public subnet', it might be using public
IPs, in which case this won't be a problem.
Of course, there are likely some gotchas, most likely in interoperating
with various devices. Be sure to do some proper testing before
deployment. However, OpenBSD is known to interoperate with both Linux
and Windows solutions, so it should work.
(This is not OpenBSD specific; IPsec is a very complex protocol, with a
lot of questionable implementations.)
Alternately, for a more shiny, more firewall-friendly, but less
efficient protocol and not quite as secure an implemenation, try
OpenVPN. It runs on Windows, Mac OS X, and (most?) POSIX-compliant
systems that have tap/tun devices.
Joachim
