Binary upgrade of mozilla-thunderbird fails on OpenBSD 4.1
Suspected line reads: Checking for collisions with .libs-mozilla-thunderbird-1.5.0.10... some found Could anyone explain what to do next ? Thanks! Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com # pkg_add -uivvv mozilla-thunderbird Candidates for updating mozilla-thunderbird-1.5.0.9p1 - mozilla-thunderbird-1.5.0.9p1 mozilla-thunderbird-1.5.0.10 Ambiguous: choose package for mozilla-thunderbird-1.5.0.9p1 0: None 1: mozilla-thunderbird-1.5.0.10 2: mozilla-thunderbird-1.5.0.9p1 Your choice: 1 No need to update jpeg-6bp3 No need to update hicolor-icon-theme-0.9 No need to update glib2-2.10.3p0 No need to update png-1.2.14p0 No need to update cairo-1.2.6p0 No need to update expat-2.0.0 No need to update gettext-0.14.6 No need to update nspr-4.6.5p0 No need to update tiff-3.8.2p0 No need to update libiconv-1.9.2p3 No need to update libaudiofile-0.2.6p0 No need to update esound-0.2.34p0 No need to update glitz-0.5.6 No need to update atk-1.10.3p2 No need to update gtk+2-2.8.20p4 No need to update pango-1.12.3p0 Running the equivalent of pkg_add -r mozilla-thunderbird-1.5.0.10 parsing mozilla-thunderbird-1.5.0.10 New package mozilla-thunderbird-1.5.0.10 contains potentially unsafe operations @exec rm -rf /tmp/.mozilla @exec cd /usr/local/mozilla-thunderbird env HOME=/tmp LD_LIBRARY_PATH=/usr/local/mozilla-thunderbird ./regxpcom @exec rm -rf /tmp/.mozilla proceed with update anyways? [y/N/a] y Checking for collisions with .libs-mozilla-thunderbird-1.5p2... none found Checking for collisions with .libs-mozilla-thunderbird-1.5.0.8... none found Checking for collisions with .libs-mozilla-thunderbird-1.5.0.10... some found Checking for collisions with .libs-mozilla-thunderbird-1.5.0.7... none found Checking for collisions with .libs-mozilla-thunderbird-1.5.0.2... none found Can't update to mozilla-thunderbird-1.5.0.10 because of collision with old libs /usr/sbin/pkg_add: mozilla-thunderbird-1.5.0.10:Fatal error
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
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
--- 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
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
--- 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
