AVM-Firewall / iptables - Forward-Problem

[JohnDoe42]

Hallo zusammen,

ich plage mich seit geraumer Zeit mit einem (möglicherweise banalen) Problemchen herum, allerdings will mir einfach der Fehler nicht auffallen. Deshalb wollte ich Euch kurz bitten, dazu was zu schreiben.
Also:
Ich betreibe im Netz der Box (7170 Fon WLAN) einige Webserver, desweiteren läuft iptables auf der Box. Nun möchte ich mit einem mobilen Endgerät auf jeden dieser Webserver zugreifen. Zwar läuft auf der Box auch ein funktionierender OpenVPN-Server, aber für das Endgerät existiert, zumindest nach meinem Kenntnisstand, kein TAP-Device ohne viel Bastelei. Ebenso möchte ich den Servern keine eigene DynDNS-Addi geben. Daher ist mein Plan der folgende: Ich möchte für jeden der Server einen eigenen Port auf der FB freigeben und diesen jeweiligen Port dann per Forwarding an den jeweiligen Server durchreichen. Und genau das klappt nicht, ich bekomme überhaupt keine Verbindung zur Box. Das Ganze soll also beispielsweise so laufen:

http://meinedyndns-addi.com:8081 -> FB -> Server1:80
http://meinedyndns-addi.com:8082 -> FB -> Server2:80
usw.

und zurück.
Hier mal die betreffenden Auszüge meiner iptables-Regeln:

iptables -A INPUT -p tcp -s *.*.*.* -m multiport --dport 80,81,8081,8082,8083 -j ACCEPT
iptables -A OUTPUT -p tcp -s iptables -A OUTPUT -p tcp -s *.*.*.* -m multiport --dport 80,81,8081,8082,8083 -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --sport 80,8081,8082,8082 -j ACCEPT

Hier die Forward-Rules:

Hat jemand eine Idee, warum die Verbindung fehlschlägt ?
Grüße,

JD.

 

[RalfFriedl]

Keine Ahnung, wie Du auf die Idee kommst, mit diesen iptables Regeln irgend etwas zu bewirken.

Entferne die iptables Regeln und trage die Portfreigaben im AVM Interface ein, dann sollte das funktionieren.

 

[JohnDoe42]

Wenn ich mit einem mobilen Endgerät z.B. auf meineip,com:8083 zugreife und z.B. die Forward-Regel nicht existiert, wie soll denn dann das Routing zum Webserver überhaupt zustande kommen (die Default Policy ist im INPUT- und im FORWARD-Zweig DROP) ? Ohne die Regeln funktioniert es jedenfalls nicht.

 

[µRaCoLi]

INPUT und OUTPUT haben damit nichts zu tun. Wenn du in der AVM-Firewall (denn daran muss der Verkehr ja auch noch vorbei) ein Port forwarding eintraegst, dann wirst du in der FORWARD chain nur noch port 80 sehen.

 

[RalfFriedl]

die Default Policy ist im INPUT- und im FORWARD-Zweig DROP

Ich habe auch nicht geschrieben, dass Du es im AVM Interface eintragen und über iptables blockieren sollst. Über das AVM Interface kann man die Weiterleitung einrichten, dafür braucht man kein iptables.

 

[JohnDoe42]

iptables laufen nun aber mal auf der Box, und die von mir benutzten Regeln möchte ich auch behalten.
Oder soll ich Deiner Meinung nach iptables für mein Vorhaben wieder von der Box nehmen, weil dieses mit iptables so nicht funktioniert ?

 

[µRaCoLi]

Nimm fuer DNAT die AVM-Firewall und fuers Weiterleiten die FORWARD chain von iptables!

 

[Lauser71]

Hallo JohnDoe42,
doch es geht mit Iptables. Warum entfernst Du nicht wieder Iptables oder liest dich vernünftig darin ein?
Eine Weiterleitung geht auch mit der AVM Firewall dazu braucht man keine Iptables.

Nachtrag:
Habe mir das Buch von Andreas Lessing: Linux Firewalls – Ein praktischer Einstieg gekauft.
Etwas älter aber sehr hilfreich.

 

[RalfFriedl]

Oder soll ich Deiner Meinung nach iptables für mein Vorhaben wieder von der Box nehmen, weil dieses mit iptables so nicht funktioniert ?

Du kannst auch die iptables auf der Box lassen. Es reicht, wenn Du sie so anpasst, dass sie die Weiterleitung nicht blockieren.

 

[JohnDoe42]

Du kannst auch die iptables auf der Box lassen. Es reicht, wenn Du sie so anpasst, dass sie die Weiterleitung nicht blockieren.

Ich habe iptables nicht wegen sondern trotz dieses Problems auf der Box. Mir ist klar, daß ich die Portweiterleitung auch mit iptables realisieren kann, allerdings hab' ich nun halt mal die AVM-Firewall benutzt. Ich kann auch eine Lösung meines Problems erzeugen, indem ich speziell die default policy in der FORWARD-CHAIN auf ACCEPT setze.
Allerdings ist es genau das, was ich (wie ich hoffe aus naheliegenden Sicherheitsaspekten ersichtlich) gerne vermeiden möchte.
Gibt es denn niemanden, der für die in Post 1 genannte Kette 8081->80->8081 eine (funktionierende) iptables-Regel kennt ?
Grüße,

JD.

 

[RalfFriedl]

Mit AVM läuft einiges nicht so, wie es normal mit iptables laufen würde.

Setze einfach mal in alle Relevanten Chains am Ende ein LOG-Target hinein, dann siehst Du, was durch die Chains geht. Dann weißt Du auch, wie die Regeln aussehen müssen, um diese Pakete durch zu lassen.

 

[JohnDoe42]

Setze einfach mal in alle Relevanten Chains am Ende ein LOG-Target hinein, dann siehst Du, was durch die Chains geht. Dann weißt Du auch, wie die Regeln aussehen müssen, um diese Pakete durch zu lassen.

Gute Idee, hätte ich auch d'rauf kommen können.
Die Pakete scheinen an der INPUT-Chain zu scheitern:

[IPT] DENY-LAN-ACCESSIN=dsl OUT=lan SRC=*.*.*.* DST=192.168.178.23 LEN=64 TOS=0x00 PREC=0x00 TTL=53 ID=7315 DF PROTO=TCP [B]SPT=38823[/B] DPT=80 WINDOW=33580 RES=0x00 SYN URGP=0

Eigenartigerweise lautet die Regel, von der ich dachte, daß sie genau dieses Paket durchläßt, so:

iptables -A INPUT -p tcp -s *.*.*.* -m multiport --dport 80,81,8081,8082,8083 -j ACCEPT

Was mich nun irritiert ist der Source-Port 38823, obwohl ich explizit Port 8081, wie in Port 1 beschrieben, in die Adresszeile des Browsers getippt hatte.
Woeran kann das denn liegen ?
Grüße,

JD:

 

[RalfFriedl]

Wie Du oben schon geschrieben hast, geht es, wenn Du FORWARD auf ACCEPT setzt. Was bringt Dich dann auf die Idee, dass das Problem an der INPUT Regel liegen könnte? FORWARD auf DENY zu setzen ist übrigens bei weitem nicht so naheliegend, wie Du es weiter oben darstellst. Was konkret ist Deiner Meinung nach der Vorteil, FORWARD auf DENY zu setzen?

Ich vermute, dass es nicht an der INPUT Chain liegt. Du könntest das aber überprüfen, indem Du verschiedene Labels auf die verschiedenen Chains setzt.

Was ist denn so seltsam an dem Source-Port? Es scheint, dass Du eine falsche Vorstellung davon hast, was Source-Port bei FORWARD bedeutet. Ich komme doch noch auf meinen Vorschlag zurück, iptables komplett zu entfernen, oder zumindest eine Beschreibung von iptables zu lesen, evtl. die von Lauser71 empfohlene, oder auch einfach die man-Page.

 

[JohnDoe42]

Okay, ich hab' 's dann alleine gelöst:
Ein

iptables -A FORWARD -p tcp --dport 80 -j ACCEPT
iptables -t nat -A POSTROUTING  -p tcp -o dsl --dport 8080:8083 -j MASQUERADE

zusätzlich zu meinen Regeln tut das, was ich möchte.
Die Ports 8080-8083 in INPUT- und OUTPUT-Chain waren in der Tat überflüssig.
Grüße,

JD.

 

[RalfFriedl]

Gibt es einen speziellen Grund für die zweite Regel?

 

[JohnDoe42]

Ich war nicht sicher, ob das AVM-Portforwarding das Masquerading übernimmt.
Deshalb die zweite Regel.

 

[RalfFriedl]

Wenn das AVM Portforwarding es nicht tun würde, würde diese zweite Regel es auch nicht tun.

Außerdem würde AVM kein Portforwarding ins Web Interface einbauen, wenn es nicht funktionieren würde.

 

[JohnDoe42]

Ich schrieb ja auch nicht von Portforwarding, sondern vom Masquerading.
Und was genau ist Deiner Meinung nach an der zweiten Regel falsch ?

 

[RalfFriedl]

Zumindest tut die Regel nichts sinnvolles. Ob sie auch stört, hängt davon ab, wie im Detail die Implementierung von AVM ist.

Die Regel besagt, dass iptables für Pakete, die über das dsl Interface nach draußen gehen und einen externen Zielport 8080-8083 haben, MASQUERADE aufrufen soll, also als NAT-Router funktionieren soll. Das aber tut der AVM Teil bereits für alle Ports, also auch für diese Ports. Wenn Du Pech hast, kommt es zu Problemen wegen dem doppelten Masqerading durch iptables und AVM, im besten Fall ist die Regel unnötig.

 

[JohnDoe42]

Das aber tut der AVM Teil bereits für alle Ports, also auch für diese Ports. Wenn Du Pech hast, kommt es zu Problemen wegen dem doppelten Masqerading durch iptables und AVM, im besten Fall ist die Regel unnötig.

Da ich, wie ich oben schrieb, nicht sicher war, ob der AVM-Teil das Masquerading, also das ersetzen der lokalen IP durch seine öffentliche I-Net-IP, übernimmt, hatte ich die Regel mal dazu geschrieben. Und da dies zum einen nicht mit dem AVM-Teil kollidierte und zum zweiten das ganze auch ohne meine Regel funktionierte (diese also in Deinen Worten unnötig ist), hab' ich sie wieder entfernt.