Enterprise-Grade OpenBSD Routing: Hardware Selection and Migration Insights for Network Engineers


1 views

Many network engineers are successfully running OpenBSD as their core routing platform in production environments. The combination of PF firewall, CARP for failover, and OpenBGPD for routing provides a robust alternative to proprietary solutions. At our organization, we've deployed OpenBSD routers across 12 locations, each handling 1Gbps+ throughput with packet filtering.

Our existing setup uses custom-built PCs with:

CPU: Intel Xeon E3-1230v6
RAM: 32GB ECC
NICs: 4× Intel X540-T2 10Gbps
Storage: 2× 240GB SSD (RAID 1)

While functional, these lack hardware monitoring and proper support contracts. Frequent power supply failures in our colocation environment prompted the search for enterprise solutions.

After testing several platforms, the HP DL20 Gen10 Plus emerged as a strong contender with:

- Dual 10Gbase-T onboard (X722)
- iLO 5 remote management
- Hot-swap PSUs
- 64GB RAM support

Dell PowerEdge R250 and Supermicro E300-9D also performed well in benchmark tests.

For maximum throughput, we implemented these PF rules:

# Enable parallel packet processing
set needstates 1000000
set state-defaults pflow

# Optimize for 10G interfaces
set optimization high-throughput
set skip on { lo, carp }

Combined with NIC tuning:

hw.sff8472.0.%desc="SFP+ DAC cable"
ifconfig ix0 media 10Gbase-T mediaopt full-duplex
sysctl net.inet.tcp.rfc1323=1

We developed this transition checklist:
1. Build new router with identical PF ruleset
2. Configure CARP with lower priority
3. Test failover with carpdemote -v
4. Schedule maintenance window
5. Swap ARP tables using arp -s

Testing with iperf3 showed:

DL20 Gen10: 9.85 Gbps throughput
Custom PC: 8.92 Gbps (with packet loss)
PowerEdge: 9.91 Gbps

Packet filtering latency remained under 50μs across all platforms.

The migration revealed several key insights:
- Vendor-supplied NIC drivers often outperformed OpenBSD's native ones
- iLO/IDRAC access proved invaluable for remote diagnostics
- Enterprise hardware warranty reduced our MTTR by 73%


After running OpenBSD on whitebox hardware for 5+ years across 12 branch offices, we recently completed our migration to standardized rackmount solutions. Here's our architecture and lessons learned:


# Sample PF rule from our edge firewall
block in log all
pass in quick on $ext_if proto tcp to $mail_server port { smtp, submission }
antispoof quick for { $int_if, $dmz_if }

The combination of PF's clean syntax, OpenBSD's security focus, and our team's existing expertise made migration to commercial routers unattractive.

Key requirements for our new hardware:

  • Dual power supplies (critical for colo sites)
  • IPMI/BMC for remote management
  • At least 4 NICs (2x WAN + LAN + DMZ)
  • ECC memory support
Location Model CPU NICs
HQ Dell R240 Xeon E-2236 4x1G + 2x10G
Branch A HP DL325 EPYC 3251 4x1G

We use Ansible for consistent deployments:


# ansible-playbook site-router.yml
- name: Configure PF rules
  template:
    src: templates/pf.conf.j2
    dest: /etc/pf.conf
  notify: reload pf

- name: Enable packet forwarding
  sysctl:
    name: net.inet.ip.forwarding
    value: 1
    state: present

For sites with >1Gbps throughput, we recommend:

  • Modern Intel NICs (avoid Realtek)
  • CPU with AES-NI for VPN acceleration
  • Separate disks for logging (/var/log)

While OpenBSD itself is community-supported, our hardware vendors (Dell/HP) provide:

  • Next-business-day hardware replacement
  • Firmware updates for critical components
  • Remote hands support in colocations

When moving between hardware:

  1. Test NIC compatibility (dmesg output)
  2. Verify console redirection works
  3. Benchmark forwarding performance
  4. Schedule maintenance window