Port Forwarding + Load Balancing

[lanwahn]

Hallo zusammen!

Ich habe gerade folgende Situation und werde aus dem Verhalten des Routers (oder au meinem) nicht schlau:
Router 1781VA LCOS 9.10
2 WAN-Verbindungen (1 über das interne Modem + 1 über ein externes Modem)
Beide WAN-Verbindungen sind über einen Load-Balancer des LANCOM zusammengefasst.
Funktioniert soweit auch wunderbar.
Nun möchte ich Port-Forwarding zu einem Gerät in meinem LAN einrichten. Allerdings muss dieser Host immer über die gleiche WAN-Verbindung erreichbar sein sowie natürlich auch ausschließlich nur über diese Verbindung mit dem Client kommunizieren.
Wenn ich das nun aber tue, ist der gewünschte Host nicht durch den Port erreichbar.
Habe auch schon mit dem Policy Based Routing versucht, über die Firewall für Pakete des Hosts den Routing-Tag 1 zu setzen, welche in meiner Routing-Tabelle der WAN-Verbindung entspricht, über welche ich gerne den Server erreichen möchte.
Im Log sehe ich wie meine Regel angewendet wird => Verbindung geht nur noch über diese WAN-Verbindung, allerdings nur solange, bis ein Client von außerhalb über einen offenen Port zugreifen möchte, dann kommt er nicht mehr durch den Port.

Habe ich etwas übersehen ?

[powder8]

Hy,

IP Router -> Maskierung -> Port

Hier kannst du die Gegenstelle auswählen.

Bei einer deny all muss hier die Firewall auch geändert werden.

Gruß

[lanwahn]

Danke schon mal für die Antwort.

Unter der genannten Option gibt es nur eine Option namens "Port Forwarding".
Habe dort auch den Port eingetragen sowie die IP des Servers.
Nur ändert sich nichts daran: Der Port bleibt geschlossen...
In meiner Firewall arbeite ich mit einer DENY-ALL-Regel, aber dort scheinen die Daten durchzugehen, wenn der Server von sich aus eine Verbindung zum Client aufbaut. Ich kann jedenfalls keine Regel sehen, welche dort Pakete verwirft, bzw. zurückweist.

Ich habe jetzt schon beim Port Forwarding mal den Load Balancer und zusätzlich die gewünschte WAN-Verbindung eingetragen, macht das überhaupt einen Unterschied?
Ich habe alle Kombinationen durch, es ändert sich aber von außen nichts...

Ich würde gerne wissen, wie der sich da genau verhält und welche weitere Rolle das dann das Client Binding spielt (wenn man es aktiviert hätte)...

Danke schon mal!

[powder8]

Hy,

klar Port Forwarding. Hier mal ein Link zu Lancom

https://www2.lancom.de/kb.nsf/bf0ed2a4d ... enDocument

Wenn das soweit läuft dann mal einen Trace der Firewall laufen lassen.

Klappt das denn im LAN? Läuft auf der Maschine evtl. eine eigene Firewall?

[ecox]

Hi,

also wie richtest du denn Loadbalancer ein? Seit der 9.10 gibt es ja Client Binding, kannst also alles über Tag 0 laufen lassen, teste das gerade ausgiebig, scheint gut zu funktionieren. Kannst also ansich alle Regeln diesbezüglich löschen oder halt deaktivieren und testen.

Wählst du beim Port-Forwarding auch die Gegenstelle aus über die der Server oder was auch immer erreichbar sein soll?

Im Normalfall sollte das eigentlich klappen. Welche Ports willst du denn wohin mappen, gib mal mehr Details

[lanwahn]

Also folgendes:

Das Client Binding habe ich bei mir aktuell deaktiviert.
Aktuell verteilt der Load Balancer die Daten gleichmäßig, außer bei HTTPS, da habe ich eine WAN Verbindung definiert (unschöne Logouts...)
Ich möchte nun den Port 9001 und 9030 auf die interne IP 192.168.2.2/16 weiterleiten.

Das sieht dann in der Port-Forwarding-Tabelle so aus:

Anfangs-Port 9001
End-Port 9001
Gegenstelle TELEKOM (Die Gegenstelle, welche ich gerne hierfür ausschließlich hätte)
Adresse 192.168.2.2
Map-Port 0
Protokoll TCP
WAN-Adresse 0.0.0.0

Anfangs-Port: 9030
End-Port: 9030
Gegenstelle: TELEKOM (Die Gegenstelle, welche ich gerne hierfür ausschließlich hätte)
Adresse: 192.168.2.2
Map-Port: 0
Protokoll: TCP
WAN-Adresse: 0.0.0.0

Firewall-Regel:

<Weitere Regeln>

Name: ALLOW TORSERVER_IN
Quelle: Beliebig
Quell-Dienst: Alle
Ziel: TORSERVER (192.168.2.2)
Ziel-Dienst: TORSERVICE (Port 9001, 9030 TCP)
Aktion: Übertragen

Name: ALLOW TORSERVER_OUT
Quelle: TORSERVER (192.168.2.2)
Quell-Dienst: Alle
Ziel: INTERNET (enthält die Gegenstelle TELEKOM sowie auch den Load-Balancer)
Ziel-Dienst: Alle
Aktion: Markieren (und auch übertragen)
=> Hier setze ich dann den Routing Tag 1

<Weitere Regeln>
<DENY_ALL>

Routing-Tabelle:

<VPN-Verbindungen>
<Multicast blockieren>
IP-Adresse: 255.255.255.255
Netzmaske: 0.0.0.0
Tag: 1
Schaltzustand: An, Sticky für RIP
Router: TELEKOM
Distanz: 0
Mask.: An

IP-Adresse: 255.255.255.255
Netzmaske: 0.0.0.0
Tag: 0
Schaltzustand: An, Sticky für RIP
Router: INTERNET (Load-Balancer)
Distanz: 0
Mask.: An


Also der Server hat bereits mehrere Monate, als nur eine Route vorhanden war, wunderbar Daten getunnelt. Ein Problem im LAN kann ich an sich ausschließen, der Server ist erreichbar und das Log zeigt dauernd an, das die Ports nicht erreichbar wären, was tatsächlich auch so ist.

Ich hoffe, man kann damit etwas anfangen.
Schon mal vielen Dank !


Gruß,

lanwahn

[ecox]

Hallo,

du mappst also den Port 9001 und 9030 auf Port 0 im LAN? Schau mal den Screenshot an!

mfg

ecox

[powder8]

Hy,

sofern der Map port = Anfangsport ist, kann auf diesen Eintrag verzichtet werden. Hier sollte dann TCP / UDP Aktiv sein.

Die Frage bleibt: Intern antwortet der Server auf Port 9001 und 9030 ?

[backslash]

Hi lanwahn,

Name: ALLOW TORSERVER_OUT
Quelle: TORSERVER (192.168.2.2)
Quell-Dienst: Alle
Ziel: INTERNET (enthält die Gegenstelle TELEKOM sowie auch den Load-Balancer)
Ziel-Dienst: Alle
Aktion: Markieren (und auch übertragen)
=> Hier setze ich dann den Routing Tag 1

Hier sollte als Ziel "alle Stationen" stehen und nicht "INTERNET", denn durch das Umtaggen matcht das Ziel "INTERNET" nicht mehr...

Gruß
Backslash

[lanwahn]

Also noch mal zum Server an sich:
Hier mal ein nmap vom Server lokal:

Code: Alles auswählen

Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-08-20 19:00 Mitteleuropäische Sommerzeit
NSE: Loaded 122 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 19:00
Completed NSE at 19:00, 0.00s elapsed
Initiating NSE at 19:00
Completed NSE at 19:00, 0.00s elapsed
Initiating ARP Ping Scan at 19:00
Scanning 192.168.2.2 [1 port]
Completed ARP Ping Scan at 19:00, 0.25s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 19:00
Completed Parallel DNS resolution of 1 host. at 19:00, 0.17s elapsed
Initiating SYN Stealth Scan at 19:00
Scanning 192.168.2.2 [2 ports]
Discovered open port 9030/tcp on 192.168.2.2
Discovered open port 9001/tcp on 192.168.2.2
Completed SYN Stealth Scan at 19:00, 0.00s elapsed (2 total ports)
Initiating Service scan at 19:00
Scanning 2 services on 192.168.2.2
Completed Service scan at 19:00, 20.08s elapsed (2 services on 1 host)
Initiating OS detection (try #1) against 192.168.2.2
NSE: Script scanning 192.168.2.2.
Initiating NSE at 19:00
Completed NSE at 19:00, 9.35s elapsed
Initiating NSE at 19:00
Completed NSE at 19:00, 0.00s elapsed
Nmap scan report for 192.168.2.2
Host is up (0.013s latency).
PORT     STATE SERVICE        VERSION
9001/tcp open  ssl/tor-orport Tor 0.2.4.11 or later (supported protocol versions: 3, 4)

Das SSL-Zertifikat kann nmap auch auslesen und im Log des Servers steht folgendes:

Aug 20 19:05:52.000 [warn] Your server (<die TELEKOM-IP>:9030) has not managed to confirm that its DirPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

Die Namensauflösung an sich funktioniert auch auf dem System.
@backslash: Habe die Regel bearbeitet, macht aber aktuell keinen Unterschied...
Im Port Forwarding steht als Gegenstelle weiterhin TELEKOM.

Die Firewall-Ereignisse sehen auch gut aus, es kommen Daten rein (ALLOW_TORSERVER_IN), und kurz danach wieder raus (ALLOW_TORSERVER_OUT).

Gerade eben hat der Tor-Server wieder eine Log-Nachricht hinterlassen:
Aug 20 19:38:20.000 [warn] Your server (<TELEKOM-WAN-IP>:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
Aug 20 19:38:20.000 [warn] Your server (<TELEKOM-WAN-IP>:9030) has not managed to confirm that its DirPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc

PS: Noch jemand eine andere Idee, was bei der Kombi Port Forwarding, Load Blancing und Policy Based Routing noch schiefgehen könnte?
Oder steh ich mir gerade selbst im Weg...