Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
On Friday 28 July 2006 21:49, Stuart Henderson wrote: simple end-user install on the Windows side I'd have to disagree with this. OpenVPN on Windows isn't nearly as end-user friendly and easy to install as, say, TheGreenbow IPSec client. you can bridge an ethernet to a remote Windows box (helps with some MS protocols) Hmm...is this why I can't get SMB workgroup browsing to work using IPSec? Even if you have WINS server? per-user authentication (rather than per-host) If you use certificates isakmpd does per-user authentication. The downside is that getting certificates to work isn't exactly a walk in the park. --- Lars Hansson
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
On Tue, Aug 01, 2006 at 03:26:46PM +0800, Lars Hansson wrote: On Friday 28 July 2006 21:49, Stuart Henderson wrote: simple end-user install on the Windows side I'd have to disagree with this. OpenVPN on Windows isn't nearly as end-user friendly and easy to install as, say, TheGreenbow IPSec client. you can bridge an ethernet to a remote Windows box (helps with some MS protocols) Hmm...is this why I can't get SMB workgroup browsing to work using IPSec? Even if you have WINS server? From my understanding - which is limited by my dislike of anything Microsoft, and SMB in particular[1] - it should work with a WINS server. Of course, NETBIOS is out, but SMB over TCP/IP (i.e., a couple of TCP and UDP ports, to muddle the terms further), should work. per-user authentication (rather than per-host) If you use certificates isakmpd does per-user authentication. The downside is that getting certificates to work isn't exactly a walk in the park. It shouldn't be *that* difficult, though, and doesn't look like it from a quick look. I never needed to get this to work, though, and consequently haven't tried it. Joachim [1] Then again, NFS sucks too. I have yet to encounter a network fs that doesn't suck. And no, AFS isn't a POSIX filesystem, and I'm pretty sure it sucks in other ways as well. NFSv4 looks like it might suck quite a bit less than v3, in particular, the ability to use a firewall is valuable.
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
Hmm...is this why I can't get SMB workgroup browsing to work using IPSec? Even if you have WINS server? WINS is for name resolution, workgroup browsing is something different.
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
On Sat, Jul 29, 2006 at 12:22:42PM -0700, jeraklo wrote: After summarizing all the clues I think I'll give a chance to OpenVPN + OpenBSD 3.9 combination primarily due to questionable quality of windows clients IPsec+IP stack (as I said in my first post - windows clients will comprise about 99% of all my VPN client base). The differentiation between OS (OpenBSD) and the service (OpenVPN package) will be clearly stated to the upper management, including OpenBSD's proactive- and overall security reputation. If you believe this'll work, be sure to make the difference clear. OpenVPN has some very nice security features, but seems to have more security bugs than would be considered reasonable in an OpenBSD application. Joachim
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
After summarizing all the clues I think I'll give a chance to OpenVPN + OpenBSD 3.9 combination primarily due to questionable quality of windows clients IPsec+IP stack (as I said in my first post - windows clients will comprise about 99% of all my VPN client base). The differentiation between OS (OpenBSD) and the service (OpenVPN package) will be clearly stated to the upper management, including OpenBSD's proactive- and overall security reputation. Also, as this VPN service will be added to our existing service monitoring framework, and as the great majority of clients will be our own system administrators (VPN will be used for remote access in the case of interventions), this combination should probably suffice. The VPN service will not be sold to external clients. Thanks to everyone for valuable opinions and comments! j. Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
VPN help needed: OpenBSD in the corporate environment instead of Linux
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), - VPN solution must be unique (i.e. using the same protocol regardless of the client type). - 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. 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. The scenario layout would then look like this (in this case, note the lack of both the second firewall and the second NIC on VPN server): 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_0 (public IP, subnet_C) | | NIC_0 (public IP, subnet_C == DESTINATION SUBNET) VPN_SERVER (OpenBSD) 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. Thank you, Jeraklo -- Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
On 28 jul 2006, at 11.19, jeraklo wrote: ... 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) This looks like a rather archaic layout, dating from when firewalls had just an inside and an outside interface. Fortunately those days are long over and all modern firewalls support multiple interfaces. This design has the drawback of all traffic needing to pass through three nodes (a.k.a single points of failure) with all that entails, plus some extra administration with two firewalls. You probably want either Internet --- Firewall --- 'destination subnet' | VPNServer or (although this may fail for political reasons :): Internet --- Firewall/VPNServer --- 'destination subnet' 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. The scenario layout would then look like this (in this case, note the lack of both the second firewall and the second NIC on VPN server): You do not want this, and not just for administrative reasons. :) The most obvious arguments why are perhaps a VPN configuration bug could make your 'destination subnet' more open than intended, and you definitely have to trust the clients not to send bad traffic. The firewall is completely blind here... To set this up, it's recommended you be fairly familiar with how IP routing works, then read some of the PF- and IPsec-related manual pages (pf.conf, ipsecctl etc al) plus examples, and you should be set to go. /H
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
On 28 jul 2006, at 14.09, jeraklo wrote: So, you are saying that pf(4), ipsec(4), ipsecctl(8), and maybe vpn(8) is all I need ? Do I have to make That's a good start, yes. Plus it should be fairly easy to find configuration examples for setups like this. some special tweakings on the windows client machines in order to run the VPN, or is ti just a matter of some default configuration ? There is an IPsec implementation in Windows, but configuring it is something else again. It's been a few years since I experimented with it last, but it was no fun then, at all. If you search for it, you'll probably find some references on how to set it up on the net. I figure most people using IPSec on Windows end up using some kind of IPSec client software... /H
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
On Fri, Jul 28, 2006 at 02:28:44PM +0200, H?kan Olsson wrote: On 28 jul 2006, at 14.09, jeraklo wrote: So, you are saying that pf(4), ipsec(4), ipsecctl(8), and maybe vpn(8) is all I need ? Do I have to make That's a good start, yes. Plus it should be fairly easy to find configuration examples for setups like this. some special tweakings on the windows client machines in order to run the VPN, or is ti just a matter of some default configuration ? There is an IPsec implementation in Windows, but configuring it is something else again. It's been a few years since I experimented with it last, but it was no fun then, at all. If you search for it, you'll probably find some references on how to set it up on the net. I figure most people using IPSec on Windows end up using some kind of IPSec client software... It's horribly broken. L2TP (layer 2 tunneling protocol) is a mandatory part of the protocol, and while it does have some uses, none of them are particularly likely to be of interest (contemplate the idiocity of IP-over-L2TP-over-IPsec-over-IP, and you'll understand that just because you can doesn't mean you should). Joachim
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
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
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
Original message Date: Fri, 28 Jul 2006 14:28:44 +0200 From: Hekan Olsson [EMAIL PROTECTED] Subject: Re: VPN help needed: OpenBSD in the corporate environment instead of Linux To: jeraklo [EMAIL PROTECTED] Cc: misc@openbsd.org On 28 jul 2006, at 14.09, jeraklo wrote: So, you are saying that pf(4), ipsec(4), ipsecctl(8), and maybe vpn(8) is all I need ? Do I have to make That's a good start, yes. Plus it should be fairly easy to find configuration examples for setups like this. some special tweakings on the windows client machines in order to run the VPN, or is ti just a matter of some default configuration ? There is an IPsec implementation in Windows, but configuring it is something else again. It's been a few years since I experimented with it last, but it was no fun then, at all. If you search for it, you'll probably find some references on how to set it up on the net. I figure most people using IPSec on Windows end up using some kind of IPSec client software... if you search the archives, there are a number of threads discussing windows xp interoperating with openbsd's isakmpd. using ipseccmd.exe on winxp is one option, it's in the archives. a problem i've noted with ipseccmd.exe is that the connection doesn't show up in winxp's routing table and can be annoying to firewall, assuming you're using windows for firewalling. a recent post on how to do this using ipsec.conf that i haven't yet had opportunity to try out myself is: http://marc.theaimsgroup.com/?l=openbsd-miscm=115217425632214w=2 i'm not sure about the status of road warrior support (e.g. feral kid with metal boomerang) for ipsec.conf rules, hakan would likely know what's up with that. cheers, jake /H
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
I just wanted to simplify the layout (it seems at the end it went more complex, sorry), but two firewalls are actually PIX firewall with several interfaces. So, you are saying that pf(4), ipsec(4), ipsecctl(8), and maybe vpn(8) is all I need ? Do I have to make some special tweakings on the windows client machines in order to run the VPN, or is ti just a matter of some default configuration ? --- Ho?=kan Olsson [EMAIL PROTECTED] wrote: On 28 jul 2006, at 11.19, jeraklo wrote: ... 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) This looks like a rather archaic layout, dating from when firewalls had just an inside and an outside interface. Fortunately those days are long over and all modern firewalls support multiple interfaces. This design has the drawback of all traffic needing to pass through three nodes (a.k.a single points of failure) with all that entails, plus some extra administration with two firewalls. You probably want either Internet --- Firewall --- 'destination subnet' | VPNServer or (although this may fail for political reasons :): Internet --- Firewall/VPNServer --- 'destination subnet' 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. The scenario layout would then look like this (in this case, note the lack of both the second firewall and the second NIC on VPN server): You do not want this, and not just for administrative reasons. :) The most obvious arguments why are perhaps a VPN configuration bug could make your 'destination subnet' more open than intended, and you definitely have to trust the clients not to send bad traffic. The firewall is completely blind here... To set this up, it's recommended you be fairly familiar with how IP routing works, then read some of the PF- and IPsec-related manual pages (pf.conf, ipsecctl etc al) plus examples, and you should be set to go. /H Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
On Jul 28, 2006, at 8:09 AM, jeraklo wrote: I just wanted to simplify the layout (it seems at the end it went more complex, sorry), but two firewalls are actually PIX firewall with several interfaces. So, you are saying that pf(4), ipsec(4), ipsecctl(8), and maybe vpn(8) is all I need ? Do I have to make some special tweakings on the windows client machines in order to run the VPN, or is ti just a matter of some default configuration ? Not to interject here, but your chances for success are directly proportional to your understanding of TCP/IP and IPsec. It sounds as though you are not terribly experienced with either. That's not to say you can't make this happen, but I would strongly suggest you reproduce your proposed design in a test lab (probably at home). Everything you need is in the base install. With the recent changes to ipsecctl and ipsec.conf, there's no need to consider OpenVPN (except perhaps on technical merits, which I believe it loses on). Once you've started testing your network and run into problems, definitely come back and we'll be happy to help. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
--- Joachim Schipper [EMAIL PROTECTED] wrote: There is something in the archives about usable IPsec clients for Windows. The built-in one certainly isn't. ok. good to know. 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.) sorry. got to go with the stable branch (3.9). 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, actually, client connects to a public network and doesn't overlaps with destinatio subnet (C), and I want its VPN interface to put the client as close as possible to destination subnet (C). Putting the client's VPN interface directly to destination subnet (C) would be the most preffered solution. however, since you mentioned 'public subnet', it might be using public IPs, in which case this won't be a problem. 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. OK but do OpenVPN connections survive NAT ? It is possible for some client addresses to be private and then translated through NAT to reach the internet. Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
On Fri, 28 Jul 2006 06:30:13 -0700 (PDT) jeraklo [EMAIL PROTECTED] wrote: 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. OK but do OpenVPN connections survive NAT ? It is possible for some client addresses to be private and then translated through NAT to reach the internet. OpenVPN is an SSL VPN and should have no problems traversing NAT. I used it at a former employer and it work great for my laptop. Tim Donahue
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
On 2006/07/28 06:30, jeraklo wrote: sorry. got to go with the stable branch (3.9). ipsec.conf(5) was added for 3.8, and improved between then and -current. isakmpd.conf(5) is no longer present in -current, so it makes sense to use ipsec.conf(5) right away. OK but do OpenVPN connections survive NAT ? Yes, there are some advantages over isakmp/ipsec:- simple end-user install on the Windows side compression works well you can bridge an ethernet to a remote Windows box (helps with some MS protocols) per-user authentication (rather than per-host) (some of these are handled by MS' l2tp(ppp)-ipsec hybrid but not by standard ipsec). disadvantages:- openvpn is more complicated to install on OpenBSD than ipsec lots of security fixes
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
The proposed design will definitely be initially tested in a lab. Not to worry about that part. The major problem I have seen by now is that IPsec have problems with NAT, while OpenVPN doesn't (but it adds to latency - it is not a major concern in the desired setup). I would like to briefly mention the setup again: some clients will get private IP addresses at their access network (theoretically, it could be anywhere in the world), and then immediatelly NAT-ed to some gateway's public IP pool, in order to access the outside world. Packets from this public IP pool will reach the VPN server and the VPN end should there be terminated. As I know, it is not possible to setup this situation using IPsec without using some additional magic. Opinions would be appreciated. Thanks, j. --- Jason Dixon [EMAIL PROTECTED] wrote: On Jul 28, 2006, at 8:09 AM, jeraklo wrote: I just wanted to simplify the layout (it seems at the end it went more complex, sorry), but two firewalls are actually PIX firewall with several interfaces. So, you are saying that pf(4), ipsec(4), ipsecctl(8), and maybe vpn(8) is all I need ? Do I have to make some special tweakings on the windows client machines in order to run the VPN, or is ti just a matter of some default configuration ? Not to interject here, but your chances for success are directly proportional to your understanding of TCP/IP and IPsec. It sounds as though you are not terribly experienced with either. That's not to say you can't make this happen, but I would strongly suggest you reproduce your proposed design in a test lab (probably at home). Everything you need is in the base install. With the recent changes to ipsecctl and ipsec.conf, there's no need to consider OpenVPN (except perhaps on technical merits, which I believe it loses on). Once you've started testing your network and run into problems, definitely come back and we'll be happy to help. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
On Fri, Jul 28, 2006 at 06:30:13AM -0700, jeraklo wrote: --- Joachim Schipper [EMAIL PROTECTED] wrote: 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, actually, client connects to a public network and doesn't overlaps with destinatio subnet (C), and I want its VPN interface to put the client as close as possible to destination subnet (C). Putting the client's VPN interface directly to destination subnet (C) would be the most preffered solution. That's not difficult with IPsec, just tell the clients to route traffic to C over the tunnel. The problem happens when a client is connected to your VPN and a seperate network with the same numbering as subnet C. misc@ is littered with threads that combine 'IPsec' and 'NAT' in the title; this setup, while not impossible, is fraught with difficulties and gotchas. Don't do it unless absolutely necessary. Most other VPN solutions have this same problem, BTW. however, since you mentioned 'public subnet', it might be using public IPs, in which case this won't be a problem. 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. OK but do OpenVPN connections survive NAT ? It is possible for some client addresses to be private and then translated through NAT to reach the internet. Both OpenVPN and IPsec work fine over NAT. However, OpenVPN is more likely to work over broken[1] routers, IME. Joachim [1] They work fine as residential NAT routers, as long as you don't do anything other than TCP, UDP, and some ICMP, and nothing outside of usual traffic patterns. Anything else causes much more interesting behaviour. I encountered one with rather interesting MTU handling, for instance. I'm still sure there was a solution, but the brokenness of WinXP's IPsec implementation combined with the suckiness of this router was enough for me to go look for something less painful to do. Of course, a decent WinXP client might have made things easier; and the server was an old version of KAME's racoon on Linux.
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
On Fri, Jul 28, 2006 at 07:09:17AM -0700, jeraklo wrote: The proposed design will definitely be initially tested in a lab. Not to worry about that part. The major problem I have seen by now is that IPsec have problems with NAT, while OpenVPN doesn't (but it adds to latency - it is not a major concern in the desired setup). I would like to briefly mention the setup again: some clients will get private IP addresses at their access network (theoretically, it could be anywhere in the world), and then immediatelly NAT-ed to some gateway's public IP pool, in order to access the outside world. Packets from this public IP pool will reach the VPN server and the VPN end should there be terminated. As I know, it is not possible to setup this situation using IPsec without using some additional magic. Opinions would be appreciated. This is quite possible, but my caveat that clients should not be attached to a subnet with the same IP numbering as your subnet C still applies. However, this is also true for OpenVPN, and most any other VPN. You *will* require the 'access network' to pass ESP, 500/UDP (IKE), and 4500/UDP (IPsec NAT-T), of course. Joachim
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
--- Joachim Schipper [EMAIL PROTECTED] wrote: On Fri, Jul 28, 2006 at 07:09:17AM -0700, jeraklo wrote: The proposed design will definitely be initially tested in a lab. Not to worry about that part. The major problem I have seen by now is that IPsec have problems with NAT, while OpenVPN doesn't (but it adds to latency - it is not a major concern in the desired setup). I would like to briefly mention the setup again: some clients will get private IP addresses at their access network (theoretically, it could be anywhere in the world), and then immediatelly NAT-ed to some gateway's public IP pool, in order to access the outside world. Packets from this public IP pool will reach the VPN server and the VPN end should there be terminated. As I know, it is not possible to setup this situation using IPsec without using some additional magic. Opinions would be appreciated. This is quite possible, but my caveat that clients should not be attached to a subnet with the same IP numbering as your subnet C still applies. Not to worry about that either. In the desired setup clients will never be attached to a subnet with the same IP numbering as the destination network (e.g. subnet C in the diagram). However, this is also true for OpenVPN, and most any other VPN. You *will* require the 'access network' to pass ESP, 500/UDP (IKE), and 4500/UDP (IPsec NAT-T), of course. Regarding NAT-T, does it have to be enabled both in clients and the VPN server ? If yes and if we're talking about windows clients - does it come bundled with some external IPsec client or does it have to be enabled in the windows itself ? (yes I know I can possibly find this info on the internet, but if you already know ...). Thanks, j. Joachim Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
From: [EMAIL PROTECTED] You *will* require the 'access network' to pass ESP, 500/UDP (IKE), and 4500/UDP (IPsec NAT-T), of course. Regarding NAT-T, does it have to be enabled both in clients and the VPN server ? If yes and if we're talking about windows clients - does it come bundled with some external IPsec client or does it have to be enabled in the windows itself ? (yes I know I can possibly find this info on the internet, but if you already know ...). Windows' native IPsec capabilities leave a lot to be desired. Like Cisco, they've landed on L2TP + IPsec and make too many assumptions in their implementation, IMHO. It can be made to work, by some bending of the Gods' will, but I have never had the patience to go that far with it. I'd say you'll have better luck on Windows using a more standard client implementation such as TheGreenBow or similar. http://www.allard.nu/openbsd/ has some information along these lines. That said, IPsec is an overengineered terror compared to some other tunneling solutions, such as OpenVPN or OpenSSH's tunnel support. For my simple home use, road warrior configuration I tinkered with a Windows system and IPsec for a couple of days and broke down and went OpenVPN. YMMV. DS
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
Jason == Jason Dixon [EMAIL PROTECTED] writes: Jason Everything you need is in the base install. With the recent changes to Jason ipsecctl and ipsec.conf, there's no need to consider OpenVPN (except perhaps Jason on technical merits, which I believe it loses on). Maybe not on getting it set up, but there are definitely some problems with ipsec that make OpenVPN a winner for some circumstances, such as NAT traversal and hostile-to-v6 routers and ISPs. Unless something has happened with ipsec/ipv6 in general recently that I'm not aware of. If so, please share. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
On Jul 28, 2006, at 2:17 PM, Randal L. Schwartz wrote: Jason == Jason Dixon [EMAIL PROTECTED] writes: Jason Everything you need is in the base install. With the recent changes to Jason ipsecctl and ipsec.conf, there's no need to consider OpenVPN (except perhaps Jason on technical merits, which I believe it loses on). Maybe not on getting it set up, but there are definitely some problems with ipsec that make OpenVPN a winner for some circumstances, such as NAT traversal and hostile-to-v6 routers and ISPs. Unless something has happened with ipsec/ipv6 in general recently that I'm not aware of. If so, please share. Unless you're aware of some unpublished issues with OpenBSD's NAT-T support, it should work fine for his scenario. Full NAT-T support has been in for quite some time now (~3.6). Hakan, please feel free to correct me if I'm mistaken. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
Stuart Henderson wrote: On 2006/07/28 06:30, jeraklo wrote: sorry. got to go with the stable branch (3.9). disadvantages:- openvpn is more complicated to install on OpenBSD than ipsec lots of security fixes Not on the client side, I think you'll find OpenVPN much easier to configure as well. OpenVPN is trivially easy to install using the packages on OBSD. OpenVPN also can help get around some restrictive firewalls by letting you pick the UDP or TCP port you wish to run it on. -Steve S.
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
On 2006/07/28 15:57, Steven Surdock wrote: openvpn is more complicated to install on OpenBSD than ipsec Not on the client side, I think you'll find OpenVPN much easier to configure as well. OpenVPN is trivially easy to install using the packages on OBSD. I do use both so I realise that OpenVPN is easy, but ipsec.conf is just as easy (easier, in the case of public-key) and doesn't need you to touch anything out of base OS. If it were the case on other OS, there would be little need for OpenVPN... OpenVPN also can help get around some restrictive firewalls by letting you pick the UDP or TCP port you wish to run it on. Unless I'm mistaken, see isakmpd(8), option -N.
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
On Fri, Jul 28, 2006 at 09:29:59AM -0700, jeraklo wrote: Regarding NAT-T, does it have to be enabled both in clients and the VPN server ? If yes and if we're talking about windows clients - does it come bundled with some external IPsec client or does it have to be enabled in the windows itself ? (yes I know I can possibly find this info on the internet, but if you already know ...). Yes, both sides must support NAT-T for it to work. AFAIK, most competent clients have this; even the built-in Windows client tries to do it [1]. Joachim [1] Though, in the case I described, it failed miserably. Probably the IP implementation failed, and not IPsec proper, but still...
Re: VPN help needed: OpenBSD in the corporate environment instead of Linux
On Fri, Jul 28, 2006 at 03:57:02PM -0400, Steven Surdock wrote: Stuart Henderson wrote: On 2006/07/28 06:30, jeraklo wrote: sorry. got to go with the stable branch (3.9). disadvantages:- openvpn is more complicated to install on OpenBSD than ipsec lots of security fixes Not on the client side, I think you'll find OpenVPN much easier to configure as well. OpenVPN is trivially easy to install using the packages on OBSD. easier than this? # cat /etc/ipsec.conf ike dynamic from egress to my.gate.net # ls /etc/isakmpd/pubkeys/fqdn/ my.gate.net # cat /etc/rc.conf.local ... ipsec=YES isakmpd_flags=-K
