Probleme bei neuem Failover mit MultiWAN
-
Morgen zusammen!
Ich teste mit einem Kollegen gerade an einem 2-WAN Standort (1x Kabel, 1x QSC) eine Multi-WAN Konfiguration. So weit so gut, FailOver mit neuer Konfiguration ist wirklich fein zu konfigurieren. Wir haben derer 2 eingerichtet, einmal mit Kabel, einmal mit QSC als Priorität und der Kabel-Failoverpool ist bei der LAN-Ausgangs-Regel als Gateway drin und wird wohl auch genutzt, da das Failover auf die QSC Strecke beim Abklemmen funktioniert hat.
Jetzt ergibt sich aber folgende Konstellation. FTP von drinnen nach draußen (mit/ohne FTP Proxy) geht nicht. Jep, da muss wohl eine Seite bevorzugt eingestellt werden, bin mir aber unschlüssig wie das vonstatten gehen soll. FTP war aber schon immer Problemkind, insofern weiter zu anderem: Von Außen soll über WAN2 (QSC) VNC, MSRDP, OpenVPN und div. anderes funktionieren, da die Leitung mit entsprechend viel Upstream konfiguriert ist. Kabel soll eigentlich primär als LAN Standard benutzt werden zum Surfen, weil die entsprechend im Downstream dicker ist. Problem ist, dass ich es trotz exzessiver Hirnschmalzanstrengung nicht geschafft habe, VNC oder Konsorten von außen auf WAN2 zugänglich zu bekommen. Policy Based Routing höre ich da im Hinterkopf aber bin im Moment ein wenig ratlos, denn funktionieren wollte es nicht.
Hier die Konfig:
+-----+ +-----+ WAN |Kabel| MODEMS | QSC | WAN2 +--+--+ +--+--+ | | | Ethernet | PPPoE +--+--+ +--+--+ | R01 | ROUTER | R02 | +--+--+ +--+--+ 192.168.102.1 | | 192.168.101.1/24 | +-------+ | +------|pfSense|------+ 192.168.102.254/24 +---+---+ 192.168.101.254/24 | LAN 10.0.0.1/24 R: Router auf DMZ IP (.254) eingestellt, damit jeglicher Traffic weitergereicht wird
Was geht (+), was nicht (-)
- LAN->INet soll über WAN laufen
- OpenVPN Server auf pfSense konfiguriert, soll auf WAN2 angesprochen werden und antworten
- VNC/MSRDP/HTTP(S) sollen auf WAN2 laufen
- FTP LAN->INet soll über WAN laufen
- Failoverpool "Kabel": 1. Kabel, 2. QSC
- Failoverpool "QSC": 1. QSC, 2. Kabel
Über einen Denkanstoß oder ein klein wenig Hilfe wären wir beide mehr als dankbar!
Viele Grüße
Grey -
Kann es sein, daß Deine vorgeschalteten Router dazwischenpfuschen und was blocken?
-
Sind beides 2 (kleine&dumme) Netgear Router, die als DMZ Host (Anm: Ich hasse diese irreführende Bezeichnung ;)) die pfSense eingetragen haben. Von außen sieht man auch bei vollem Paketfilter ohne Freigabe auf dem entsprechenden Interface, dass angeklopft wird. Gebe ich aber bspw. 1194 UDP auf der QSC Seite (WAN2) frei, sind zwar die Blocks verschwunden, aber das VPN baut trotzdem keine Verbindung auf. Irgendwie scheint es mir noch unklar, wo die definierten Failover Pools in den Regeln Anwendung finden sollen, damit es funktioniert wie es soll :)
Danke soweit,
Grey -
Die Konfiguration steht bei mir.
Auf Einladung von Grey habe ich mich hier registriert, um eine Lösung des Problems zu erzielen…
Ich habe gerade eben beide Netgear-Router-Konfigurationen überprüft. Beide Router (Netgear FSV114) leiten den vollen Traffic ohne jegliche Blocks auf die Soekris net 48xx mit pfSense 1.0.1-SNAPSHOT-02-02-2007 weiter.
Ich habe lediglich auf der Seite der QSC-Verbindung einen Konfig-Fehler entdeckt und behoben (Idle-Time 5 Minutes auf 0 gesetzt, damit die Verbindung gehalten wird) und auf der Kabel-DSL-Seite war die Systemzeit nicht korrekt definiert (ist aber nun auch behoben und als User-Defined-NTP-Server habe ich jetzt auf beiden Netgear-Routern de.pool.ntp.org eingetragen).
Diese Flüchtigkeitsfehler haben aber mit der Problemstellung den Traffic auf den relevanten Port zu bringen leider nichts zu tun, so dass ich hier immer noch vor dem Problem stehe, dass kein OpenVPN und kein Remote-Zugriff auf meine Server bzw. Dienste (Mail-Server WebAccess, etc.) möglich ist.
Eine Anmerkung wäre vielleicht noch zum Opt2-Interface zu machen:
Ich habe eine miniPCI-Karte von Wistron (CM 9) eingesetzt, das WLAN zwar "vorkonfiguriert", aber noch nicht aktiviert, da ich noch keine Antenne angebracht habe (ich muss erst noch die Löcher für die Pigtail-Kupplungen bohren). Kann das nicht aktivierte Interface hier zusätzlich für Probleme sorgen?Bin für konstruktive Tipps mehr als dankbar, den die ganze Situation "lähmt" mich in meiner Arbeit ziemlich!
Vor allem das nicht funktionierende FTP ist ein großes Problem!
-
Wenn Du mir das Webgui am WAN aufmachst und mir per pm die IP und Logindaten schickst kann ich mal drüberschauen. Setze für mich ein temporäres Passwort für den Logon.
-
Vielen Dank für das Angebot; ich komme gerne darauf zurück. Allerdings bin ich jetzt nicht zuhause; erst wieder heute abend ab etwa 18:00 Uhr MEZ oder morgen (dann so ziemlich den ganzen Tag).
Wenn Du mir mitteilst, wann Du Zeit hättest, gebe ich Dir die WebGUI frei und schicke Dir die Daten.
Danke schonmal im Voraus!
Nobby
-
Ich würde die CM9er mal abschalten, hatte beim letzten drübersehen noch erspäht, dass du die im 10er Netz von LAN konfiguriert hast und weiß nicht inwiefern das noch Seiteneffekte auslösen kann. Aber die Wurzel des Übels ist das vermutlich nicht. Immerhin weiß ich aber jetzt, woher die Timeouts auf dem QSC WAN2 kamen ;)
Was mir beim OpenVPN Daemon noch aufgefallen ist: der hatte kurzzeitig funktioniert, allerdings nur, wenn auf beiden WANs eingehender Traffic auf dem udb/1194 erlaubt wird. Auch wenn in der config des Clients WAN2 Public IP (oder deren DynDNS Name) drinsteht klopft er zwar auf WAN2 an, bekommt aber dann laut Log Antwort via WAN (statt WAN2). Könnte es sein, dass hier der Daemon standardmäßig immer auf dem WAN gebunden ist (kann mich an ein Logeintrag erinnern mit gw 192168.102.1 was ja WAN und nicht WAN2 wäre).
Warum aber die anderen Dienste wie VNC etc nicht von außen über WAN2 funktionieren ist mir schleierhaft. Bin aber mehr als gespannt ob Holger da vielleicht was findet (ich hoffe) und wie ers löst :)
@Nobby: Vorher vielleicht nochmal Konfig sichern, neu mit aktuellem Snapshot flashen und Restore machen, damit wir auf neuem Stand sind :)
-
Aktualisierung zum Opt2-Interface (WLAN):
Antenne angeschlossen, WLAN aktiviert, aber noch ungetestet.
Konfiguration scheint soweit ok zu sein.
Die Soekris soll hier als AccessPoint mit der IP-Adresse 10.0.0.253 fungieren; dürfte eigentlich keine Probleme geben…Abschalten ist aber auch möglich ;D
-
Komm einfach auf freenode in den IRC channel ##pfsense. Wenn ich dort online bin bin ich auch da und habe Zeit (hoba_idle ist nur mein backlogging-nick, ich bin als hoba dort, falls ich da bin).
-
Hallo hoba,
bin jetzt zuhause und die WebGUI ist offen (siehe auch Deine PM).
Danke!
Norbert