OpenBSD Firewall and ddb{1}
I've got two OpenBSD 3.9 firewall/router in a CARP configuration. They are
both IBM NetFinity 40004 servers with dual P3 650MHz chips and 512MB of
memory each. Twice now, the backup firewall has disappeared from my Nagios
monitoring and I've found (through remote serial console) only a ddb{1}>
prompt.
According to man ddb, this can happen when the kernel panics or when a break
signal is sent from the console (and ddb.console is set to 1). In my case,
no one is using the console at these times and ddb.console is set to 0
anyway. However, "show panic" seems to indicate it wasn't a kernel panic
either:
ddb{1}> show panic
the kernel did not panic
I feel like I'm missing something obvious here. Is there some undocumented
condition that can cause a system to crash to ddb or am I investigating the
panic wrong? I tried using trace and hangman to gather more information, but
hangman just confused the hell out of me and the trace command gave me:
apm_cpu_idle(0,0,0,0,0) at apm_cpu_idle+0x4a
After a little more investigative commands, I started only to get "Faulted in
DDB; continuing..." and tried rebooting. "boot dump" yielded a nonresponsive
system and a trip to the datacenter to cold boot the machine.
Anyone have any ideas? Perhaps I can disable part of APM and avoid this
problem in the future? What other techniques can I use to debug this if it
happens again - is there a good doc out there that is a little more
descriptive than man ddb?
--
Regards,
Neil Schelly
Senior Systems Administrator
W: 978-667-5115 x213
M: 508-410-4776
OASIS Open http://www.oasis-open.org
"Advancing E-Business Standards Since 1993"
Re: Microsoft gets the Most Secure Operating Systems award
On Thursday 22 March 2007 11:29 am, RedShift wrote: > Siju George wrote: > > Hi, > > > > http://www.internetnews.com/security/article.php/3667201 > > > > Just for some entertainment, no troll :-) > > > > --Siju > > IMHO it's not a fair comparison, most linux distributions ship with alot > more software than microsoft windows does, and most bugreports indicate > an issue with third-party software. If you read the article past the summary, they mention that. While Windows had far fewer bugs than say Red Hat, Red Hat only had 2 (out of 208) considered high/severe. Windows had a very high percentage of its bugs labelled as high or severe (12 out of 39). Similarly, I'm sure if you looked at the time-to-fix for just the high and severe bugs from each side, you'd see that the Microsoft ones were slower to get patched. I'm just betting that the 200+ less unimportant bugs included many that really just didn't warrant any priority to fix. Unfortunately, the article doesn't really show this in the light that suggests the findings of Windows being the most secure commercial OS might be false, but it's not too hard to read between the lines. 78% of statistics are made up and 103% of statistics can say the exact opposite of what you think they should mean. -- Regards, Neil Schelly Senior Systems Administrator W: 978-667-5115 x213 M: 508-410-4776 OASIS Open http://www.oasis-open.org "Advancing E-Business Standards Since 1993"
Re: OT? Is this bad news?
On Wednesday 14 February 2007 12:24 pm, Darren Spruell wrote: > On 2/14/07, Neil Joseph Schelly <[EMAIL PROTECTED]> wrote: > > > Also, please educate me: couldn't a BSD driver be created by using the > > > cleanroom approach? One person reads the GPL code, writes specs, > > > another implements them? Or is this covered when people say "reverse > > > engineer"? > > > > I imagine that's the best case scenario here, > > No, the best case scenario is that the good intentions of the Linux > driver project would be focused on getting vendors to provide open My statement wasn't an opinion, so please don't say I'm wrong. His question was about how this project could lead to drivers for BSD. And it ~could~ be that cleanroom implementations of the driver code developed for GPL projects get reliable enough under BSD here. That is the best case scenario here - that drivers are written well enough that reliable specs can be drawn up from them and be useful. I didn't in my email suggest I thought this was the best way to make drivers. I just answered the question he asked about creating BSD drivers based on GPL'd drivers without the original specs. Please don't correct my statements out of context. -- Regards, Neil Schelly Senior Systems Administrator W: 978-667-5115 x213 M: 508-410-4776 OASIS Open http://www.oasis-open.org "Advancing E-Business Standards Since 1993"
Re: OT? Is this bad news?
> He might *actually* be telling the truth. Maybe not all NDAs are > conspiracies against us, but are just marketers trying to keep things > quiet, and beyond that the companies don't care. That code might > actually be readable! > --then again it might not. We'll see. As an optimist, I tend to agree with you. He hasn't really started something new - he's really just making it public knowledge with an open letter to hardware makers how FOSS drivers get made. A lot of shops must avoid the FOSS world because they don't want to take on another platform for support, no knowing that the community will. Realistically, while a company may require an NDA while they want to keep things secret, I expect having an unobfuscated driver out there will negate any need to enforce it longer than necessitated by marketing departments. I also expect that any drivers written in this manner will be discluded from the mainline linux kernel tree unless they are absolutely clearly written to a degree that the top deciders in Linux will accept it regardless of NDAs. Manufacturers who continue to be troublesome will see their drivers go away or require more work at least for users. If I can choose between two SCSI cards in Linux where one is supported by generic kernels, but the other requires either binary blobs or firmware loaders, or patching my own kernel with their code, I'll pick the easy one hands down. I think manufacturers will see that. > Also, please educate me: couldn't a BSD driver be created by using the > cleanroom approach? One person reads the GPL code, writes specs, > another implements them? Or is this covered when people say "reverse > engineer"? I imagine that's the best case scenario here, but that certainly does make things harder and everyone's a little more likely to lose something in translation. It's one of those situations where it *can* work, but no one wants to do it that way. It's not as bad as reverse engineering without a working model, but it is still reverse engineering because you're building your own specifications based on something that isn't the specifications. -- Regards, Neil Schelly Senior Systems Administrator W: 978-667-5115 x213 M: 508-410-4776 OASIS Open http://www.oasis-open.org "Advancing E-Business Standards Since 1993"
Re: pf+altq
On Wednesday 17 January 2007 07:28 am, sonjaya wrote:
> queue q_std bandwidth 100% cbq \
> {q_def,q_pri,q_web,q_msc,q_dat,q_gms}
> queue q_def bandwidth 25% priority 1 cbq(borrow default red ecn)
> queue q_dat bandwidth 10% priority 0 cbq(red)
> queue q_web bandwidth 25% priority 5 cbq(borrow)
> queue q_msc bandwidth 15% priority 4 cbq(borrow)
> queue q_gms bandwidth 25% priority 6 cbq(borrow)
> queue q_pri priority 7
>
> pfctl: the sum of the child bandwidth higher than parent "q_std"
The totals for the 6 queues under q_std need to add to 100%. The first 5
queues make 25%+10%+25%+15%+25% = 100%. Then you have an extra queue called
q_pri that there's no "room" for. You need to assign it a slice of the 100%
and lower another queue to accommodate.
--
Regards,
Neil Schelly
Senior Systems Administrator
W: 978-667-5115 x213
M: 508-410-4776
OASIS Open http://www.oasis-open.org
"Advancing E-Business Standards Since 1993"
Re: Trunk to two swichtes, carp on trunk-interfaces
On Wednesday 17 January 2007 07:24 am, Falk Brockerhoff - smartTERRA GmbH wrote: > I want to connect an openbsd router to two swichtes in case of > redundancy. These two switches are connected together, so that I think > trunk in failover mode may be the right way, isn't it? This is what I do for my redundant setups. I have two provider drops, one into each switch, one connection into the external interface of each of my firewalls from each switch, then one connection back into a trunk port of each switch for routing between the various VLANs. The switches themselves are in the same VTP domain, so that the external connections and provider drops are all in one VLAN. -- Regards, Neil Schelly Senior Systems Administrator W: 978-667-5115 x213 M: 508-410-4776 OASIS Open http://www.oasis-open.org "Advancing E-Business Standards Since 1993"
Re: isakmpd question
On Thursday 11 January 2007 12:46 pm, Jacob Yocom-Piatt wrote:
> have you tried following this ipsecctl "howto"
Yes
> there are tons of things you could have wrong when not using ipsecctl.
> you didn't post any of the relevant config files or debugging
> information, so how do you expect anyone to help?
I was unclear in my original post. These were running before with ipsec.conf,
as follows (with similar entries on the other end's firewall of course).
ike passive esp from 10.20.20.0/22 to 10.21.20.0/22 peer x.x.x.x
I've rebuilt them the long way in isakmpd.conf, but ultimately, they work just
as well either way. I still have these occasional interruptions during SA
timeouts. I've actually noticed today for the first time a Phase 2 SA
timeout caused a similar interruption, even though a new SA had already been
negotiated, so perhaps my initial observations are off still.
Anyway, I didn't submit debugging or config files before because attaching
every config file involved here would be overhwelming. I'm hoping I can get
some direction to look for, more along the lines of generic isakmpd
troubleshooting.
I've been trying to make pf, altq, isakmpd, ipsec.conf, etc adjustments as
atomically as possible to see if I can at least affect the problem and get a
hint at where to look more closely. The best I've got so far is that altq
may be related because it's under high loads in general that the connections
have more problems. And isakmpd may be related because doubling the SA
timeouts makes it more reliable, in the sense that the behavior comes up half
as often.
#
Here's the datacenter (dc0) side of my isakmpd.conf for example:
[General]
Listen-On = X.X.X.X (CARP)
Default-phase-1-lifetime = 7200,60:86400
Default-phase-2-lifetime = 2400,60:86400
[Phase 1]
X.X.X.X = ma0fw
[Phase 2]
Connections = dc0network-ma0network, dc0savvis-ma0network
[ma0fw]
Phase = 1
Transport = udp
Address = X.X.X.X
Configuration = Default-main-mode
[dc0network-ma0network]
Phase = 2
ISAKMP-peer = ma0fw
Configuration = Default-quick-mode
Local-ID = dc0network
Remote-ID = ma0network
[dc0savvis-ma0network]
Phase = 2
ISAKMP-peer = ma0fw
Configuration = Default-quick-mode
Local-ID = dc0savvis
Remote-ID = ma0network
[dc0network]
ID-type = IPV4_ADDR_SUBNET
Network = 10.20.20.0
Netmask = 255.255.252.0
[dc0savvis]
ID-type = IPV4_ADDR_SUBNET
Network = 10.1.1.0
Netmask = 255.255.255.0
[ma0network]
ID-type = IPV4_ADDR_SUBNET
Network = 10.21.20.0
Netmask = 255.255.252.0
[Default-main-mode]
EXCHANGE_TYPE = ID_PROT
Transforms = 3DES-SHA-GRP2-RSA_SIG
[Default-quick-mode]
EXCHANGE_TYPE = QUICK_MODE
Suites = QM-ESP-3DES-SHA-SUITE
#
#
Here's my datacenter side pf.conf, as applies to altq/IPSec
altq on fxp1 cbq bandwidth 6Mb queue { standard, admin, vpncontrol, carp }
queue standard bandwidth 82% { mail, std }
queue mail bandwidth 25% priority 2 cbq(borrow)
queue std bandwidth 75% priority 6 cbq(borrow, default)
queue admin bandwidth 10% { ssh, vpn }
queue ssh bandwidth 20% { ssh_interactive, ssh_bulk }
queue ssh_interactive bandwidth 25% priority 4 cbq(ecn, borrow)
queue ssh_bulk bandwidth 75% cbq(ecn, borrow)
queue vpn bandwidth 80% priority 6 cbq(borrow)
queue vpncontrol bandwidth 4% priority 7 cbq(borrow)
queue carp bandwidth 4% priority 7 cbq(borrow)
# Allow isakmpd control traffic between
pass in quick on $ext_if proto udp from to $extcarp_if:0 port
isakmp queue vpncontrol
pass out quick on $ext_if proto udp from $extcarp_if:0 to port
isakmp queue vpncontrol
# Allow all isakmpd tunneled traffic (encoded with esp)
pass in quick on $ext_if proto esp from to $extcarp_if:0 queue
vpn
pass out quick on $ext_if proto esp from $extcarp_if:0 to queue
vpn
#
#
Here is the excerpts from /var/run/isakmpd.result on the office side firewal
during a Phase 2 SA timeout period.
SA name: dc0fw (Phase 1/Initiator)
src: MA0.X.X.X dst: DC0.X.X.X
Lifetime: 7200 seconds
Soft timeout in 4086 seconds
Hard timeout in 4468 seconds
icookie b83f99790cccd43a rcookie 0a4d6741d97c0d96
SA name: dc0savvis-ma0network (Phase 2)
src: MA0.X.X.X dst: DC0.X.X.X
Lifetime: 2400 seconds
Hard timeout in 41 seconds
SPI 0: 985404c3
SPI 1: 257a3144
Transform: IPsec ESP
Encryption key length: 24
Authentication key length: 20
Encryption algorithm: 3DES
Authentication algorithm: HMAC-SHA1
SA name: dc0network-ma0network (Phase 2)
src: MA0.X.X.X dst: DC0.X.X.X
Lifetime: 2400 seconds
Soft timeout in 149 seconds
Hard timeout in 296 seconds
SPI 0: 67f24a6f
SPI 1: e3f4896b
Transform: IPsec ESP
Encryption key length: 24
Authentication key length: 20
Encryption algorithm: 3DES
Authentication algorithm: HMAC-SHA1
SA name: dc0savvis-ma0network (Phase 2)
src: MA0.X.X.X dst: DC0.X.X.X
Lifetime: 2400 seconds
Soft timeout in 1852 seconds
Hard timeout
isakmpd question
I'm having a problem with an IPSec tunnel I have configured connecting two networks together. Each firewall is running OpenBSD 3.9. At one end, it's a pair of firewalls running CARP and I've turned off sasyncd to troubleshoot now, because I didn't want to have it interfering and I suspect it may have been causing more problems. Since the primary firewall is staying up without issues, I'm ignoring the backup in my examples. Essentially, the behavior I'm seeing is that communication over the tunnel is interrupted whenever the Phase 1 SA is timed out. When it hits the soft timeout, a new SA is negotiated and looks fine. As soon as the older Phase 1 SA times out, communication (even just pinging) is interrupted for a minute or less. To confirm that the behavior is related to the timeouts, I've doubled all my timeout times in isakmpd.conf to 7200s for Phase 1 and 2400 seconds for Phase 2. The outages happen roughly half as often now and still correspond in timing to new Phase 1 SA establishments and changeover. I have pf configured on both ends, with altq. Altq isn't dropping any port 500 isakmpd packets (according to pfctl -vvs queue) on either side and only occasional esp traffic under high loads. Both have enough bandwidth reserved and they're given the highest priority in CBQ mode. pf is allowing isakmpd traffic only from the other of our two locations at both sides. I don't suspect that pf or altq is the problem here just because the SAs do get recreated without any obvious problem and traffic is "allowed" at least to proceed through the packet filter normally. However, the problem is exacerbated by higher throughput times during the business day - it usually goes unnoticed (by Nagios) on a weekend or overnight, so altq could be a factor if I need to reserve some bandwidth for more than port 500 and esp traffic. I've been watching SAs with the following procedure from isakmpd's man page: # echo S>/var/run/isakmpd.fifo # cat /var/run/isakmpd.result The flows/routes as reported by ipsecctl -vvs all and netstat -rnf encap don't appear to be interrupted ever - they are always present unless I clear the SA table manually. pflog is logging all dropped packets to /var/log/pflog and I never find any esp or port 500 packets in there except obviously from servers outside our networks. Does anyone have any suggestions for points to investigate? I can provide configuration details about parts of this if anyone has a good place to look. I've already manually configured tunnels with isakmpd.conf (rather than ipsec.conf) in hopes that something would show up in that process, but the same behavior is noticed both ways. -- Regards, Neil Schelly Senior Systems Administrator W: 978-667-5115 x213 M: 508-410-4776 OASIS Open http://www.oasis-open.org "Advancing E-Business Standards Since 1993"
