FreeBSD CARP+BRIDGE+VLAN=BAD

Bridge, good. VLANs, great. CARP, awesome. BRIDGE+VLAN+CARP, pwned. We decided to purchase a pair of atom-based systems for use as the office firewalls. The only thing we weren't completely pleased with was the single Ethernet port. Given that we have been using vlans elsewhere on the network, we didn't expect that there would be any problems using vlans for all interfaces. It turned out to be a big box of pain. In addition to routing problems, we also appear to have aggravated a bug that hangs the system.

VLAN+CARP is a fairly common configuration on firewalls. Our office and DC LANs use the same subnet and are bridged over an OpenVPN tunnel. Trying to incorporate VLAN+CARP into into a bridge seems to cause problems. This diagram illustrates our logical network setup.

After a lot of trial and error, a number of conclusions were drawn.

• Routing over the bridge doesn't work the same when using vlans. The VPN server pushes a route to our production network when clients connect. When the office firewall was using a physical Ethernet interface for the LAN, this route would refer to the LAN interface as the outgoing interface for this connection. This seems counter-intuitive, but it worked just fine. When the Ethernet LAN interface was replaced with a vlan, the tap (VPN) interface was referenced by the route to production. This seemed to be more logical, except that the Production network became unreachable.

• After some troubleshooting, I figured out that access to the production network could be fixed by adding a static route to the DC firewall (next-hop to production network) pointing out the tap interface. This seemed to allow traffic to flow smoothly to production.

• Adding CARP into the above configuration caused the firewall to hang randomly. There seemed to be no indication of a crash, no excessive resource use or network traffic.

• Routing traffic between tagged vlans and the underlying physical interface may be problematic. This was an earlier configuration I tried, and it seemed to have issues. However, at the time I had not identified CARP as the source of the system hangs, so this may be a non-issue.

The routing issue was reported in a PR that can be found here. The routing tables mentioned above can be found here.

Enabling Audigy SPDIF in Windows 7

Reinstalled Windows 7 the other day and spent an hour figuring out how to enable digital audio output for my SoundBlaster Audigy Platinum. When you open the Sound properties you will see "Speakers" and "SPDIF Out" listed as playback devices. Futz with SPDIF all you want, but you won't get any audio output from digital. I finally opened the properties for "Speakers" and found the magic option under the "Custom" tab. The only option listed is a check box for "Digital Output Only". Click that box, hit apply, and enjoy digital output.

Apache startup problems

After spending the better part of a day trying to track this problem down, I figured I'd be nice and share the fix, since google wasn't helpful. I was trying to fix a previously working apache installation and found that I was unable to authenticate using LDAP. With the apache logging set to debug, I received the following messages.

At apache startup:
[Wed Apr 06 08:56:30 2011] [debug] mod_authnz_ldap.c(1010): [2999] auth_ldap url parse: `ldap://ldap.blissfulidiot.com/ou=people,dc=blissfulidiot,dc=com?uid?sub?(clxEnabled=TRUE)', Host: ldap.blissfulidiot.com, Port: 389, DN: ou=people,dc=blissfulidiot,dc=com, attrib: uid, scope: subtree, filter: (clxEnabled=TRUE), connection mode: not using SSL

At authentication attempt:

[Wed Apr 06 08:57:58 2011] [debug] mod_authnz_ldap.c(403): [client 10.0.3.6] [5604] auth_ldap authenticate: using URL ldap://ldap.blissfulidiot.com/ou=people,dc=blissfulidiot,dc=com?uid?sub?(clxEnabled=TRUE)

[Wed Apr 06 08:57:58 2011] [info] [client 10.0.3.6] [5604] auth_ldap authenticate: user tom authentication failed; URI / [LDAP: ldap initialization failed][Unknown (private extension) error]

The solution for me on FreeBSD, rebuild the apr port.

Multiple Ambient Temp sensors in the Dell R610

The Dell R610 servers we have report a status for three different "Ambient Temp" sensors.

tom@R610:~-> sudo ipmitool sdr type "Temperature" | grep -i ambien
Ambient Temp | 07h | ok | 10.1 | 22 degrees C
Ambient Temp | 08h | ok | 10.2 | 20 degrees C
Ambient Temp | 0Eh | ok | 7.1 | 25 degrees C

The three sensors appear to be the redundant PSUs (10.1 & 10.2), and the main chassis sensor (7.1). Doing some checking around, it appears that all our Dell boxes list the "main" ambient temp in category(?) 7.1, but the actual sensor address is not always 0Eh. Category 10.<1|2> seems to always refer to the PSUs on the 610s.