IPSec-VPN, Wert für "rp_filter"

[/dev/null]

Hallo Freunde,

Vorgeschichte:
Ich nutze schon seit mehreren openSUSE-Versionen das integrierte IPSec-VPN der Fritz!Box und den IKE-Client der Fa. Schrew-Soft. Unter anderem route ich darüber bei ext. WLAN-Nutzung den gesamten Traffic über meine heimische Box. (In meinem Lieblings-Urlaubsland DK hat niemand etwas gegen die Mitnutzung seines offenen WLAN! Selbst wenn ich frage, wird nur gelächelt und "du darfst" ... .)
Um den bestehenden Tunnel nutzen zu können ist es (nach langer Suche und gefundenen Informationen aus mehreren Foren) erforderlich, den Wert für "rp_filter" auf "0" zu setzen. Damit wird erreicht: "disable route verification on all interfaces"
Ergo: VPN, Routing usw. alles "kein Thema". Es funktioniert eben.

Problem ("gelöst", aber trotzdem eine Frage!):
Seit irgend einem Update (schon auf 11.4 oder auf Kernel 2.6.39-30-desktop, oder ???) funktioniert das nicht mehr.
=> die Datei "/etc/sysctl.d/10-network-security.conf", welche ich sonst editiert habe, existiert nicht mehr.
Kein Problem (dachte ich), dafür gibt es die "/etc/sysctl.conf, wo dieser Wert auch drin steht, und den ich von 1 auf 0 geändert habe:

# Disable response to broadcasts.
# You don't want yourself becoming a Smurf amplifier.
net.ipv4.icmp_echo_ignore_broadcasts = 1
# enable route verification on all interfaces
net.ipv4.conf.all.rp_filter = 0
# disable IPv6 completely
net.ipv6.conf.all.disable_ipv6 = 1
# enable IPv6 forwarding
#net.ipv6.conf.all.forwarding = 1
# increase the number of possible inotify(7) watches
fs.inotify.max_user_watches = 65536
# avoid deleting secondary IPs on deleting the primary IP
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1

Aber es funktioniert nicht! Unter /proc/sys/net/ipv4/conf/all/rp_filter wird dieser Wert weiterhin mit "1" angezeigt.

"Gelöst" habe ich das Problem, indem ich mit Hilfe des Startscriptes, welches als root den iked startet ("Vorstart VPN") den Wert direkt ändere:

sysctl net.ipv4.conf.all.rp_filter=0

Kurioserweise klappt es mit der Schnittstelle "all" immer noch nicht. Deshalb setze ich nacheinander mit dem Script die Werte für alle Schnittstellen auf 0 => und jetzt (erst) funktioniert es.

Ich habe dieses Problem zwar "gelöst" und kann beruhigt in Urlaub fahren, aber mich befriedigt das nicht.

Deshalb hier meine eigentlichen Fragen an die Wissenden:
1.) Warum wird der Eintrag in /etc/sysctrl.conf nicht beim Start übernommen, so wie das früher bei der "/etc/sysctl.d/10-network-security.conf" war?
2.) Welche Gründe mag es geben, dass der geänderte Wert für "all" nicht mehr ausreicht?

(Ja, ich weiß, meine Fragen sind immer recht kompliziert ... ;-) )


Mit den besten Wünschen für einen schönen Tag!

Peter

 

[josef-wien]

Wenn es "früher" funktioniert hat, dann mußt Du damals etwas unternommen haben, denn die Regelung hat sich von 11.3 auf 11.4 nicht verändert.

Standardmäßig ist in /etc/sysconfig/SuSEfirewall2 die Eintragung FW_KERNEL_SECURITY="yes" bzw. FW_KERNEL_SECURITY="" vorhanden, und das bewirkt, daß in sbin/SuSEfirewall2 (aufgerufen aus /etc/init.d/SuSEfirewall2_setup) eine Reihe von Werten in /proc gesetzt wird.

Mit sysctl setzt Du genau einen Wert (auch /etc/init.d/boot.sysctl setzt nur exakt die in /etc/sysctl.conf eingetragenen Werte).

 

[/dev/null]

Hallo Josef,

wirst es nicht glauben, aber ich habe genau von dir eine Antwort erwartet ;-)
Also vielen Dank!

Jetzt habe ich eine Richtung und weiß, wo ich weiter suchen muss.

MfG Peter

 

[spoensche]

Das wäre mir neu, dass man rp_filter auf 0 setzen muss. rp_filter dient der Spoofing protection.

 

[/dev/null]

Stimmt, damit erreichst du letztendlich dieses.
Aber nachdem der Tunnel in wenigen Sekunden stand und trotzdem nichts darüber ging, habe ich intensiv im Netz gesucht. Und ich habe an vielen Stellen gefunden, dass rp_filter ausgeschaltet werden muss. Getestet und funktioniert ... .
Ich kann mit dem daraus resultierenden Risiko leben.

Habe getestet was passiert, wenn bei laufender Verbindung der Wert auf 1 gesetzt wird => aus und vorbei. Und bei 0 läuft es wieder. Wohlgemerkt, alles bei bestehendem einmal aufgebauten Tunnel. Und, wie immer, getestet auf zwei verschiedenen Rechnern.
=> Also lasse ich es so (wenn ich nicht von irgendwo eine bessere Lösung bekomme). Ich lasse es auch so, dass ich direkt nach /proc schreibe. Damit ist diese Umschaltung mit des Start des iked verbunden. Also nur für die paar Minuten, wo ich in DK außerhäusig WLAN schnorre.

MfG Peter

 

[josef-wien]

Falls Du Dir die Kernel-Dokumentation noch nicht vorgenommen hast: außer no und strict gibt es auch noch loose.

 

[/dev/null]

Jetzt betrete ich ein Territorium, wo ich noch viele Lücken habe.
Aber ich tue es.
Danke!

edit (2 Stunden später):

Current recommended practice in RFC3704 is to enable strict mode
to prevent IP spoofing from DDos attacks. If using asymmetric routing
or other complicated routing, then loose mode is recommended.

Perfekt! Das wars wohl ... .
Und wieder was gelernt ;-)

Nochmals vielen Dank!

MfG Peter