Zyxel P660H als Bridge (INODE xDSL Business Silber 2048/512)

[Master One]

Aktuelles Szenario: Das P660H von Inode manuell konfiguriert mit zwei Remote Node Profiles (11.1), einmal PPPoE Routing 9/35 für Internetzugang, einmal Bridging 9/36 für Telenode Gold 1. An dem P660H hängt die Smartnode 1200 für ISDN-over-IP, und ein Draytek Firewall-Router mit dahinterliegendem LAN.

Nun soll der Draytek Router durch eine pfSense Firewall-Router-Maschine ersetzt werden, wobei ich pfSense die PPPoE Verbindung managen lassen möchte.

Jutta's betreffende zweite "Test-Config" im gleichnamigen Thread geht von drei Remote Node Profiles im Menu 11.1 aus, wobei man das PPPoE-br Profile beim 660er dank der Advanced Option PPPoE-passthrough ja kicken kann. Allerdings wird diese Konfiguration an einem INODE xDSL Business Silber Anschluß nicht funktionieren, da da man bei diesem, im Gegensatz zu einem Privat-Anschluß mit dynamischer öffentlicher IP, ein fixes Subnetz mit 8 IP-Adressen zur Verfügung hat. D.h. man kann sich über PPPoE nur einmal einloggen, und somit nicht 8/35 routen und 9/35 gleichzeitig bridgen (oder umgekehrt).

Die Lösung des Problem läßt also nur einen Schluß zu, nämlich zwei Remote Node Profiles (11.1), einmal Bridging 9/35 für Internetzugang, einmal Bridging 9/36 für Telenode Gold 1.

Wird dieses Vorhaben tatsächlich auf diese Weise funktionieren?

Völlig unklar ist mir hierbei, welche IP-Adresse man dem LAN-Interface des P660H zuteilt, um weiterhin auf das Zyxel zugreifen zu können. Eine Bridge würde ja eigentlich keine eigene IP-Adresse benötigen, aber mangels serieller Konsole (und da ich nun mal sowieso gerne über das Netz drauf Zugriff haben möchte) kommt man da ja auch gar nicht drum herum. Logischerweise wird es wohl eine private IP-Adresse sein, wobei man dann in der pfSense Maschine WAN-seitig eine statische Route auf diese IP-Adresse einrichten muß, right? Spielt es eine Rolle, welche (private) IP-Adresse man dem Zyxel gibt?

Was ist bei einem solchen Setup sonst noch zu beachten?

Das Zyxel zur reinen Bridge umzuwandeln hat jedenfalls ganz klare Vorteile. Vor allem kann man hierbei eine öffentliche IP-Adresse mehr benutzen (die Gateway-Adresse, die ansonst im Zyxel für die Zuteilung auf das LAN-Interface geopfert werden muß), die Sache mit dem MTU Handling (1492 beim PPPoE Tunnel vs. 1500 im LAN), sowie das wesentlich leistungsfähigere Connection-Handling (der pfSense Computer ist dem Zyxel bei weitem überlegen).

[jutta]

> Allerdings wird diese Konfiguration an einem INODE xDSL Business Silber Anschluß nicht funktionieren, da da man bei diesem, im Gegensatz zu einem Privat-Anschluß mit dynamischer öffentlicher IP, ein fixes Subnetz mit 8 IP-Adressen zur Verfügung hat. D.h. man kann sich über PPPoE nur einmal einloggen, und somit nicht 8/35 routen und 9/35 gleichzeitig bridgen (oder umgekehrt).

stimmt.

> Die Lösung des Problem läßt also nur einen Schluß zu, nämlich zwei Remote Node Profiles (11.1), einmal Bridging 9/35 für Internetzugang, einmal Bridging 9/36 für Telenode Gold 1.

stimmt.

> Wird dieses Vorhaben tatsächlich auf diese Weise funktionieren?

ja, sollte problemlos funktionieren.

> Völlig unklar ist mir hierbei, welche IP-Adresse man dem LAN-Interface des P660H zuteilt, um weiterhin auf das Zyxel zugreifen zu können.

*irgendeine* private ip, die nicht stoert. die einzelplatz-bridges von inode haben bekanntlich 169.254.220.1. fuer deine zwecke ist es vermutlich praktischer, ihm eine 192.168.xx.yy oder 10.xx.yy.zz ip zu geben - eine ip die zu deinem lan passt, aber ausserhalb des pools deines dhcp-servers liegt, damit sie nicht irrtuemlich doppelt vergeben wird.

> Logischerweise wird es wohl eine private IP-Adresse sein, wobei man dann in der pfSense Maschine WAN-seitig eine statische Route auf diese IP-Adresse einrichten muß, right?

das haengt davon ab, wie oft und von wo du auf das zyxel zugreifen musst. wenn du ein netzwerk-notebook hast, das sich bei bedarf rasch passend konfigurieren und ans zyxel anschliessen laesst, oder sonst einen rechner, den du rasch umstecken kannst (oder der sogar 2 netzwerkkarten hat), kannst du auf die konstruktion mit der static route verzichten.

wenn du lust auf bastelarbeit hast und ein bissl erfahrung im loeten von elektronischen bauteilen, kannst du dir ein konsolenkabel basteln. nachteil: dann steht das modem offen herum und die pins verbiegen sich verdammt leicht. (ist also eher eine sache fuers labor oder fuer notfaelle, als fuer den normalbetrieb.)

> Spielt es eine Rolle, welche (private) IP-Adresse man dem Zyxel gibt?

im grunde egal. ich waere nur mit 172.er ips vorsichtig, weil die auch im internen inode-netz verwendet werden. man kann den p660 btw sogar 2 oder 3 verschiedene lan-ips geben (und je nach firmware gibts auch noch die funktion "any ip", die ich allerdings noch nie ausprobiert habe.)

> Was ist bei einem solchen Setup sonst noch zu beachten?

sollte problemlos funktionieren. zu beachten ist dabei nur, dass du es selbst hinkriegen musst und im fall des falles keinen anspruch auf support deiner sonderloesung hast.

> Das Zyxel zur reinen Bridge umzuwandeln hat jedenfalls ganz klare Vorteile. Vor allem kann man hierbei eine öffentliche IP-Adresse mehr benutzen (die Gateway-Adresse, die ansonst im Zyxel für die Zuteilung auf das LAN-Interface geopfert werden muß), die Sache mit dem MTU Handling (1492 beim PPPoE Tunnel vs. 1500 im LAN), sowie das wesentlich leistungsfähigere Connection-Handling (der pfSense Computer ist dem Zyxel bei weitem überlegen).

wenn du ein leistungsfaehiges geraet hast und das auch konfigurieren kannst, spricht imo absolut nichts gegen die bridge-loesung. (btw: das wissen, dass sie *wirklich* funktioniert, verdanke ich einer panne: ein bekannter hat von @home auf @work upgegradet und inode hat vergessen, ihm das neue modem zu liefern. da hat er seinen server ans vorhandene p645 angeschlossen und fuer die einwahl und fuers routing konfiguriert. hat tadellos geklappt. und ein bissl spaeter hat er dann auch das neue modem bekommen )

[Master One]

Jutta, wie immer mit Rat & Tat zur Seite, da kann ja eigentlich gar nichts schief gehen.

Werde dem Zyxel also eine 192.168.xx.yy Adresse aus meinem LAN-Bereich zuteilen, und eine statische Route für diese IP in der pfSense Maschine festlegen. Es ist einfach praktischer, wenn ich über's LAN auf das Zyxel zugreifen kann, ohne extra den Laptop direkt am Zyxel direkt anschließen zu müssen. Über das Basteln eines Konsoleanschlusses haben wir uns ja in der Vergangenheit schon mal unterhalten, ist mir aber zu aufwendig, für das Inode Leihgerät nicht angebracht, und würde mir auch nicht wirklich einen Vorteil bieten, da das Zyxel an einem recht unpraktischen Ort steht. Ich möchte jedenfalls schon jederzeit auf das Zyxel zugreifen können, im speziellen auf die Uptime, denn ich vertraue dem Teil nicht wirklich, wir hatten im letzten Jahr seltsame und mysteriöse Ausfälle, wobei das Zyxel zu bestimmten Uhrzeit in kurzen Abständen immer wieder neu Rebootet hat, wobei man beim Inode Support dem Problem nicht auf die Spur kommen konnte (die eheste Vermutung hierbei war, dass es sich um eine "Attacke" von außen handelt, bei der das Zyxel per SNMP-Befehl zum Rebooten aufgefordert werde, obwohl ich den Zugriff per SNMP im Zyxel deaktiviert hatte --> vielleicht ein Bug in der Inode-Firmware?). Die Hardware war es jedenfalls nicht, denn das Zyxel wurde schon mal ausgetauscht, was an dem Problem nichts geändert hat. Dies ist auch ein weiterer Grund, warum ich dem Zyxel die Kontrolle über den PPPoE Tunnel entziehen möchte, denn mit pfSense kann so etwas jedenfalls nicht passieren.

BTW Solltest Dir pfSense mal ansehen. Dies scheint derzeit die vielversprechendste Firewall-Router-Lösung zu sein. Basiert auf FreeBSD 6.2 mit entscheidenden Komponenten von OpenBSD, läuft direkt von CDROM oder auf HDD installierbar (sogar auf Softraid-1!), alles über's Webgui konfigurierbar, bei HDD Installation mit Package AddOn-Funktionalität (z.B. mit squid, ergibt ja am meisten Sinn, einen transparenten Web-Proxy auf der Firewall-Maschine mitlaufen zu lassen), uvm.

[Master One]

Ist ja nun einiges an Zeit vergangen. Also das Vorhaben ist natürlich geglückt. Das Zyxel läuft nun im reinen Bridging-Modus (1x Internet & 1x Telenode), und die pfSense Maschine handhabt die PPPoE Verbindung.

Dem LAN Interface des Zyxel habe ich eine 192.168.xx.yy Adresse zugeteilt, aber leider war es mir nicht möglich, eine statische Route zu legen, um aus dem LAN hinter der pfSense Maschine auf das Zyxel zuzugreifen. Vermutlich ist das prinzipiell auch gar nicht möglich, da das WAN Interface der pfSense Maschine durch die PPPoE Verbindung automatisch jene öffentliche IP zugeteilt bekommt, die vormals dem Zyxel (im Routing-Modus) vorbehalten war. Abgesehen davon habe ich in pfSense "Block private networks" am WAN Interface aktiviert. Hierdurch ist aber nichts verloren, da es im Zyxel bei dieser Betriebsart eigentlich nichts weiteres (außer der zur Verfügung stehenden WAN Bandbreite) zu kontrollieren, oder nachträchlich zu konfigurieren gibt. Das Zyxel ist nun von außen völlig unangreifbar, da es selbst keine WAN IP hat. Im Bedarfsfall kann ich ja immer noch ein Notebook am LAN Interface des Zyxel anhängen, und per Telnet darauf zugreifen.

[Master One]

Tja, zu früh gefreut.

Es ist mir bislang leider nicht gelungen, in diesem Setup die mir zu Verfügung stehenden öffentlichen IP Adressen mit einzubinden.

Das Problem ist hierbei besonders gefinkelt:

In einem normalen Setup, in dem das Zyxel die PPPoE Verbindung herstellt, erhält das Zyxel automatisch die Gateway-Adresse mit der Netzmaske 255.255.255.255 am WAN Interface, und dieselbe IP-Adresse, aber mit Netzmaske 255.255.255.248 (da es sich um ein /29 Subnetz handelt), am LAN Interface, wobei das Subnetz (also die 5 nutzbaren IP-Adressen) auf diese Gateway-Adresse geroutet werden.

In meinem Bridging-Setup erhält nun die pfSense Maschine automatisch die Gateway-Adresse mit der Netzmaske 255.255.255.255 am WAN Interface, aber da es ja keinen "Ausgang" gibt, dem man dieselbe IP-Adresse mit Netzmaske 255.255.255.248 zuteilen könnte, stehe ich jetzt bei der Frage an, wie ich auf diesem Rechner nun die nutzbaren IP-Adressen als Virtuelle IPs konfigurieren kann.

Das ganze kommt auf eine Diskussion mit Jutta & einem INODE Insider per email zurück (ich glaube das war im März 2006), wo aufgezeigt wurde, was man mit einem solchen /29 Subnetz alles anstellen kann.

Ich habe dazu eine ausführliche Beschreibung des Problems hier im pfSense Forum geschrieben. Diese ist jedoch in Englisch, und ehrlich gesagt zu umfangreich für eine rasche Übersetzung.

Jutta, könntest Du bitte mal einen Blick darauf werfen? Natürlich ist auch jeder andere, der sich diesbzgl. in der Netzwerktechnik gut auskennt, herzlich dazu eingeladen, sich dieser Denksportaufgabe zu stellen.

Ich wäre echt dankbar, wenn sich dieses Problem doch noch lösen lassen würde.

[penguinforce]

ich frag mich nur, warum du extrawürstl braten willst...

lass es auf default stellen (sodass das modem die einwahl macht), dieses routet das /29 nach hinten weiter, und deiner pfsense gibst die zur verfügung stehenden ip-adressen...

du bekommst die leistung, die du bezahlst, und der support kann dir bei supportfragen weiterhelfen (sehe ich als win <-> win - situation).

[Master One]

Ok, doch nicht zu früh gefreut! Es hat ja doch von Anbeginn erwartungsgemäß funktioniert, es hat letztendlich an der Durchführung des Funktionstests gescheitert...

Gewißheit brachte diese Antwort im pfSense Forum, und ein erneuter Test die Bestätigung.

@penguinforce

Warum eine wertvolle Public IP ungenützt für das Zyxel verbraten, wenn man doch nur eine Handvoll hat, und es auch anders geht? Abgesehen davon, daß nun endlich Schluß mit diesen rätselhaften Modem-Reboots ist, die auch das Inode Support-Team nicht lösen konnte.

[penguinforce]

ob ein solches drumrum den aufwand lohnt, muss jeder für sich entscheiden.

wenn man mehr ip's benötigt, kann man - wenn man es (plausibel) begründen kann - selbige zusätzliche ordern...

wie hats noch in der magnum-werbung geheissen... man muss prioritäten setzen..

[Master One]

Hierbei ging es natürlich nicht nur um die eine IP Adresse, sondern auch darum, die Aufgabe zu meistern.