Re: snapshot always actual releases?
could some one please explain what is means that snapshots are *always* actually releases? In /usr/src/etc/Makefile, there used to be two targets to create tarballs to share a system with someone else: - make snapshot, which would create rough tarballs of various filesystem locations (bin.tar.gz, sbin.tar.gz, usr.bin.tar.gz, etc) - make release, which would create the installation media and the thematic tarballs everyone is used to use (base.tgz, comp.tgz, etc). What is published as OpenBSD snapshots is always the result of ``make release'', which is no different than the way actual releases are built. Hence the removal of the ``make snapshot'' part, and the comments that our snapshots are (obtained with make) release. Miod
Re: cat -v
On Thu, 27 Jul 2006, Nick Guenther wrote: Why does cat retain the -[etv], -[bn] and -[s] options? I am reading the paper cited in cat's manpage and saw 'vis' mentioned. vis is in base, and line numbering and stripping can be done with sed, so why does cat have those options? Is for history, just for compatibility, or has no one ever bothered to remove them (I find this unlikely)? Once you've added a flag to a command it's almost impossible to remove it for compatibility reasons. -Otto
Problems with PCMCIA cards
I am a new user having just installed OpenBSD for the first time. I am having trouble with my PCMCIA cards. I have 2 cards, both 3COM, and two PCMCIA slots (TI-PCI1130, see dmesg below). I am currently having two issues: system hangs in bios after reboot and kernel panics when pcmcia card is removed. I am willing to open up 1 or more bug reports if these cannot be easily resolved, but since my last problem involved using floppyB to boot the system instead of floppyC, I wanted to make sure this was a real issue instead of a new user doesn't know what he is doing issue. Both problems are easily reproducable, so I can easily gather more information. Details: Issue 1: My system always boots fine from a powered down state, but hangs in the bios after a reboot (type reboot at the cmd prompt). The reboot hangs right after it initalizes the mouse and right before it checks the save to disk feature. Powering down and back up causes the system to boot correctly. I know what you are thinking: This is a hardware issue not an openbsd issue, but hear me out. If I boot the system of a Win95 rescue disk, the system does not hang. When I had slackware installed on the system 1 week ago, it did not hang. And here is kicker: it only hangs when a pcmcia card is in the slot immediately before openbsd syncs disks to reboot. Consider the following senerios: 1) Booted to msdos and rebooted: No hang 2) Booted to openbsd and rebooted (card in slot): Hang 3) Booted to openbsd and rebooted (no card in slot): No hang 4) Booted to openbsd and rebooted (no card on boot, inserted after rc.shutdown is complete, but before kernel syncs disks. Insertion mesg printed to the screen by the kernel): Hang 5) Booted to openbsd and rebooted (card on boot, removed after rc.shutdown is complete, but before kernel syncs disks. Detach mesg printed to the screen by the kernel): No hang Notice the last two cases prove that it is the state of the card when openbsd begins the reboot cycle and has nothing to do with the state of the card during the actual reboot. It seems that openbsd is putting the hardware into a weird state that prevents the bios from properly booting. Interrupt related? maybe? Insert mesg: ep1 at pcmcia1 function 0 3Com, 3C574-TX Fast EtherLink PC Card, A port 0x340/32, irq 5: address 00:10:4b:f4:b5:57 tqphy0 at ep1 phy 0: 78Q2120 10/100 PHY, rev. 10 Detach mesg: tqphy0 detached ep1 detached The diff of the dmesg of the system booted with and without card is as follows (for quick refence, full dmesgs below): $ diff ti_extensa660cdt_dmesg_generic ti_extensa660cdt_dmesg_generic_no_cards 10c10 bios0 at mainbus0: AT/286+(03) BIOS, date 09/06/97, BIOS32 rev. 0 @ 0xf5b16 --- bios0 at mainbus0: AT/286+(09) BIOS, date 09/06/97, BIOS32 rev. 0 @ 0xf5b16 31c31 pciide0: channel 1 disabled (no drives) --- pciide0: channel 1 ignored (disabled) 58,61c58,59 ep1 at pcmcia1 function 0 3Com, 3C574-TX Fast EtherLink PC Card, A port 0x340/32, irq 9: address 00:10:4b:f4:b5:57 tqphy0 at ep1 phy 0: 78Q2120 10/100 PHY, rev. 10 pcic0: irq 5, polling enabled biomask ed45 netmask ef45 ttymask ffe7 --- pcic0: irq 9, polling enabled biomask ed65 netmask ed65 ttymask ffe7 Notice that sometimes irq 5 is used and sometimes irq 9 is used. The system hands on reboot regardless of which irq openbsd selects. Issue 2: The top pcmcia slot does not seem to work with openbsd. The lower slot works with both of the cards with no issues. If a card is in the top slot upon boot (or inserted after boot), the kernel is not able to configure the card and ignores it. When the card is removed a kernel page fault error is printed to the screen and a dds prompt is given. This is true for either card. This issue is repeatable, the same fault occurs every time, with only slightly different pointer values in the trace. Here is the detailed info for the fault (copied by hand, could contain typos): Upon insert: ep1 at pcmcia0 function 0 3Com, 3C574-TX Fast EtherLink PC Card, A port 0x340/32, irq 5: address 02:01:02:01:02:01 wrote 7ff to TX_AWAIL_THRESH, read back 4057. Interface disabled Upon removal of card no detach message is printed, instead: uvm_fault(0xd05e1aa0, 0x0, 0, 1 ) - e kernel: page fault trap, code = 0 Stopped at dhooks+0x3c: movl 0(%esi),%ebx dds trace dohooks(0,3,10,d0a6644) at dohooks+0x3c if_detach(d08c584c,,,2d,d08c5800) at if_detach+0x53 ep_detach(d08c5800,d08c14,d5528ee4,d08c5800) at ep_detach+0x35 ep_pcmcia_detach(d08c500,1,10,d04a4dac,d084) at ep_pcmcia_detach+0x10 config_detch(d08c500,1,d5528f2c,d0603d4) at config_detach+0x200 pcmcia_card_detach(d04,1,0,d08cdec0,d084c080) at pcmcia_card_detach+0x47 pcic_even_process(d084c080,d08cdec0,0,d5527000) at pcic_event_process+0xe1 pcic_event_thread(d084c080) at pcic_event_thread+0x8a Bad frame pointer: 0xd070be98 dds ps (last several lines only, this is a lot of typing...) ...snip... 6000 3 0x100204 pftm pfpurge 50
Re: cat -v
Nick Guenther [EMAIL PROTECTED] writes: ... Anyway, I wasn't trying to fight about it, I'm just curious. ... sed -n l has been around since forever or at least since v7. Presumably before that folks used ed or od. cat -v -e etc. have been around in *bsd since at least 4.1bsd. I don't remember ATT picking up on those options, but probably -v, -e, etc., are part of various standards today. Certainly the FSF folks picked up on those flags in their GNU core utilities. The vis command appears to have been added in 4.4bsd. I can't find any evidence of vis outside of 4.4bsd. Most people who've been around Unix long enough have their own pet commands. For instance, I have randomize, fd, and genpass. I use randomize all the time to unsort data line by line differently each time, fd in place of od -xc to get side-by-side hex ascii dump output, and more rarely genpass to generate random passwords for things. There's very probably some population of other people out there who might find those very commands useful, - but it's also very probable there's not a large enough population of such users that I could find them without annoying a bunch of other people in the process. -Marcus Watts
Re: cat -v
On 28/07/06, Marcus Watts [EMAIL PROTECTED] wrote: Nick Guenther [EMAIL PROTECTED] writes: ... Anyway, I wasn't trying to fight about it, I'm just curious. ... sed -n l has been around since forever or at least since v7. Presumably before that folks used ed or od. cat -v -e etc. have been around in *bsd since at least 4.1bsd. I don't remember ATT picking up on those options, but probably -v, -e, etc., are part of various standards today. Certainly the FSF folks picked up on those flags in their GNU core utilities. The only standard (SUSv3) switch for the cat utility is -u for unbuffered output. The -e, -t, -v, -s, and -n switches are mentioned in the rationale, and the reason for not having them in the standard is that the same functionality may be found in other utilities (giving examples using sed(1) and pr(1)). http://www.unix.org/online.html Regards, Andreas -- Andreas Kahari Somewhere in the general Cambridge area, UK
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
Intel gigabit 82541PI
Hi. I'm looking for some gigabit netcards. And I was checking up on if the Intel 82541PI is supported by OpenBSD. Looking through the supported hardware for i386 page I found that i82541 is supported in the gigabit section. Looking in the em(4) manpage I found that a series of 82541's is supported. But the PI is not listed. Anyone knows if this card is supported or does anyone recommend another card? Thanks, Lasse Bach
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: Intel gigabit 82541PI
On 2006/07/28 13:19, Lasse Bach wrote: Looking through the supported hardware for i386 page I found that i82541 is supported in the gigabit section. Looking in the em(4) manpage I found that a series of 82541's is supported. But the PI is not listed. I think it may be caught by the 82541GI_LF entry on -current, if not then send the dmesg, it will be a simple change.
Re: snapshot always actual releases?
On 7/28/06, Miod Vallat [EMAIL PROTECTED] wrote: could some one please explain what is means that snapshots are *always* actually releases? In /usr/src/etc/Makefile, there used to be two targets to create tarballs to share a system with someone else: - make snapshot, which would create rough tarballs of various filesystem locations (bin.tar.gz, sbin.tar.gz, usr.bin.tar.gz, etc) - make release, which would create the installation media and the thematic tarballs everyone is used to use (base.tgz, comp.tgz, etc). What is published as OpenBSD snapshots is always the result of ``make release'', which is no different than the way actual releases are built. Hence the removal of the ``make snapshot'' part, and the comments that our snapshots are (obtained with make) release. Thanks a millon miod for your detailed explanation of the context :-) Kind Regards Siju
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: cat -v
On 7/28/06, Otto Moerbeek [EMAIL PROTECTED] wrote: On Thu, 27 Jul 2006, Nick Guenther wrote: Why does cat retain the -[etv], -[bn] and -[s] options? Once you've added a flag to a command it's almost impossible to remove it for compatibility reasons. Thanks Otto. That's what I figured but I was thinking that the OpenBSD philosophy would trump compatibility. -Nick
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: OpenBSD gets a poor score in security.
On 7/27/06, Louis Bertrand [EMAIL PROTECTED] wrote: If you do send something in, be polite. We're not a bunch of raving loonies. We're not? Damn! Carlos. -- nick grah windows just crashed again, unstable crap. yukito Windows isn't unstable, it's just spontaneous.
Watching daemons
Hello, currently I have a problem with my server that makes ftp-proxy die unexpectedly. I'm in the process of tracking this down, which is likely something hardware related AFAIK. In the mean time, I'd like to keep ftp-proxy running most of the time. What do you guys use/recommend to watch if a process dies and restart it? Thanks, Carlos. -- nick grah windows just crashed again, unstable crap. yukito Windows isn't unstable, it's just spontaneous.
piixpm / iic / admtemp issues!
Hi: I recently install OpenBSD in a Dell PowerEdge 1400sc, everything works fine [like always] but I found 2 issues that I cant resolve. Machine : Dell PowerEdge 1400 sc / 512MB / 34GB scsi disk / Intel 10/100 OS : OpenBSD 3.9 Kernel : GENERIC.MP 1. Even using halt -p the machine dont power down. The kernel recognize piixpm. 2. There is a problem with the iic framework, the kernel recognize two sensors but them give me a long list of iic devices dont configured, sorry but I never need to configure a device before, so I dont know how to do it. Please if anyone can help me on this I will thanks very much. Maybe OpenBSD doesnt support yet this particular issues, but at least I need a guide to keep working on it. Here is my dmesg: OpenBSD 3.9 (GENERIC.MP) #598: Thu Mar 2 02:37:06 MST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Pentium(R) III CPU family 1266MHz (GenuineIntel 686-class) 1.27 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real mem = 536449024 (523876K) avail mem = 482430976 (471124K) using 4278 buffers containing 26927104 bytes (26296K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(00) BIOS, date 08/12/02, BIOS32 rev. 0 @ 0xffe90 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfc370/176 (9 entries) pcibios0: PCI Interrupt Router at 000:15:0 (ServerWorks OSB4 rev 0x00) pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0x6000 mainbus0: Intel MP Specification (Version 1.4) (DELL POWEREDGE CE) cpu0 at mainbus0: apid 1 (boot processor) cpu0: apic clock running at 132 MHz cpu1 at mainbus0: apid 0 (application processor) cpu1: Intel(R) Pentium(R) III CPU family 1266MHz (GenuineIntel 686-class) 1.27 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE mainbus0: bus 0 is type PCI mainbus0: bus 1 is type PCI mainbus0: bus 2 is type ISA ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 16 pins ioapic0: misconfigured as apic 0, remapped to apic 2 ioapic1 at mainbus0: apid 3 pa 0xfec01000, version 11, 16 pins ioapic1: misconfigured as apic 0, remapped to apic 3 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 ServerWorks CNB20LE Host rev 0x06 pchb1 at pci0 dev 0 function 1 ServerWorks CNB20LE Host rev 0x06 pci1 at pchb1 bus 1 ahc0 at pci1 dev 2 function 0 Adaptec AIC-7899 U160 rev 0x01: apic 3 int 14 (irq 5) scsibus0 at ahc0: 16 targets sd0 at scsibus0 targ 1 lun 0: SEAGATE, ST336706LW, 8A03 SCSI3 0/direct fixed sd0: 34732MB, 26302 cyl, 4 head, 676 sec, 512 bytes/sec, 71132959 sec total ahc1 at pci1 dev 2 function 1 Adaptec AIC-7899 U160 rev 0x01: apic 3 int 15 (irq 11) scsibus1 at ahc1: 16 targets fxp0 at pci0 dev 2 function 0 Intel 8255x rev 0x08, i82559: apic 3 int 0 (irq 11), address 00:b0:d0:fc:e5:9c inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4 vga1 at pci0 dev 14 function 0 ATI Rage XL rev 0x27 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) piixpm0 at pci0 dev 15 function 0 ServerWorks OSB4 rev 0x50: SMI iic0 at piixpm0 admtemp0 at iic0 addr 0x18: adm1021 unknown at iic0 addr 0x1a not configured unknown at iic0 addr 0x20 not configured unknown at iic0 addr 0x21 not configured unknown at iic0 addr 0x22 not configured unknown at iic0 addr 0x23 not configured unknown at iic0 addr 0x24 not configured unknown at iic0 addr 0x25 not configured unknown at iic0 addr 0x26 not configured unknown at iic0 addr 0x27 not configured unknown at iic0 addr 0x28 not configured unknown at iic0 addr 0x29 not configured unknown at iic0 addr 0x2a not configured unknown at iic0 addr 0x2b not configured lmenv0 at iic0 addr 0x2c: ds1780 rev 1 lmenv1 at iic0 addr 0x2d: ds1780 rev 1 unknown at iic0 addr 0x2e not configured unknown at iic0 addr 0x2f not configured unknown at iic0 addr 0x48 not configured unknown at iic0 addr 0x49 not configured unknown at iic0 addr 0x4a not configured unknown at iic0 addr 0x4b not configured admtemp1 at iic0 addr 0x4c: adm1032 unknown at iic0 addr 0x4d not configured unknown at iic0 addr 0x4e not configured pciide0 at pci0 dev 15 function 1 ServerWorks OSB4 IDE rev 0x00: DMA atapiscsi0 at pciide0 channel 0 drive 0 scsibus2 at atapiscsi0: 2 targets cd0 at scsibus2 targ 0 lun 0: LG, CD-ROM CRD-8484B, 2.01 SCSI0 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 2 ohci0 at pci0 dev 15 function 2 ServerWorks OSB4/CSB5 USB rev 0x04: apic 2 int 10 (irq 10), version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 uhub0: ServerWorks OHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered isa0 at mainbus0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for
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: piixpm / iic / admtemp issues!
Hi: I recently install OpenBSD in a Dell PowerEdge 1400sc, everything works fine [like always] but I found 2 issues that I cant resolve. Machine : Dell PowerEdge 1400 sc / 512MB / 34GB scsi disk / Intel 10/100 OS : OpenBSD 3.9 Kernel : GENERIC.MP 1. Even using halt -p the machine dont power down. The kernel recognize piixpm. 2. There is a problem with the iic framework, the kernel recognize two sensors but them give me a long list of iic devices dont configured, sorry but I never need to configure a device before, so I dont know how to do it. [snip] unknown at iic0 addr 0x1a not configured [snip] -- Anibal Amiama-Veras Hi 'not configured' doesn't mean that you should configure something, it means that no devicedriver attached itself to this 'device'. So you'll have to wait for someone to write a driver for these devices or start hacking yourself. The poweroff thingie is probably there due to the lack of acpi-support in openbsd. Regards // Bjorn
Re: OpenBSD gets a poor score in security.
From: Marian Hettwer [mailto:[EMAIL PROTECTED]
OpenBSD is secure in many ways, but if the third party app has a
security flaw and released a bugfix, I'd like to see an
updated package
/ port too.
Otherwise I would need to compile the bugfixed version from source,
which doesn't make sense at all.
So I need to be a ports commiter or something, right? :)
Yes, it is true that in the face of a security or major other bug fix for an
app that an update should be timely as well. Thing is, most of the time,
absolutely critical updates are released for ports pretty quickly; obviously
a lot of this depends on popularity of the port itself, but somewhat on the
responsiveness of the port maintainer too. However, it needs to be clearly
understood that a lag in versions on a third party app doesn't reflect on
the OS project. 3rd party apps are largely maintained by third parties. And,
the user base can just as easily contact the port maintainer to send in a
patch for a version bump too.
I already know the next argument. OpenBSD doesn't provide critical updates
to packages as quickly as ${YOUR_LINUX_DISTRO_HERE}. I've used enough
popular distros myself to know that I _have_ had to sit around for days
using a self-built source version while I wait for the distro vendor to
produce an updated package. Resource constraints exist everywhere; no one is
on top of everything, all of the time.
DS
Re: OpenBSD gets a poor score in security.
I've written some sort of rebuttal. It is not specific to OpenBSD, though. http://lxer.com/module/forums/t/23230/ Regards, Dominik [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Watching daemons
Hi Carlos, What do you guys use/recommend to watch if a process dies and restart it? monit: http://www.tildeslash.com/monit/ /usr/ports/sysutils/monit/ HTH... Nico
IKE DoS - factual?
Word is, there is a flaw in IKEv1 that allows for an attacker to create IKE sessions faster than previous attempts expire. The security research firm who found the flaw only lists Cisco VPN devices as being vulnerable while Cisco maintains that the flaw is in the IKE protocol itself. Research Firm: http://www.nta-monitor.com/posts/2006/07/cisco-concentrator-dos.html Cisco's Response: http://www.cisco.com/en/US/tech/tk583/tk372/tsd_technology_security_response 09186a00806f33d4.html I hesitate to trust Cisco's response fully, as the behavior sounds like something that to me would be implementation dependent. Is it legitimate to fear that this kind of attack could succeed against isakmpd(8) or other IKE implementations of other projects, for example? If so, what if any controls would be effective in defense? -- Darren Spruell Information Security Operations Catholic Healthcare West IT (602)307-2217 [EMAIL PROTECTED]
Re: Watching daemons
On 7/28/06, Carlos A. Carnero Delgado [EMAIL PROTECTED] wrote: In the mean time, I'd like to keep ftp-proxy running most of the time. What do you guys use/recommend to watch if a process dies and restart it? More to the root of the problem, have you turned on verbose debugging output to see if there are any correlations to when it dies? Are any other processes dying unexpectedly? Try passing an additional flag '-D 7' and watch the logs. As a nasty interim hack, and a suggested last resort, you might use a cron job to restart it when it dies (for now) -- it won't be immediate, but you could check at 1 minute intervals. Per minute PID check and restart in root's crontab (ugly): * * * * * /usr/bin/pgrep ftp-proxy 21 /dev/null || /usr/sbin/ftp-proxy
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: Problems with PCMCIA cards
On Thu, Jul 27, 2006 at 10:33:04PM -0700, Paul Maurer wrote: I am a new user having just installed OpenBSD for the first time. I am having trouble with my PCMCIA cards. I have 2 cards, both 3COM, and two PCMCIA slots (TI-PCI1130, see dmesg below). I am currently having two issues: system hangs in bios after reboot and kernel panics when pcmcia card is removed. ---snip--- The 'panic on pcmcia eject' issue looks like bug #5128. I see the same thing on my thinkpad 560X running 3.9-stable. Is your machine a thinkpad also? -- Mark
Re: dhcpd on CARP+VLAN interfaces
Christopher Snell wrote: 2) One of the downsides to running dhcpd on a pair of CARP boxes is that there is no syncing of the leases file. So, if we have a /24 that has 240 machines, all using dynamic IPs, and the primary CARP box fails, dhcpd on the backup box will have no knowledge of those 240 leases. Any ideas here? Can we simply rsync the leases file? This should answer your 2nd question :) http://www.madboa.com/geek/dhcp-failover/ Sevan -- The truth, the half-truth, and nothing like the truth. - Mark Brandon Read
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: Watching daemons
On Fri, Jul 28, 2006 at 10:38:49AM -0400, Carlos A. Carnero Delgado wrote: In the mean time, I'd like to keep ftp-proxy running most of the time. What do you guys use/recommend to watch if a process dies and restart it? I would use daemontools[1] or runit[2]. There's also freedt in ports, but I've not tried it. [1] http://cr.yp.to/daemontools.html [2] http://smarden.sunsite.dk/runit/
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: 4.0-beta
Bryan Irvine wrote: I can't wait to see what goodies you've been holding back for the 4.0release. ;) Hold back? Congrats on the momentum, and thanks for the good work. Thanks. :) -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
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...
Gratuitous ARP problem with OpenBSD and MS Cluster Services
Hello, I have a pair of OpenBSD 3.9 firewalls (using pf and carp) attached to a network with a Windows server cluster on it. The Windows cluster moves a shared IP address between nodes using the MAC address of the actual cluster node, not a common virtual MAC address like pf uses. When it does this, it sends out gratuitous ARP requests to indicate that the cluster IP is now associated with a different MAC address. Unfortunately, OpenBSD seems to be ignoring these requests; when a cluster address moves to a different node, the ARP table on the firewall still holds the entry for the previous node, so packets routed through the firewall, which are currently all of them, go to the wrong address and are ignored. An example, with a cluster address of 172.20.0.22: # At first, there is no entry in the ARP table on the firewall: -bash-3.00$ arp -an | grep 172.20.0.22 -bash-3.00$ # I ping it from a remote host: 13:22:58.704467 0:0:5e:0:1:5 ff:ff:ff:ff:ff:ff 0806 42: arp who-has 172.20.0.22 tell 172.20.0.1 13:22:58.704612 0:14:4f:20:3f:4e 0:0:5e:0:1:5 0806 60: arp reply 172.20.0.22 is-at 0:14:4f:20:3f:4e 13:22:58.704621 0:0:5e:0:1:5 0:14:4f:20:3f:4e 0800 98: 172.29.128.218 172.20.0.22: icmp: echo request 13:22:58.704737 0:14:4f:20:3f:4e 0:0:5e:0:1:5 0800 98: 172.20.0.22 172.29.128.218: icmp: echo reply # and the expected ARP interaction happens, and the pings go through. Now there is an ARP entry: -bash-3.00$ arp -an | grep 172.20.0.22 ? (172.20.0.22) at 00:14:4f:20:3f:4e on carp4 # So I move the address to the other cluster node, and the new owner sends out gratuitous ARP packets: 13:23:11.606112 0:14:4f:20:4f:d8 ff:ff:ff:ff:ff:ff 0806 60: arp who- has 172.20.0.22 tell 172.20.0.22 13:23:11.932507 0:14:4f:20:4f:d8 ff:ff:ff:ff:ff:ff 0806 60: arp who- has 172.20.0.22 tell 172.20.0.22 13:23:12.932817 0:14:4f:20:4f:d8 ff:ff:ff:ff:ff:ff 0806 60: arp who- has 172.20.0.22 tell 172.20.0.22 # But the ARP table on my firewall still holds the old entry: -bash-3.00$ arp -an | grep 172.20.0.22 ? (172.20.0.22) at 00:14:4f:20:3f:4e on carp4 -bash-3.00$ # And pings still go, unanswered, to the old MAC address: 13:23:24.408370 0:0:5e:0:1:5 0:14:4f:20:3f:4e 0800 98: 172.29.128.218 172.20.0.22: icmp: echo request 13:23:25.410006 0:0:5e:0:1:5 0:14:4f:20:3f:4e 0800 98: 172.29.128.218 172.20.0.22: icmp: echo request 13:23:26.410600 0:0:5e:0:1:5 0:14:4f:20:3f:4e 0800 98: 172.29.128.218 172.20.0.22: icmp: echo request Any idea what's going on here? I don't think it's even possible to filter out non-IP packets with pf, and I'm certainly not trying. I am not using any bridge devices. ARP works in all other respects. I don't see any sysctl tunables for ARP, either. RFC 826 makes it clear that the ARP table should be updated in this case. -- Clayton Wheeler Windermere Technology [EMAIL PROTECTED]
Re: Problems with PCMCIA cards
On 2006-07-28 15:35:05, Mark Zimmerman wrote: On Thu, Jul 27, 2006 at 10:33:04PM -0700, Paul Maurer wrote: I am a new user having just installed OpenBSD for the first time. I am having trouble with my PCMCIA cards. I have 2 cards, both 3COM, and two PCMCIA slots (TI-PCI1130, see dmesg below). I am currently having two issues: system hangs in bios after reboot and kernel panics when pcmcia card is removed. ---snip--- The 'panic on pcmcia eject' issue looks like bug #5128. I see the same thing on my thinkpad 560X running 3.9-stable. Is your machine a thinkpad also? -- Mark It is actually a Texus Instruments Extensa 660 CDT (from about 1997), but part of the second issue is very similar to that bug. A card is insterted into a PCMCIA slot and the kernel is not able to use the card so it ignores it. Then, when the card is ejected, it fails to realize that it didn't really initialize it an tries to detach from an unproperly setup memory structure. Sounds like the issue can be fixed with an if statement on the detach that checks if the card was fully initalized upon insert. But this doesn't answer the question as to why both cards work in the bottom slot, and neither in in top slot. Just one week prior, both slots worked under Slackware, so the hardware is not broke.
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
Re: IKE DoS - factual?
On Fri, Jul 28, 2006 at 09:32:09AM -0700, Spruell, Darren-Perot wrote: Word is, there is a flaw in IKEv1 that allows for an attacker to create IKE sessions faster than previous attempts expire. The security research firm who found the flaw only lists Cisco VPN devices as being vulnerable while Cisco maintains that the flaw is in the IKE protocol itself. Research Firm: http://www.nta-monitor.com/posts/2006/07/cisco-concentrator-dos.html Cisco's Response: http://www.cisco.com/en/US/tech/tk583/tk372/tsd_technology_security_response 09186a00806f33d4.html I hesitate to trust Cisco's response fully, as the behavior sounds like something that to me would be implementation dependent. Is it legitimate to fear that this kind of attack could succeed against isakmpd(8) or other IKE implementations of other projects, for example? If so, what if any controls would be effective in defense? This is indeed a flaw of the ike protocol and rather old news, see the article mentioned in isamkpd.conf(8), section CAVEATS. Regarding dos mitigation, see http://www.openbsd.org/papers/ikepaper.ps.
Nagios check_bioctl available
I have written a perl script that parses the output from bioctl and returns it in a format that Nagios can use. check_bioctl is avaliable here: http://openbsd.somedomain.net/nagios/check_bioctl-1.3.tar.gz It is useful to me, and so I thought it might be useful to someone else. I wrote this on OpenBSD 3.9 and tested on Dell PERC 3/DC controllers using the ami driver. It should work just fine on other versions of OpenBSD as well as with other cards and drivers. If you do run into trouble, send me the output from bioctl on the system you are having trouble with and I can try to help. Patches to fix problems would be even better. One thing I ran into is that bioctl needs to run as root to get access to /dev/bio, even for read only access. Is there a way to query bioctl without needing root? Also, in biovar.h, both a raid volume and a disk can be Offline. However, I am not sure what that means. Currently it is a WARNING, but I don't know what status it should be set to. http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/biovar.h?rev=1.25content-type=text/x-cvsweb-markup If anyone knows what the Offline status means, I would sure like to know. An additional useful feature is that you can specify multiple devices to check in a single check /usr/local/libexec/nagios/check_bioctl -d ami0 -d ami1 Output is similar to below, except with NAGIOS_OUTPUT set to 1 in the source (as it usually is) all output is on a single line separated with br and it hides any devices that are OK because Nagios has a limit on the length of a response. CRITICAL (1): ami0 sd1 Degraded WARNING (1): ami0 0:8.0 Rebuild QUANTUM ATLAS10K2-TY184JDA40 OK (7): ami0 sd0 Online ami0 0:0.0 Online IBM DMVS09M 0220 ami0 0:1.0 Online IBM DRVS09D 0140 ami0 0:3.0 Online QUANTUM ATLAS10K2-TY184JDA40 ami0 0:4.0 Online QUANTUM ATLAS10K2-TY184JDA40 ami0 0:5.0 Online QUANTUM ATLAS10K2-TY184JDA40 ami0 0:2.0 Hot spare IBM DRVS09D 0140 I currently configure it something like this: $ grep check_bioctl /etc/sudoers /etc/nrpe.cfg /etc/sudoers:_nrpe ALL = NOPASSWD:/usr/local/libexec/nagios/check_bioctl -d ami0 /etc/nrpe.cfg:command[check_bioctl]=/usr/bin/sudo /usr/local/libexec/nagios/check_bioctl -d ami0 Also available is check_hw_sensors for checking of sysctl hw.sensors from Nagios. http://openbsd.somedomain.net/nagios/ l8rZ, -- andrew - ICQ# 253198 - JID: [EMAIL PROTECTED] BOFH excuse of the day: YOU HAVE AN I/O ERROR - Incompetent Operator error
Re: Nagios check_bioctl available
andrew fresh wrote: I have written a perl script that parses the output from bioctl and returns it in a format that Nagios can use. Sweet :-) check_bioctl is avaliable here: http://openbsd.somedomain.net/nagios/check_bioctl-1.3.tar.gz It is useful to me, and so I thought it might be useful to someone else. I wrote this on OpenBSD 3.9 and tested on Dell PERC 3/DC controllers using the ami driver. It should work just fine on other versions of OpenBSD as well as with other cards and drivers. If you do run into trouble, send me the output from bioctl on the system you are having trouble with and I can try to help. Patches to fix problems would be even better. One thing I ran into is that bioctl needs to run as root to get access to /dev/bio, even for read only access. Is there a way to query bioctl without needing root? No! Also, in biovar.h, both a raid volume and a disk can be Offline. However, I am not sure what that means. Currently it is a WARNING, but I don't know what status it should be set to. If 2 or more physical disks of a RAID 5 are offline a volume will be marked offline as well. An offline RAID 5 is obviously a critical event. Hope this makes sense since I am not exactly sure what you are asking. http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/biovar.h?rev=1.25content-type=text/x-cvsweb-markup If anyone knows what the Offline status means, I would sure like to know. An additional useful feature is that you can specify multiple devices to check in a single check /usr/local/libexec/nagios/check_bioctl -d ami0 -d ami1 Output is similar to below, except with NAGIOS_OUTPUT set to 1 in the source (as it usually is) all output is on a single line separated with br and it hides any devices that are OK because Nagios has a limit on the length of a response. CRITICAL (1): ami0 sd1 Degraded WARNING (1): ami0 0:8.0 Rebuild QUANTUM ATLAS10K2-TY184JDA40 OK (7): ami0 sd0 Online ami0 0:0.0 Online IBM DMVS09M 0220 ami0 0:1.0 Online IBM DRVS09D 0140 ami0 0:3.0 Online QUANTUM ATLAS10K2-TY184JDA40 ami0 0:4.0 Online QUANTUM ATLAS10K2-TY184JDA40 ami0 0:5.0 Online QUANTUM ATLAS10K2-TY184JDA40 ami0 0:2.0 Hot spare IBM DRVS09D 0140 I currently configure it something like this: $ grep check_bioctl /etc/sudoers /etc/nrpe.cfg /etc/sudoers:_nrpe ALL = NOPASSWD:/usr/local/libexec/nagios/check_bioctl -d ami0 /etc/nrpe.cfg:command[check_bioctl]=/usr/bin/sudo /usr/local/libexec/nagios/check_bioctl -d ami0 Also available is check_hw_sensors for checking of sysctl hw.sensors from Nagios. http://openbsd.somedomain.net/nagios/ l8rZ,
Re: Nagios check_bioctl available
andrew fresh wrote: I have written a perl script that parses the output from bioctl and returns it in a format that Nagios can use. Sweet :-) check_bioctl is avaliable here: http://openbsd.somedomain.net/nagios/check_bioctl-1.3.tar.gz It is useful to me, and so I thought it might be useful to someone else. I wrote this on OpenBSD 3.9 and tested on Dell PERC 3/DC controllers using the ami driver. It should work just fine on other versions of OpenBSD as well as with other cards and drivers. If you do run into trouble, send me the output from bioctl on the system you are having trouble with and I can try to help. Patches to fix problems would be even better. One thing I ran into is that bioctl needs to run as root to get access to /dev/bio, even for read only access. Is there a way to query bioctl without needing root? No! Also, in biovar.h, both a raid volume and a disk can be Offline. However, I am not sure what that means. Currently it is a WARNING, but I don't know what status it should be set to. If 2 or more physical disks of a RAID 5 are offline a volume will be marked offline as well. An offline RAID 5 is obviously a critical event. Hope this makes sense since I am not exactly sure what you are asking. http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/biovar.h?rev=1.25content-type=text/x-cvsweb-markup If anyone knows what the Offline status means, I would sure like to know. An additional useful feature is that you can specify multiple devices to check in a single check /usr/local/libexec/nagios/check_bioctl -d ami0 -d ami1 Output is similar to below, except with NAGIOS_OUTPUT set to 1 in the source (as it usually is) all output is on a single line separated with br and it hides any devices that are OK because Nagios has a limit on the length of a response. CRITICAL (1): ami0 sd1 Degraded WARNING (1): ami0 0:8.0 Rebuild QUANTUM ATLAS10K2-TY184JDA40 OK (7): ami0 sd0 Online ami0 0:0.0 Online IBM DMVS09M 0220 ami0 0:1.0 Online IBM DRVS09D 0140 ami0 0:3.0 Online QUANTUM ATLAS10K2-TY184JDA40 ami0 0:4.0 Online QUANTUM ATLAS10K2-TY184JDA40 ami0 0:5.0 Online QUANTUM ATLAS10K2-TY184JDA40 ami0 0:2.0 Hot spare IBM DRVS09D 0140 I currently configure it something like this: $ grep check_bioctl /etc/sudoers /etc/nrpe.cfg /etc/sudoers:_nrpe ALL = NOPASSWD:/usr/local/libexec/nagios/check_bioctl -d ami0 /etc/nrpe.cfg:command[check_bioctl]=/usr/bin/sudo /usr/local/libexec/nagios/check_bioctl -d ami0 Also available is check_hw_sensors for checking of sysctl hw.sensors from Nagios. http://openbsd.somedomain.net/nagios/ l8rZ,
Ipsecadm Subnet-Subnet Can't connect
Hi I have some problem on the ipsecadm setting as i ping from 172.16.22.2 to 10.150.17.2 i cant get reply from 10.150.17.2 but i can get replay as i tcpdump on the WAN interface at 1.1.1.1 and 2.2.2.2 but untill 2.2.2.2 interface it ihas the replay but without the encap. It means when the packet from 10.150.17.2 back to 10.17.22.2 the 10.150.17.2 didn't enter the tunnel so no encap. My setting is as below. Can anyone point out the error? Server ipsecadm ipcomp \ -comp lzs \ -cpi 0x0704 \ -src 1.1.1.1 -dst 2.2.2.2 ipsecadm ipcomp \ -comp lzs \ -cpi 0x0407 \ -src 2.2.2.2 -dst 1.1.1.1 ipsecadm flow -in -require -proto ipcomp \ -src 1.1.1.1 -dst 2.2.2.2 \ -addr 172.16.22.0/24 10.150.17.0/24 ipsecadm flow -out -require -proto ipcomp \ -src 1.1.1.1 -dst 2.2.2.2 \ -addr 10.150.17.0/24 172.16.22.0/24 I added route add -net 172.16.22.0/24 2.2.2.2 Client ipsecadm ipcomp \ -comp lzs \ -cpi 0x0407 \ -src 1.1.1.1 -dst 2.2.2.2 ipsecadm ipcomp \ -comp lzs \ -cpi 0x0704 \ -src 2.2.2.2 -dst 1.1.1.1 ipsecadm flow -in -require -proto ipcomp \ -src 2.2.2.2 -dst 1.1.1.1 \ -addr 10.150.17.0/24 172.16.22.0/24 ipsecadm flow -out -require -proto ipcomp \ -src 2.2.2.2 -dst 1.1.1.1 \ -addr 172.16.22.0/24 10.150.17.0/24 I added route add -net 10.150.17.0/24 202.171.48.9 * i tcpdump on both gateway and have request no encap but replay with encap * i can't ping from subnet to subnet as i tcpdump on the subnet host no reply from the other end of subnet. On gateway there is request and reply messages with just encap on the WAN interface while LAN interface with just request and reply messages. Any Ideas?
