IPsec-Verkehr war beim Linux-Kernel 2.6 bisher weitaus schwieriger zu filtern als noch unter 2.4. Seit Ende März 2006 klappt mit den aktuellen Versionen von Kernel und IPtables das Zusammenspiel endlich wieder reibungslos: Das Policy-Match und ein Patch von McHardy machen's möglich.

SNAT

Das virtuelle Interface hatte noch einen weiteren wichtigen Vorteil: Die Firewall konnte die unverschlüsselten Pakete, bevor sie sie durch den Tunnel schickte, mit Source-NAT behandeln. Hierzu genügte folgende Regel:

iptables -t nat -A POSTROUTING -o ipsec0 -j MASQUERADE

SNAT ist etwa nötig, wenn der Tunnel nur die IP-Adresse des VPN-Clients zulässt, aber weitere Rechner hinter dem Client das VPN nutzen sollen. Ein weiteres Einsatzszenario ist ein VPN, das zwei Netzwerke mit identischen privaten Adressen verbindet. Dann ist sogar ein NAT in beiden Richtungen nötig (Twice-NAT). Mit dem Kernel 2.6 klappte dies zunächst nicht, da die Pakete beim Erreichen der NAT-Postrouting-Kette bereits verschlüsselt sind (Abbildung 3).

Abbildung 3: Da der Linux-Kernel 2.6 die IPsec-Pakete bereits vor der Postrouting-Kette verschlüsselt, scheitert das oft nötige Source-NAT. Erst neue Kernelpatches umgehen diese Hürde.

Patrick McHardy hat aber einige Patches geschrieben [2], die unter anderem dafür sorgen, dass Pakete die Postrouting-Kette zweimal durchlaufen. Zunächst wandert das Klartextpaket durch alle Ketten. Anschließend durchläuft es verschlüsselt die IPtables-Ketten, als sei es ein lokal erzeugtes Paket. Es beginnt mit den Output-Chains und betritt dann Postrouting.

So kann NAT sowohl das Klartextpaket vor seiner Verschlüsselung als auch das verschlüsselte Paket in den Postrouting-Ketten behandeln. SNAT ist nun möglich. Diese Patches waren bis vor kurzem noch nicht funktionstüchtig, aber seit Linux-Kernel 2.6.16 sind sie fester und funktionierender Bestandteil. Ein Patch ist nicht mehr erforderlich. Einige Distributionen (etwa Fedora Core 5) haben diese Patches auch schon in den Distributions-Kernel 2.6.15 eingebaut. Folgende einfache Regel maskiert Pakete, die durch einen IPsec-Tunnel wandern:

iptables -t nat -A POSTROUTING -p tcp -m policy --dir out -j MASQUERADE

Durch diese neue Entwicklung gibt es nun keinen objektiven Grund mehr, das Upgrade eines VPN-Gateway von Kernel 2.4 auf Kernel 2.6 zu fürchten. Natürlich ist eine Anpassung der Firewallregeln erforderlich. Der Lohn für diese Mühe sind viele weitere Vorteile des Kernels 2.6 auf der Firewall. Sicherheitslösungen wie App Armor oder SE Linux stehen nur für den Kernel 2.6 zur Verfügung.

Zukunftsträchtig

Auf lange Sicht werden sicherlich auch Anbieter von Linux-VPN- und Firewall-Lösungen den Wechsel auf Kernel 2.6 vollziehen. Bisher war das Fehlen der virtuellen »ipsecX«-Netzwerkkarten häufig ein K.-o.-Kriterium. Das Policy-Match ersetzt zusammen mit den McHardy-Modifikationen die alte Architektur aber vollständig und erweitert sogar die Einflussmöglichkeiten der Firewall. (fjl)

Der Autor
Ralf Spenneberg arbeitet als freier Unix/Linux-Trainer, Berater und Autor. Er veröffentlicht Bücher zu den Themen Intrusion Detection und Virtuelle Private Netzwerke. Vor wenigen Wochen ist sein neues Werk "Linux Firewalls mit IPtables & Co" erschienen.

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.

IPsec-Verkehr war beim Linux-Kernel 2.6 bisher weitaus schwieriger zu filtern als noch unter 2.4. Seit Ende März 2006 klappt mit den aktuellen Versionen von Kernel und IPtables das Zusammenspiel endlich wieder reibungslos: Das Policy-Match und ein Patch von McHardy machen's möglich.