Schlagwort-Archive: iptables

Interfacebasiertes OpenVPN-Routing und martian packets

Ab und an sehen meine Wünsche recht speziell aus, ich weiß. Heut sieht die Aufgbe wie folgt aus:

Ein Router besitzt 3 Netzwerkkarten, eth0 ist direkt an das Internet angeschlossen, eth1 versogt das Netzwerk A und eth2 das Netzwerk B. Zusätzlich gibt es über OpenVPN (tap0) einen Link zu einem externen Internetzugang. Ziel ist nun, dass alle Internetanfragen von Netzwerk B (eth2) über das VPN versendet werden, der Rest jedoch nicht.

Der (zusammenkopierte) Entwurf lautete wie folgt:

iptables -t mangle -A PREROUTING -i eth2 -j MARK --set-xmark 0x1/0xffffffff
-> Alles was aus Netzwerk B kommt wird mit Flag 0x1 versehen

iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE
-> Alles was über tap0 raus geht wird per NAT maskiert

ip route add unreachable default table 42
-> Alles auf der Routingtabelle 42 wird per default abgelehnt

ip rule add from all fwmark 0x1 table 42
-> Alles mit der Markierung 0x1 gehört zur Tabelle 42

ip route replace 0.0.0.0/1 via *OpenVPN-IP* table 42
ip route replace 128.0.0.0/1 via *OpenVPN-IP* table 42
-> Alles auf Tabelle 42 wird über den VPN-Server abgewickelt

net.ipv4.ip_forward ist auf 1

Auf den ersten Blick ist auch alles OK, Netzwerk A und der Server funktionieren fehlerfrei. Vom Netzwerk B ist jedoch kein Internetzugriff möglich. Getreu dem guten alten Troubleshooting-Guide also auf die Suche.

Wenn ich von einem Client in Netzwerk B pinge kommt das Paket am Router auf eth2 an:

[eth2] 10.222.100.53 > 8.8.8.8: ICMP echo request

…und wird auf tap0 nach draußen gesendet:

[tap0] 10.8.0.16 > 8.8.8.8: ICMP echo request

Kurz drauf trifft auch von draußen über das VPN eine Antwort ein:

[tap0] 8.8.8.8 > 10.8.0.16: ICMP echo reply

und dann hing es… Die Antwort wird nicht auf eth2 wieder weitergegeben, dort ist kein Traffic erkennbar. Scheint, als ob irgendwas beim NAT schief geht. Wenn ich logging auf Maximum stelle (net.ipv4.conf.tap0.log_martians=1) ist im syslog folgendes zu lesen:

kernel: IPv4: martian source 10.222.100.53 from 8.8.8.8, on dev tap0

Ich vermute, dass hier das NAT durch die verschiedenen Routing-Tabellen ein zu großes Chaos verursacht. Als „Workarround“ ist auf dem VPN-Interface jetzt Source-Filterung ausgeschaltet (net.ipv4.conf.tap0.rp_filter=0). Da die Gegenseite ohnehin nochmals nattet sollte da nichts böses(™) drüber eintrudeln.

Sollte jemand genauer erklären können was hier passiert freue ich mich über einen Kommentar.