[der dom]

Hi,

ich steh gerade auf dem Schlauch - geht um das Routing zwischen zwei Segmenten und ich hab jetzt diverse male einen meiner DD-WRTs zurücksetzen müssen weil der Krampf nicht mehr so funktioniert wie er soll - kann auch temporärer Ausfall meiner Hirnleistung sein was wahrscheinlicher ist.

Ich habe:

FB im Standardnetz also 192.168.178.x
das leitet den WAN verkehr an die FW weiter 192.168.80.x
Vom 80er ins 178er kein Thema geht - voller Zugriff,
andersherum nein - das muss ja über den WAN Port weil das 178er als
externes Netz angesehen wird - soweit korrekt oder?

Dementsprechend Route auf der FW angelegt -> über das Gateway (FW) ins 80er Netz.

Am DD-WRT das 178er Netz bekannt gemacht und das Routing über eine 24er Metric festgelegt da ja das Netz abgedeckt werden soll - erstmal PoC, danach wird eingegrenzt.

Jetzt steh ich da wie Carl Napp und bekomme immer nur von der 80er Seite das OK, die 178er hat keinen Schimmer was sie machen soll. In der FB ist die Route zum Fremdnetz über die IP des WAN Ports gesetzt. Der ist ja im 178er Bereich.

Ich habe da glaube ich gerade komplett den Überblick verloren . Hat jemand eine Idee?

Mir gehen sie langsam aus. Ich hatte das Problem schon mal und irgendwann war es gelöst - aber ich komm nicht mehr drauf wie ich es gemacht habe. Und Dokumentiert hab ich Trottel das auch nicht.

[RalphS]

Hmm... also ich versuch das mal zu konstruieren nach Deinen Worten:

Wand (Internetanschluß 0.0.0.0/0 :WAN) Fritzbox

=> Fritzbox(LAN: 192.168.178.0/24 :OIF) Firewall

=> Firewall (IIF: 192.168.80.0/24 .... vermutlich ein Switch)


So und wo hängt jetzt der DDWRT?


Die Fritzbox: Muß alles was zuhause so rumsteht routen mit Gateway = LAN Interface bzw. IP-Adresse des Firewall OIF. Mit Kabel ist das natürlich immer so ne Sache, aber ich würde unter den Umständen erstmal eine Route anlegen
192.168.0.0/16 192.168.178.was-auch-immer-das-FW-OIF-für-eine-IP-Adresse-hat

Die Firewall sollte sich selber ums Forwarding zwischen IIF und OIF kümmern. Das ist ihr Job. Wenn es nur zwei Interfaces gibt, sollte kein weiteres Routing erforderlich sein und das Segment zwischen FBox und FWall kann auf ein /30 eingestampft werden, wenn da nichts anderes drinhängt. In diesem Fall also 192.168.178.0/30 oder wegen mir 192.168.178.252/30 oder halt irgendeines der vielen /30er Optionen im 178.0/24-Segment.

- FB und LAN sind jetzt abgekoppelt. FB-DHCP wird ohne Agent KEINE IP-Adressen mehr im LAN verteilen KÖNNEN.

- Also im LAN-Segment einen DHCP-Server aufstellen, idealerweise auch einen DNS, damit der nicht durch die FW in ungeschützte Regionen gestellt werden muß.

- Jener DHCP muß dann an die Clients im LAN verteilen:
IP => dynamisch oder reserviert
Pool => aus 192.168.80.0/24, sagen wir von 192.168.80.100 - 200.
Gateway: IP des Firewall-IIF.


Und dann müßte das eigentlich schon funktionieren.

Merke: Routen sind immer gerichtet und sind analog Wegweisern an einer Kreuzung zu verstehen: Wenn Du nach Rom willst, fahr Richtung Innsbruck und schau dort dann, wie es weitergeht; Problem: wir kommen so nicht nach Hause.
Deswegen muß eine Rückroute her: Wenn Du nach Jena willst, fahr (von Innsbruck aus) erstmal nach München und schau dort dann, wie es weitergeht.

Je weiter weg das ist, desto unspezifischer kann die Route werden - ODER man muß für jedes Ziel eine angeben.

Von Innsbruck: Fahr erstmal nach Deutschland. Die wissen besser als wir, wo Jena ist.
Oder:
Nach München, da lang. Nach Berlin, auch da lang. Nach Rostock, AUCH da lang. Und nach Kopenhagen, ebenfalls da lang.

[M. Heinemann]

Mmh. Ich versteh den Sinn des Ganzen nicht so richtig.

Aber das Routing macht deine Firewall eigentlich von selbst.

Ich würde mich an deiner Stelle mehr mit den Zonen und Firewall Regeln beschäftigen, anstatt mit dem Routing.

[RalphS]

Die Fw vielleicht, die Fbox aber nicht. Wo soll denn das Antwortpaket hin? Quellip ist nach NAT außerhalb des Segments, also müßte es per Standardgateway zurück aufs WAN Interface. Da sind wir allerdings auf dem Holzweg - Antworten müssen nach innen, nicht nach außen.

Wenn die FB das nicht weiß, funktioniert der Internetzugang nur bis zur Firewall, aber nicht dahinter. Ist auch ein Schutz, klar, aber vielleicht ein wenig Overkill. - plus dann braucht man keine Firewall.

[der dom]

Also Topologie ist wie folgt:

COAX -> Fritz!Box (192.168.178.1) - diese dient derzeit quasi als "Modem" - um es mal salopp auszudrücken

von der FB geht ein LAN Kabel zu meiner FW (OPNSense 192.168.178.122 ist die Adresse mit der die OPNSense mit der FB spricht und als WAN Port fungiert)

OPNSense (192.168.80.1 als LAN Port) spricht mit dem DD-WRT (192.168.80.2) -> der verteilt auf weitere Geräte.

Ich komme von "innen" also vom 80er Netz ins 178er - das funktioniert. Vom 178er ins 80er geht aber nicht und ich brauche ein Gerät das eben dieses kann (wg. Daten per VPN und so).

Als DNS hab ich dediziert einen piHole am laufen - der ist im 178er Netz. DHCP übernimmt die OPNSense und der DHCP Server der FB ist deaktiviert. Das will ich auch so.

Die FB muss doch "nur" wissen über welches Gateway sie mit dem "Fremdnetz" sprechen kann.

Meine Idee wäre jetzt halt dem DD-WRT per Routing zu sagen "Sprich bitte das 178er Netz über das WAN Interface an der FW an". Der FB würde ich sagen -> Antworte gefälligst auf die Anfragen des 80er Netzes über das WAN Interface der FW (also .178.122). Damit wäre der Weg doch, so die Theorie, korrekt oder nicht?

@Heinemann: Der Plan ist halt folgender:

Ich habe noch 2 Pis im Netz - einer ist der DNS und der andere bedient mich mit diversen Diensten. Dieser muss aber auch aufs 80er Netz zugreifen. Soll aber per VPN zu erreichen sein. Da die FB meines Wissens nach keine Möglichkeit bietet die VPN Ports weiterzuleiten sodass die FW den VPN Server Part übernimmt, bin ich gezwungen den Weg für die Himbeere ins 80er Netz zu ebnen. Alternativ wäre noch die Möglichkeit da dem Pi ein weiteres Gateway zu verpassen und eine weitere IP. Dann sollte er ja auch in den anderen Netzbereich kommen.

Die FW ist eine vom ISP gewartete und somit auch dezent beschnittene.

[RalphS]

Dieser DDRWRT, ist das auch ein Router?

Weil wenn ja, dann kann es nicht gehen. Das 80er Segment wäre dann NUR das Stück zwischen Firewall und dem DDWRT und die Clients wären nochmal woanders.


Wenn es keine besonderen Gründe für einen zweiten Router *VOR* der Firewall gibt, schmeiß ihn raus und ersetz ihn durch einen Switch.

[der dom]

Ich kann das Dingen konfigurieren wie ich will - Out of the Box ist das teil frei konfigurierbar. Ich hatte dem mal gesagt mach mal als Router - das gilt aber nur dann wenn ich auch einen Eintrag in die Routingtable haue - alternativ hätte ich noch "Sei mal Gateway" und auch da nur mit Einträge in die Tabelle....ansonsten macht das Dingen nichts anderes außer Miniswitch zu sein und die Pakete durch zu schubsen.

Da kann ich dem DD-WRT (das ist ein geflashter Netgear EX6200) die WAN Daten mitgeben - als Gateway hätte ich da halt die IP der FW im 178er reingepackt:




So dann kann ich bei dem Dingen noch ein Advanced Routing einstellen:



Da würde ich als Routing-Gateway entweder die 178.1 oder die 178.122 oder aber auch die 80.1 eintragen - als gleiches natürlich in der FB die muss ja Antworten.

Ich hab das wie gesagt schon mal gehabt - da war es ein 192.168.2.x und 192.168.178.x aber wie das war, ich weiß es nicht mehr.

[RalphS]

Ein Gateway ist (im Netzwerkkontext) ein Router.

Deiner Beschreibung nach könnte das Ding als Router mit NAT auf dem WAN-Interface agieren: Raus geht, aber rein bleibt hängen.

Häng mal die Firewall vom WAN-Interface des DDWRT auf das LAN-Interface um und schau, ob es dann schon geht.

In diesem Fall bräuchtest Du an den Clients die Firewall-IP des inneren Interfaces als Standardgateway und die Fritzbox braucht eine Route zum Client-Segment via der IP des äußeren Firewall-Interfaces.

Darauf achten, daß das innere Interface der Firewall keinen Gateway eingetragen hat. Die FW kümmert sich ums Forwarding via zu definierender Regeln; wenn es keine SPI ist, jeweils eingehend und ausgehend, ansonsten ausgehend für TCP-Anfragen aus dem Clientnetz und eingehend für UDP. Eingehend auch für Dienste, die aus dem Internet erreichbar sein sollen, die dann aber möglichst sparsam oder ggfs. eine DMZ einplanen.



Oder Du machst es tatsächlich so wie oben angedeutet: Neues Segment für die Clients und dann mit dem DDWRT routen. Ist zwar an der Stelle nicht nötig, kann man aber trotzdem tun.

Angaben sind zur Veranschaulichung gemäß der aktuellen Konfiguration. Subnetzmasken sind Vorschläge und sind so gewählt, daß man überall einfach /24 angeben kann, wenn man sich nicht mit verschiedenen Größen herumärgern will. Das Clientsegment kann bedarfsweise vergrößert oder verkleinert werden, sollte aber zuhause prinzipiell nicht notwendig sein - mehr als 250 Clients wirds hoffentlich nicht geben.


Client-Segment:
ID = 192.168.2.0/24
Gateway = LAN-Interface des DDWRT, wahrscheinlich 192.168.2.1 oder 192.168.2.254 .

DDWRT:
NAT *aus*. Mit NAT geht gar nichts.
LAN IP = 192.168.2.254/24
WAN IP = 192.168.80.1/30; Standardgateway = Inneres Interface der Firewall


Firewall-Segment INNEN:
ID = 192.168.80.0/30
Gateway: Inneres Interface der Firewall; in dieser Konfiguration wäre das 192.168.80.2


Firewall:
INNEN = 192.168.80.2
AUSSEN = 192.168.178.2 (eigentlich 1, aber das wird die FB wohl schon verwenden und wir machen es uns etwas einfacher)
plus Regelsatz, was durchgestellt werden muß, wieder nach innen und nach außen, wenn es keine SPI ist. Das gilt insbesondere für das Clientsegment, da die FW das nicht kennt (nicht ihr eigenes Segment).


Firewall-Segment AUSSEN:
ID = 192.168.178.0/30 (oder größer für DMZ)
Gateway = IP des LAN-Interfaces an der Fritzbox, in diesem Fall also 192.168.178.1

Fritzbox:
LAN IP = 192.168.178.1/30
WAN IP = (autokonfiguriert durch Provider)

und zwei Routen setzen
Ziel = 192.168.2.0/24; Gateway = 192.168.178.2 für die Clients
Ziel = 192.168.80.0/30; Gateway = 192.168.178.2 für den DDWRT


Pakete ausgehend:
Aus dem Client-Netzwerk geht jeglicher Traffic, der nicht nach 192.168.2.0/24 soll, zum DDWRT. Der muß entscheiden, was damit passieren soll.

Der DDWRT kennt die .2. und die .80., aber nicht die .178. und auch nicht das Internet.
Deshalb muß aufs WAN-Interface ein Standardgateway: Alle Pakete, die nicht .2. oder .80. heißen, insbesondere Internetpakete, müssen zur Firewall.

Die Firewall muß gesagt kriegen, was durchzustellen ist, damit es funktioniert.

Und an der Fritzbox kümmert sich das autokonfigurierte WAN um die Internetverbindung.


Pakete eingehend:
Die FB kennt die 178 und sonst gar nichts, also muß eine Route bzw. mehrere Routen her für alles andere, was wir haben.
Im einfachsten Fall routen wir 192.168.0.0/16 nach dem äußeren Interface der Firewall: 192.168.178.2 . Daß da die 192.168.178.0/30 mit drinsteckt, stört an der Stelle nicht, da das über dasselbe Interface rausgeht.

Die Firewall muß wieder gesagt kriegen, was durchgehen soll, insbesondere wenn es keine SPI ist.

Der DDWRT braucht keine weiteren Routinginformationen. Alles was da ankommt, kennt er selber, insbesondere das .2. Segment.



Ohne Gewähr, hab das nicht durchgetestet.

Wie gesagt, lieber den DDWRT rauswerfen und auf das zusätzliche Segment verzichten:
Client-Netzwerk
- Firewall INNEN bekommt IP-Adresse aus dem Clientsegment
- Firewall AUSSEN bekommt IP-Adresse aus einem anderen Segment, nennen wir es Außensegment
- In diesem Außensegment befindet sich die Fritzbox

Soll es Geräte geben, die aus dem Internet erreichbar sein sollen:
Der Firewall ein drittes Interface für die DMZ geben. Das wäre dann das DMZ-Segment, wieder mit einer eigenen ID. Routinginformationen wären entsprechend zu erweitern, um die DMZ von innen und von außen erreichen zu können.

[der dom]

Alter Schwede - okay, gut, das musste ich mir jetzt mal ausdrucken. Danach mach ich mal ein Bild (also tatsächlich malen) und dann wird getestet. Strange ist, dass ich ohne "richtige" Firewall solche Probleme mit dem Routing nicht hatte - aber das steht auf einem anderen Blatt.

Ist ja auch ´ne neue FW.

Ich werde berichten ob es geklappt hat.

[RalphS]

Ja, malen hilft da immer.

Die FW muß von Interface A nach Interface B durchreichen und da gibt es dann auch verschiedene Möglichkeiten für.

Wenn man jetzt iptables hernehmen würde, da hätte man INPUT und OUTPUT Chains, aber die würden an der Stelle nicht reichen, denn Pakete sollen nicht am FW-Host ankommen, sondern sollen durchgestellt werden.


Kann man sich bißchen wie einen Router vorstellen. Funktioniert anders, aber man muß ebenfalls sagen, hier kommt Paket X und was soll ich jetzt damit machen?


Daß es mit FW nicht geht, ist also nur bedingt ein Wunder.


Ich glaub ich hab das schon mal irgendwo erwähnt gehabt, aber zuerstmal muß es funktioniern. Im Zweifel die FW aufh Durchzug schalten - sinngemäß:

allow any to any in iif out oif
allow any to any in oif out iif
allow any to me
allow me to any

Logs anschalten und dann mit Traffic herumwerfen.
Traceroute hilft dabei, aber dran denken, daß der letzte angzeigte Router im Normalfall noch funktioniert hat
und daß das Problem einen Hop dahintersitzt.

Unter Linux sollte as auch noch sowas wie route show ... geben, der verrät, was mit Peketen passiert, die das angegebene Ziel haben.

Ist wirklich nicht schwer, aber man muß immer dran denken, Routen gehen von EINEM A zu EINEM B und Pakete müssen zurückkommen können, ergo sind Hin- und Rückrouten erforderlich.

[der dom]

Wie Routing im allgemeinen funktioniert ist mir schon bewusst - dass A wissen muss dass er auf B auch antworten darf.

Das Problem ist halt eher, das ich vorher mit anderen FWs gearbeitet habe und diese mir immer irgendwelche Steine in den Weg legen. Das ist wichtig und richtig so - aber machts halt auch komplizierter

[RalphS]

Dann sag halt nicht, daß Du kein Netzie bist.

[der dom]

Soooo, des Rätsels Lösung ist so trivial. Es war kein Routingproblem ansich.

OPNSense hat die Einstellung am WAN Port private Netzte zu blockieren, was ja auch erstmal gar nicht so doof ist.
Wenn der Haken allerdings gesetzt ist, gehen auch keine privaten Netze - gleich welche Regel man erstellt.

Haken entfernt, dann die Routen wieder gesetzt und siehe da - es läuft.

[RalphS]

Ich sag doch, am Ende isses immer irgendwelcher trivialer Müll, wo man sich nur noch an den Kopf fassen kann.

Danke fürs Feedback.


So als Protip, wenn irgendwo zB an einer Firewall noch "globale" Konfigurationsmöglichkeiten da sind, die sich funktional mit dem Rest überlappen, dann laß möglichst die globale Konfigurationsoption weg. Das schießt sonst nur quer.


Stattdessen halt wirklich fragen, okay welchen Weg GEHT denn mein Traffic denn jetzt wirklich?

Triviales Beispiel, Traffic von 127.0.0.0/8 ist nur am Loopbackinterface legal. Woanders kann der nicht herkommen und schon gar nicht hingehen. Das wäre ein Fall von Spoofing.

Ergo kann man Regeln haben:

- ALLOW any to any via <loopback>
- DENY 127.0.0.0/8 to any in via <non-loopback>
- DENY any to 127.0.0.0/8 out via <non-loopback>

und so diesem Spoofing vorbeugen (cf. Assertion).

Macht aber NUR Sinn mit der zugehörigen Pfadangabe! DENY 127.0.0.0/8 to any für sich genommen sorgt für alle möglichen Problemchen, ebenso wie DENY any to 127.0.0.0/8; jeglicher lokaler Verkehr *muß* zugelassen werden.

Aber halt nur über das Loopbackinterface.