Eigentlich war der Zotac CI321 Barebone als neue Firewall angedacht. Der Releasetermin lies recht lange auf sich warten und als die ersten HĂ€ndler das Teil verfĂŒgbar hatten, wurde ich auf eine Alternative aufmerksam: Shuttle DS57U mit Intel Broadwell.
Die groben Specs:
Intel Celeron 3205U CPU, 2 Kerne, 2 Threads
Zwei SO-Dimm SteckplÀtze
Ein 2.5 Zoll Slot fĂŒr HDD oder SDD
Zwei MiniPCIe SteckplÀtze (Full- und Halfsize)
Ein MiniPCIe Steckplatz mit Realtek Wifi Karte (150 MBit)
Zwei Intel NICs onboard:
– Intel i211 Ethernet Controller mit MAC, PHY und PCIe-Schnittstelle
– Intel i218LM PHY verbunden mit dem MAC des Prozessors
Integrierter SD Kartenleser
2x USB3, 4x USB2
HDMI und Displayport
Details findet man auf der Shuttle Seite.

Als Massenspeicher diente mir eine Sandisk 16 GB Micro SDHC Karte (UHS 1). FĂŒr den RAM habe ich ein Crucial Modul mit 4 GB DDR3 Low Voltage eingebaut. Installiert wurde IPFire in der aktuellen Version 2.17 mit Core Update 89. Die Intel i211 habe ich als grĂŒnes, internes Interface genutzt. Entsprechend die Intel i218LM als rote, externe Schnittstelle.
Wozu aber der spĂ€te Sinneswandel vom Zotac zum Shuttle? Der Hauptgrund war ein Unterschied bei den Netzwerkkarten. WĂ€hrend der Zotac Barebone auf zwei passive Realtek Karten setzt, sind beim Shuttle zwei mehr oder weniger aktive Intel NICs verbaut. Die aktiven Karten sollten zu deutlich geringerer CPU Auslastung unter Last fĂŒhren. Ein weiterer Bonus beim Shuttle ist eine Intel CPU der aktuellen Broadwell Architektur. Entgegen erster Informationen bietet die CPU kein AES-NI und damit keine Beschleunigung bei OpenVPN. Umso wichtiger, dass die aktiven NICs den Prozessor entlasten. Bei 250 MBit Downstream, Proxy, URL Filter etc. ist man um jedes StĂŒck Performance dankbar. Apropos Performance, hier die Testergebnisse. Hauptaugenmerk war natĂŒrlich die Netzwerkperformance. Alles gemessen mit angepassten iperf Parametern. Vorab aber noch das Netzschema:

iperf Client und Server sind Intel Quadcore mit Intel bzw. Broadcom Netzwerkkarten. Der OpenVPN Client ist ebenfalls ein Quadcore mit Broadcom Client. Alle Tests wurden im lokalen Netz gemacht. Als Switch diente ein Gigabit Modell.
Erster Test. iperf Client zu iperf Server. Wie man den Parametern entnehmen kann, habe ich auf eine groĂe TCP Windowsize gesetzt und zwei parallele Threads gestartet:
F:\iperf>iperf -c 192.168.0.200 -w 256k -l 256k -P2
————————————————————
Client connecting to 192.168.0.200, TCP port 5001
TCP window size: 256 KByte
————————————————————
[ 4] local 192.168.1.1 port 52004 connected with 192.168.0.200 port 5001
[ 3] local 192.168.1.1 port 52003 connected with 192.168.0.200 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 562 MBytes 471 Mbits/sec
[ 3] 0.0-10.0 sec 562 MBytes 471 Mbits/sec
[SUM] 0.0-10.0 sec 1.10 GBytes 941 Mbits/sec
Die bwm-ng Anzeige unter IPFire:

htop auf IPFire wĂ€hrend der Ăbertragung:

Zweiter Test. Diesmal mit kleiner Window Size:
F:\iperf>iperf -c 192.168.0.200 -w 64k -l 64k -P2 -t 60
————————————————————
Client connecting to 192.168.0.200, TCP port 5001
TCP window size: 64.0 KByte
————————————————————
[ 4] local 192.168.1.1 port 52019 connected with 192.168.0.200 port 5001
[ 3] local 192.168.1.1 port 52018 connected with 192.168.0.200 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-60.0 sec 3.28 GBytes 469 Mbits/sec
[ 3] 0.0-60.0 sec 3.28 GBytes 469 Mbits/sec
[SUM] 0.0-60.0 sec 6.56 GBytes 939 Mbits/sec
bwm-ng:

htop:

Der Stromverbrauch lag wÀhrend dieser Tests bei 10.5 Watt im Leerlauf und 13.2 Watt unter Last.
Dritter Test. Download ISO Image aus dem Internet. Proxy und URL Filter (Ads, Adv) aktiv. Limitierung durch die max. verfĂŒgbare Internetbandbreite.
bwm-ng:

htop:

Vierter Test. OpenVPN Tunnel gegen externes IPFire Interface.
F:\iperf>iperf -c 192.168.1.200 -w 256k -l 256k -P2 -t 60
————————————————————
Client connecting to 192.168.1.200, TCP port 5001
TCP window size: 256 KByte
————————————————————
[ 4] local 10.41.21.6 port 54484 connected with 192.168.1.200 port 5001
[ 3] local 10.41.21.6 port 54483 connected with 192.168.1.200 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-60.1 sec 270 MBytes 37.7 Mbits/sec
[ 3] 0.0-60.1 sec 384 MBytes 53.7 Mbits/sec
[SUM] 0.0-60.1 sec 654 MBytes 91.3 Mbits/sec
bwm-ng:

htop:

Das Ganze nochmal mit kleiner TCP Window Size und nur einem Thread:
F:\iperf>iperf -c 192.168.1.200 -t 60
————————————————————
Client connecting to 192.168.1.200, TCP port 5001
TCP window size: 63.0 KByte (default)
————————————————————
[ 3] local 10.41.21.6 port 54489 connected with 192.168.1.200 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 681 MBytes 95.2 Mbits/sec
Und nochmal mit groĂer Window Size und einem Thread:
F:\iperf>iperf -c 192.168.1.200 -w 256k -l 256k -t 60
————————————————————
Client connecting to 192.168.1.200, TCP port 5001
TCP window size: 256 KByte
————————————————————
[ 3] local 10.41.21.6 port 54497 connected with 192.168.1.200 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.1 sec 648 MBytes 90.6 Mbits/sec
Die CPU Last variierte in beiden FĂ€llen nicht nennenswert. Es wurden keine speziellen Anpassungen der Konfiguration vorgenommen.
*Update*
FĂŒnfter Test. Download ISO Image aus dem Internet. Proxy und URL Filter (Ads, Adv) aktiv. Limitierung durch die max. verfĂŒgbare Internetbandbreite. Snort auf Rot aktiv.
bwm-ng:

htop:

Snort Settings:
Emergingthreats.net Community Rules:
community.rules
emerging-attack_response.rules
emerging-exploit.rules
emerging-malware.rules
emerging-mobile_malware.rules
emerging-trojan.rules
emerging-worm.rules