Hi,
ich habe an meinem Speedport mit Bitswitcher FW ein NAS das auf den FTP Port 21 lauscht.
Von außen hab ich Port 3333 freigegeben und per Portforwarding auf die "interne IP" und Port 21 weitergeleitet. Das hatübrigens so bei meinem Vorgänger Router einwandfrei funktioniert.
Nur jetzt bekomm ich entweder Time Out oder Server nicht erreichbar.
IP wird über DYNDNS weitergelitet und das funktioniert auch.
Hab ich was vergessen einzustellen?
Danke
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Versuch mal ebenfalls Port 20 weiterzuleiten. Weiterhin kannst du unter Firewall->General Settings mal überprüfen ober Conntracking für FTP aktiviert ist. Als letzte Möglichkeit kannst du im Client mal noch zwischen aktiv und passiv FTP umschalten.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
funktioniert es bei dir inzwischen nach den Tipps von coolman?
Hab ein ähnliches Problem mit https über Port 9000 mit meinem
NAS und bin nun nicht sicher, ob es ein generelles Problem ist.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
bei mir hat das Port-Forwarding erst funktioniert, als ich für public und internal die gleiche Port-Nummer vergeben hab..
also "public-Port 2134 -> private-Port 21" funktionierte nicht, "21 -> 21" oder "2134 -> 2134" hingegen klappt. (mit BS 0.36)
vielleicht hilfts
Gruß, Jantle
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
leider nicht, hatte bereits verschiedene Port.Kombinationsmöglichkeiten durchprobiert, auch 443<=>443 & 9000<=>9000, ebenfalls mit BS 0.36.
Ich vermute ja, das das Port-Forwarding über den LAN-Port nicht funktioniert!? Bin aber nicht sicher, ob es daran liegt.
Kenne leider Linux nicht gut genug, um die Firewall selbst zu konfigurieren :-|
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Was sagt denn " iptables -nt nat -L" ?
Wie testest du das ganze, von "innerhalb, unter Angabe von externer IP bzw dynDNS-Name" ?
Bei mir funktioniert das nämlich nicht. Nur Zugriffe die wirklich von "draussen" erfolgen werden weitergeleitet.
Und ja, am LAN-Anschluss funktioniert das problemlos, LAN und WLAN sind ja zu einem logischen Netzerkdevice zusammengefasst: " brctl show "
Gruß,
Jantle
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> Wie testest du das ganze, von "innerhalb, unter Angabe von externer IP bzw dynDNS-Name" ?
Von innen komme ich an mein NAS im Browser per https://172.30.201.200:9000 ohne Probleme ran!
Von aussen komme ich über dyndns ebenfalls Problemlos an Bitswitcher ran : http://meinedomain.dyndns.org ,
aber leider nicht an mein NAS über https://meinedomain.dyndns.org:9000 !?
Gibt es weitere mögliche Fehlerquellen?
Poste mal bitte die Ausgabe von 'iptables -t nat -L -nv' und von 'iptables -L -nv' ein, damit man zusätzlich auch die Interface-Angaben sieht. Ausserdem werden dir da Zähler angeziegt, wo du siehst auf wieviele Pakete die entsprechende Regel gematcht hat. Daran sieht man ob eingehende Pakete tatsächlich richtig weitergeleitet werden.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
anbei die Ausgaben. Wenn ich das richtig interpretiere, so greift die Regel 443=>9000 !?
==> 25 1264 DNAT tcp - ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 to:172.30.201.200:9000
Im Browser gab ich aber https://meinedomain.dyndns.org:9000 ein! Sollte das nicht
mit Port 9000 ankommen (unter Verwendung des https-Protokolls)?
Im LAN verwende ich aber den gleichen Browser, nur mit der Adresse https://172.30.201.200:9000 . Dabei komme ich auch mit Port 9000 korrekt am NAS an! Nur https://172.30.201.200 oder nur http://172.30.201.200:9000 (http!!!) funktioniert auch im LAN nicht! (Der NAS verlangt das https-Protokoll und horcht nur auf Port 9000)
Also die Regel zieht offensichtlich für ein paar Pakete, da hast du recht. Wenn du aber von deinem Rechner aus mit dem Browser https://meinedomain.dyndns.org:9000 testest, dann kommt das Paket nicht vom externen Interface (ppp_1_32_1) sondern vom LAN Interface. Um die Weiterleitung zu testen musst du es wirklich von einem anderen Rechner aus dem Internet aus probieren, nur dann zieht die Regel. Du kannst das auch umgehen indem du bei firewall->custom_rules einfach folgendes einfuegst:
die Daten, die ich heute gesendet habe, kamen vom EXTERNEN ZUGRIFF/vom Internet. War nämlich auf Arbeit und hab versucht, von dort auf mein NAS zuzugreifen über https://meinedomain.dyndns.org:9000 - wie gesagt ohne Erfolg. Auf BitSwitcher komme ich über http://meinedomain.dyndns.org ran!
Die angebenen PREROUTING-Regeln habe ich in die Custom rules eingetragen. Der Zugriff vom LAN klappt weiterhin.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So ich habe deine Konfiguration heute nochmal nachgeprüft, bei mir funktioniert die Weiterleitung ohne Probleme,
kann also daran nicht liegen.
Ich vermute daher dass dein Problem eher dahr rührt, das dein NAS vielleicht kein Standardgateway hat?! Dann kann er natürlich nicht auf die Anfragen von ausserhalb antworten, wenn das so ist. Falls du auf dem NAS kein Standardgateway eintragen kannst, dann schalte mal NAT auch für das lokale Interface auf dem Router an:
iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ne, klappt leider auch nicht - bin am verzweifeln.
Hab mal im LAN die NAS-Verbindung gesnifft und gesehen, das für ziemlich jedes HTTPS-Paket ein neuer socket aufgemacht wird - weis aber nicht, ob das so zum Protokoll gehört.
Von außen komm ich halt immer noch nicht ran :-(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
ich habe an meinem Speedport mit Bitswitcher FW ein NAS das auf den FTP Port 21 lauscht.
Von außen hab ich Port 3333 freigegeben und per Portforwarding auf die "interne IP" und Port 21 weitergeleitet. Das hatübrigens so bei meinem Vorgänger Router einwandfrei funktioniert.
Nur jetzt bekomm ich entweder Time Out oder Server nicht erreichbar.
IP wird über DYNDNS weitergelitet und das funktioniert auch.
Hab ich was vergessen einzustellen?
Danke
Versuch mal ebenfalls Port 20 weiterzuleiten. Weiterhin kannst du unter Firewall->General Settings mal überprüfen ober Conntracking für FTP aktiviert ist. Als letzte Möglichkeit kannst du im Client mal noch zwischen aktiv und passiv FTP umschalten.
Hi lumajo,
funktioniert es bei dir inzwischen nach den Tipps von coolman?
Hab ein ähnliches Problem mit https über Port 9000 mit meinem
NAS und bin nun nicht sicher, ob es ein generelles Problem ist.
Hallo,
bei mir hat das Port-Forwarding erst funktioniert, als ich für public und internal die gleiche Port-Nummer vergeben hab..
also "public-Port 2134 -> private-Port 21" funktionierte nicht, "21 -> 21" oder "2134 -> 2134" hingegen klappt. (mit BS 0.36)
vielleicht hilfts
Gruß, Jantle
Hi Jantle,
leider nicht, hatte bereits verschiedene Port.Kombinationsmöglichkeiten durchprobiert, auch 443<=>443 & 9000<=>9000, ebenfalls mit BS 0.36.
Ich vermute ja, das das Port-Forwarding über den LAN-Port nicht funktioniert!? Bin aber nicht sicher, ob es daran liegt.
Kenne leider Linux nicht gut genug, um die Firewall selbst zu konfigurieren :-|
Was sagt denn " iptables -nt nat -L" ?
Wie testest du das ganze, von "innerhalb, unter Angabe von externer IP bzw dynDNS-Name" ?
Bei mir funktioniert das nämlich nicht. Nur Zugriffe die wirklich von "draussen" erfolgen werden weitergeleitet.
Und ja, am LAN-Anschluss funktioniert das problemlos, LAN und WLAN sind ja zu einem logischen Netzerkdevice zusammengefasst: " brctl show "
Gruß,
Jantle
>> Wie testest du das ganze, von "innerhalb, unter Angabe von externer IP bzw dynDNS-Name" ?
Von innen komme ich an mein NAS im Browser per https://172.30.201.200:9000 ohne Probleme ran!
Von aussen komme ich über dyndns ebenfalls Problemlos an Bitswitcher ran : http://meinedomain.dyndns.org ,
aber leider nicht an mein NAS über https://meinedomain.dyndns.org:9000 !?
Gibt es weitere mögliche Fehlerquellen?
Gruß,
Ralf
root@BS:~ #iptables -nt nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp - 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 to:172.30.201.200:9000
DNAT tcp - 0.0.0.0/0 0.0.0.0/0 tcp dpt:9000 to:172.30.201.200:9000
DNAT tcp - 0.0.0.0/0 0.0.0.0/0 tcp dpt:9000 to:172.30.201.200:443
DNAT tcp - 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 to:172.30.201.200:443
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all - 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
root@BS:~ #brctl show
bridge name bridge id STP enabled interfaces
br0 8000.001638e5d574 no eth0
wl0
nas_1_32
root@BS:~ #ifconfig
br0 Link encap:Ethernet HWaddr 00:16:38:E5:D5:74
inet addr:172.30.201.222 Bcast:172.30.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2395710 errors:0 dropped:0 overruns:0 frame:0
TX packets:4073678 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:194239986 (185.2 MiB) TX bytes:1266024519 (1.1 GiB)
eth0 Link encap:Ethernet HWaddr 00:16:38:E5:D5:74
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:16317 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:2219213 (2.1 MiB)
Interrupt:28 Base address:0x6000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1002 (1002.0 B) TX bytes:1002 (1002.0 B)
nas_1_32 Link encap:Ethernet HWaddr 00:16:38:E5:D5:76
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4098992 errors:0 dropped:0 overruns:0 frame:0
TX packets:2389001 errors:0 dropped:16378 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1242913336 (1.1 GiB) TX bytes:267508783 (255.1 MiB)
ppp_1_32_ Link encap:Point-to-Point Protocol
inet addr:xxx.xxx.xxx.xxx P-t-P:xxx.xxx.xxx.xxx Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:301396 errors:0 dropped:0 overruns:0 frame:0
TX packets:182367 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:392682741 (374.4 MiB) TX bytes:14048987 (13.3 MiB)
wl0 Link encap:Ethernet HWaddr 00:16:38:E5:D5:75
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2397071 errors:0 dropped:0 overruns:0 frame:4817715
TX packets:4090581 errors:163 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:228984800 (218.3 MiB) TX bytes:1302067059 (1.2 GiB)
Interrupt:32
Poste mal bitte die Ausgabe von 'iptables -t nat -L -nv' und von 'iptables -L -nv' ein, damit man zusätzlich auch die Interface-Angaben sieht. Ausserdem werden dir da Zähler angeziegt, wo du siehst auf wieviele Pakete die entsprechende Regel gematcht hat. Daran sieht man ob eingehende Pakete tatsächlich richtig weitergeleitet werden.
Hallo coolman,
anbei die Ausgaben. Wenn ich das richtig interpretiere, so greift die Regel 443=>9000 !?
==> 25 1264 DNAT tcp - ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 to:172.30.201.200:9000
Im Browser gab ich aber https://meinedomain.dyndns.org:9000 ein! Sollte das nicht
mit Port 9000 ankommen (unter Verwendung des https-Protokolls)?
Im LAN verwende ich aber den gleichen Browser, nur mit der Adresse https://172.30.201.200:9000 . Dabei komme ich auch mit Port 9000 korrekt am NAS an! Nur https://172.30.201.200 oder nur http://172.30.201.200:9000 (http!!!) funktioniert auch im LAN nicht! (Der NAS verlangt das https-Protokoll und horcht nur auf Port 9000)
Gruß,
Ralf
Web-Shell> iptables -t nat -L -nv
Chain PREROUTING (policy ACCEPT 4214 packets, 585K bytes)
pkts bytes target prot opt in out source destination
25 1264 DNAT tcp - ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 to:172.30.201.200:9000
0 0 DNAT tcp - ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9000 to:172.30.201.200:9000
0 0 DNAT tcp - ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9000 to:172.30.201.200:443
0 0 DNAT tcp - ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 to:172.30.201.200:443
Chain POSTROUTING (policy ACCEPT 28 packets, 1760 bytes)
pkts bytes target prot opt in out source destination
111 8262 MASQUERADE all - * ppp_1_32_1 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Web-Shell> iptables -L -nv
Chain INPUT (policy DROP 21036 packets, 2118K bytes)
pkts bytes target prot opt in out source destination
21536 2412K ACCEPT all - lo * 0.0.0.0/0 0.0.0.0/0
24671 1897K ACCEPT all - br0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all - wl0 * 0.0.0.0/0 0.0.0.0/0
14865 2003K ACCEPT all - * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
21828 2167K SERVICES_INPUT all - ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0
21609 2155K PORTFW_INPUT all - ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0
573 36364 ACCEPT icmp - ppp_1_32_1 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
6091 4284K TIME_FILTER all - * * 0.0.0.0/0 0.0.0.0/0
274 16280 TCPMSS tcp - * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
482K 410M TIME_FILTER all - * * 0.0.0.0/0 0.0.0.0/0
2191K 1930M TIME_FILTER all - * * 0.0.0.0/0 0.0.0.0/0
4452K 3961M TIME_FILTER all - * * 0.0.0.0/0 0.0.0.0/0
6109K 5435M TIME_FILTER all - * * 0.0.0.0/0 0.0.0.0/0
6422K 5697M TIME_FILTER all - * * 0.0.0.0/0 0.0.0.0/0
6422K 5697M TIME_FILTER all - * * 0.0.0.0/0 0.0.0.0/0
111K 5623K TCPMSS tcp - * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU
2364K 192M PORT_AND_WEB_FILTER all - * ppp_1_32_1 0.0.0.0/0 0.0.0.0/0
6363K 5694M ACCEPT all - * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
20 1040 ACCEPT all - br0 br0 0.0.0.0/0 0.0.0.0/0
59004 2973K ACCEPT all - br0 ppp_1_32_1 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT all - wl0 wl0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all - wl0 ppp_1_32_1 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT all - br0 wl0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all - wl0 br0 0.0.0.0/0 0.0.0.0/0
123 6276 ACCEPT tcp - * * 0.0.0.0/0 172.30.201.200 tcp dpt:9000
0 0 ACCEPT tcp - * * 0.0.0.0/0 172.30.201.200 tcp dpt:9000
0 0 PORT_AND_WEB_FILTER all - * ppp_1_32_1 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all - * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all - br0 br0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all - br0 ppp_1_32_1 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT all - wl0 wl0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all - wl0 ppp_1_32_1 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT all - br0 wl0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all - wl0 br0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp - * * 0.0.0.0/0 172.30.201.200 tcp dpt:9000
0 0 ACCEPT tcp - * * 0.0.0.0/0 172.30.201.200 tcp dpt:9000
0 0 ACCEPT tcp - * * 0.0.0.0/0 172.30.201.200 tcp dpt:443
0 0 ACCEPT tcp - * * 0.0.0.0/0 172.30.201.200 tcp dpt:443
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
21536 2412K ACCEPT all - * lo 0.0.0.0/0 0.0.0.0/0
59143 6494K ACCEPT all - * br0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all - * wl0 0.0.0.0/0 0.0.0.0/0
15836 1359K ACCEPT all - * * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED
Chain PORTFW_INPUT (1 references)
pkts bytes target prot opt in out source destination
4034 574K RETURN all - * * 0.0.0.0/0 0.0.0.0/0
Chain PORT_AND_WEB_FILTER (2 references)
pkts bytes target prot opt in out source destination
2451 312K RETURN all - * * 0.0.0.0/0 0.0.0.0/0
Chain SERVICES_INPUT (1 references)
pkts bytes target prot opt in out source destination
102 5184 ACCEPT tcp - * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 state NEW
117 7000 ACCEPT tcp - * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23 state NEW
21609 2155K RETURN all - * * 0.0.0.0/0 0.0.0.0/0
Chain TIME_FILTER (7 references)
pkts bytes target prot opt in out source destination
26M 23G RETURN all - * * 0.0.0.0/0 0.0.0.0/0
0 0 RETURN all - * * 0.0.0.0/0 0.0.0.0/0
0 0 RETURN all - * * 0.0.0.0/0 0.0.0.0/0
0 0 RETURN all - * * 0.0.0.0/0 0.0.0.0/0
0 0 RETURN all - * * 0.0.0.0/0 0.0.0.0/0
0 0 RETURN all - * * 0.0.0.0/0 0.0.0.0/0
0 0 RETURN all - * * 0.0.0.0/0 0.0.0.0/0
Also die Regel zieht offensichtlich für ein paar Pakete, da hast du recht. Wenn du aber von deinem Rechner aus mit dem Browser
https://meinedomain.dyndns.org:9000 testest, dann kommt das Paket nicht vom externen Interface (ppp_1_32_1) sondern vom LAN Interface. Um die Weiterleitung zu testen musst du es wirklich von einem anderen Rechner aus dem Internet aus probieren, nur dann zieht die Regel. Du kannst das auch umgehen indem du bei firewall->custom_rules einfach folgendes einfuegst:
iptables -t nat -I PREROUTING -p tcp -dport 9000 -j DNAT -to-destination 172.30.201.200:9000
#nur nochmal zur Sicherheit
iptables -I FORWARD -d 172.30.201.200 -p tcp -dport 9000 -j ACCEPT
Diese Regel(n) sollte dann auch für interne Pakete ziehen und kann im LAN getestet werden,
da kein Input-Interface angegeben ist.
Hallo,
die Daten, die ich heute gesendet habe, kamen vom EXTERNEN ZUGRIFF/vom Internet. War nämlich auf Arbeit und hab versucht, von dort auf mein NAS zuzugreifen über https://meinedomain.dyndns.org:9000 - wie gesagt ohne Erfolg. Auf BitSwitcher komme ich über http://meinedomain.dyndns.org ran!
Die angebenen PREROUTING-Regeln habe ich in die Custom rules eingetragen. Der Zugriff vom LAN klappt weiterhin.
So ich habe deine Konfiguration heute nochmal nachgeprüft, bei mir funktioniert die Weiterleitung ohne Probleme,
kann also daran nicht liegen.
Ich vermute daher dass dein Problem eher dahr rührt, das dein NAS vielleicht kein Standardgateway hat?! Dann kann er natürlich nicht auf die Anfragen von ausserhalb antworten, wenn das so ist. Falls du auf dem NAS kein Standardgateway eintragen kannst, dann schalte mal NAT auch für das lokale Interface auf dem Router an:
iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
Ne, klappt leider auch nicht - bin am verzweifeln.
Hab mal im LAN die NAS-Verbindung gesnifft und gesehen, das für ziemlich jedes HTTPS-Paket ein neuer socket aufgemacht wird - weis aber nicht, ob das so zum Protokoll gehört.
Von außen komm ich halt immer noch nicht ran :-(