Messages

Hallo!

Neben meiner privaten OPNsense administriere ich eine weitere Appliance bei meinem Arbeitgeber.
Wir realisieren damit verschiedene Netzwerkumgebungen. Eines davon ist ein sogenanntes Installations-LAN, in dem wir PCs und Virtualisierungsumgebungen für unsere Kunden installieren und konfigurieren.
Das Installations-LAN hat einen anderen IP-Adressenbereich, wie der Rest und ist mit FW-Regeln gegen das übrige LAN abgeschottet. Es gibt aber Kommunikation vom übrigen LAN in das Rechnerinstallations-LAN (Installations-Station).

Jetzt kommt meine eigentliche Anforderung:
Am Ende der Installationen verpassen wir den Systemen die vom Kunden vorgegebenen IP-Adressen. Das führt aber dazu, dass unsere Firewallregeln und das Routing nicht mehr funktionieren.

Wie kann man das Problem lösen, dass das Gateway der Schnittstelle neben dem Installationsnetz auch temporär ein weiteres Netz, der vom Kunden vorgegebene Netzwerkbereich, routet?

Danke für eure Hilfe!

Ja, das ist 100pro eine Änderung am DHCP Server des ISP.
Bei uns ein kleiner lokaler ISP, dessen Techniker eigentlich a) sehr schnell antworten und b) relativ fähig sind.

Ich habe jetzt noch an der Schnittstelle "rumkonfiguriert" und ausprobiert.
Meine Idee war, dass - wieso auch immer - die virtuelle Schnittstelle nicht sauber erkannt wird. Ich habe also mal einen Hostnamen eingegeben und siehe da: Ich bekomme wieder eine IP. Wieso auch immer. Dafür habe ich nen 3/4 Tag rumgesucht.

Also unter Schnittstellen -> betroffene Schnittstelle ->DHCP Client Konfiguration -> Hostname.

(Alles was über Fritz!Box hinausgeht überordert die ISP-Techniker dann wohl oftmals ;-) )

Hallo!

Folgende Konstellation auf meiner WAN-Schnittstelle:

1. Auf Standard-WAN bekomme ich vom ISP eine IP-Adresse für den Zugriff aufs Internet.
2. Auf VLAN40, das über WAN reinkommt, bekomme ich ebenfalls eine IP von ISP für VoIP.

Es handelt sich um einen FTTH Anschluss mit einem ONT bzw. "Glasfasermodem". OPNsense ist also direkt an der Leitung angeschlossen über den ONT.

Seit heute Nacht bekomme ich keine IP mehr auf VLAN40. Nach Auskunft des Supporttechniker wurden Wartungsarbeiten durchgeführt. Sie würden auf ihrer Seite keine DHCP-Anfrage im VLAN sehen.

Mir sagt die OPNsense nach zyklischen DHCP Veruschen "No DHCPOFFERS received."

WAN selbst hat keine Probleme und erhält auch eine IP.

Ich habe schon alles versucht, von ONT stromlos machen/neustarten, bis hin zu OPNsense neustarten sowie ausschalten, stromlos machen und wieder einschalten.

Der ISP Techniker hat das Thema intern weitergegeben. Ich möchte aber ausschließen, dass das Problem an der OPNsense liegt.

Jemand eine Idee?

(Hab die Konfig mittlerweile 4 Jahre laufen und hatte damit noch nie Probleme)

Danke und Grüße
Andreas

So wie es aussieht ist der Netzwerkadapter überhitzt gewesen.
Meine Firewall ist in einem Serverschrank verbaut,  in dem sich an den heißen Tagen mehr Wärme gestaut hat, wie sonst.

Mit Abkühlung des Wetters und Öffnen der Schranktür hat sich das Problem aufgelöst.

Nach ewiger Googlerei bin ich auf Hitzeprobleme gestoßen,  wenn zu oft der Promiscuous Mode deaktiviert/aktiviert wird.

Allerdings war die restliche Hardware innerhalb der Toleranzen, ich hatte nirgends in den Logs eine Warnung oder einen Error.

Nachtrag:

Mir ist aufgefallen, dass seit Auftreten des Problem immer kurz vor Verbindungsverlust folgender Logeintrag zu finden ist:

Code Select Expand

2020-07-09T01:20:59 kernel: pflog0: promiscuous mode enabled
2020-07-09T01:20:59 kernel: pflog0: promiscuous mode disabled

Am 09.07. fing das Problem an. Einen älteren Eintrag finde ich nicht, also könnte hier ein Zusammenhang bestehen.

Ach ja, hier wird das Problem auch beschrieben, Verbindungsverlust von LAN zu WAN. Nur bei mir nicht alle 15 Minuten, sondern unregelmäßig: https://forum.opnsense.org/index.php?topic=13596.0

Mittlerweile habe ich den Fehler nicht mehr so oft, allerdings immer noch ca. 4 mal.
Dabei völlig unreproduzierbar.

Ich habe die Logfiles rauf und runter durchsucht, kann aber keinen richtigen Erroreintrag finden.
Fakt ist wirklich, dass er sich die Verbindung abhängt, wenn er versucht zu checken, ob WAN eine neue IP hat. Aber eben auch nicht bei jedem Versuch.

Wenn der Fehler auftritt funktioniert z.B. auch eine DNS-Abfrage bzw. Namensauflösung. Natürlich aber kein Ping oder Traceroute. Von außen geht die Verbindung aber wie gehabt durch.

Der einzige Eintrag in den allgemeinen Logfiles, der mir zum Zeitpunkt des Ausfalls auffällt ist der hier:

Code Select Expand

opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv4 default route
2020-07-11T07:29:33 opnsense: /usr/local/etc/rc.newwanip: ROUTING: IPv4 default gateway set to wan

1. Netzwerk ist einfach:

Internet (Glasfasermodem) -> OPNsense -> Switch -> WLAN APs, LAN-Teilnehmer etc.

2.
- das Ding ist Blech auf Basis eines X11SBA-F  (das hatte bis HW Rev. 1.02 Probleme mit den Netzwerkschnittstellen, ich habe aber Rev 1.02 und hatte bis jetzt das Problem nur sporadisch. Heute massiv und vermehrt ohne ersichtlichen Grund)

- Wie geschrieben: OPNsense bekommt auf WAN direkt eine IP vom ISP, das war's.

- Ich finde keine Fehlermeldungen im eigentlichen Sinne, sehe nur, dass kurz vor dem Fehler, die OPNsense versucht die IP zu erneuern. Es kommt aber keine Fehlermeldung, dass dies nicht funktioniert hätte. Die IP ändert sich übrigens vielleicht 1 mal im Jahr. Wie gesagt, von außen ist alles erreichbar, aber vom LAN aus kommt man nicht mehr ins Internet.

- LAN, WLAN hat beides das gleiche Fehlerbild.

- Klar, beides getestet.

Details zu meiner Appliance in meinem Blog: https://www.imrazor.de/howto/selfmade-opnsense-appliance/

Hallo Leute,

ich hatte immer mal wieder das komische Phänomen, dass auf einmal aus dem LAN keine Internetverbindung mehr aufgebaut werden konnte. D.h. verbundene Geräte sagen, sie sind offline.

Rufe ich von außen aber die Adresse meines über das Internet erreichbaren Webserver aus, dann funktioniert das tadellos. Der Webserver hängt ebenfalls im LAN.

Um das Problem zu lösen, muss ich die WAN-Schnittstelle deaktivieren und dann wieder aktivieren.

Seit heute Nacht ist dieser Fehler jetzt aber mehrmals aufgetreten und ich kann mir nicht erklären, was diesen auslöst.

Hat jemand eine Idee?

Habe die aktuelle 20.1.8 laufen, Gateways werden immer als Online angzeigt. Die Kiste hängt direkt an einem Glasfasermodem, also kein Router oder sonst was dazwischen. Holt sich auf dem WAN Interface per DHCP eine IP vom ISP.

Hallo Sven-Jendrik,

Richtig verstanden.

Die nackten Rechner werden zuerst im 15er Netz eingebaut, bekommen vom DHCP eine entsprechende IP-Adresse aus unserem Band. Dann werden die Kisten u.a. per Desktop Central installiert/konfiguriert. Finale Tätigkeit ist, den Geräten eine Kunden-IP zu verpassen.

Allerdings kann es danach vorkommen, dass diese Rechner in einem Testverbund verbleiben und Szenarien des späteren Einsatzgebietes durchgespielt werden. Für diesen Zweck müssen Kollegen, deren Rechner im 192.168.10.X Netz sind auf das "Installation-LAN" und die Rechner mit Kunden-IP zugreifen können (z.B. auf die installierten Virtualisierungsserver). Unser Problem ist eben, dass sich diese Adresse dauernd ändern und aus den verschiedensten Bändern sein können.

Grüße
Andreas

Hallo Leute,

wir haben im Büro eine OPNsense Firewall laufen, die unser Netzwerk zum Internet abschottet und diverse weitere Funktionen übernimmt.

So haben wir einen Port konfiguriert, der zu unserem normalen Netzwerk führt und auf dem per DHCP IP-Adressen aus dem Band 192.168.10.X verteilt werden. Ein weiterer Port führt zu einem zweiten LAN, auf dem per DHCP 192.168.15.X Adressen verteilt werden. Vom Subnetz 15 soll nichts ins 10er dürfen, umgekehrt schon. Das funktioniert soweit auch. Dieses LAN ist ein Installations-LAN, in dem Kundenrechner im Verbund installiert und konfiguriert werden.

Am Ende werden diese Kundenrechner jedoch mit x-beliebigen IP-Adressen versehen, so wie sie nach Auslieferung arbeiten sollen.
Jetzt meine Frage: Besteht irgendwie die Möglichkeit das Routing so zu konfigurieren, dass es egal ist, welche IP-Adressen im Installationsnetzwerk betrieben werden, aber man diese immer vom 192.168.10.X Netzwerk erreicht?

Leider habe ich niemanden im Bekanntenkreis, der sein Internet auch von TPP bezieht.

Falls es jemanden interessiert, ich habe auf meinem Blog ein kleines HowTo geschrieben, wie ich mir meine OPNsense Appliance mit einem Supermicro-Board "gebastelt" und konfiguriert habe. Auch das Thema hier findet sich wieder:

https://www.imrazor.de/howto/selfmade-opnsense-appliance/

Der Techniker von TPP hat alles auf ihrer Seite geprüft und konnte den Fehler auch nicht finden. Mit dem Hinweis er möge doch mal bei dem Zulieferer anfragen, kam zurück, dass die meinte, es muss auch mit dem Gigaset funktionieren, da wäre nichts anderes einzustellen.

Also habe ich alles nochmal getestet und siehe da - ohne etwas an der Konfiguration zu ändern funktioniert es auf einmal ohne Fritzbox direkt mit dem Gigaset. Ein Schelm wer böses denkt. Die R-Kom hat hier sicherlich irgendeinen "Haken gesetzt" bzw. die Agent-Abfrage deaktiviert. Anders kann ich es mir jedenfalls nicht vorstellen.

Für mich ist das Thema gelöst, auch wenn ich nicht weiß, was es schlussendlich war.

Wahrscheinlich sind die selbst noch nicht auf die Idee gekommen das ein Kunde sein Gigaset ohne die FritzBox da anmelden könnte/würde.

Davon gehe ich auch mal ganz schwer aus. Wobei im IP Telefonie Forum einer geschrieben hat, er hätte von der R-Kom eine Anleitung erhalten, mit der es ging. Blöderweise hat er diese nicht gepostet.

Bin gespannt, was mein Provider sagen wird. Ich glaub ich hab die Kollegen eiskalt erwischt ;-)

Bis jetzt habe ich noch keine Rückmeldung vom Provider, werde sie aber nochmal drauf hinweisen.

Wenn ich die nächsten Tage mal Zeit hab, werde ich auch nochmal die Pakete beim Verbindungsaufbau durch das Gigaset direkt aufzeichnen. Da sollte man ja auch erkennen, weshalb genau die Verbindung nicht zustande kommt...

Naja, mal schaun, ob/was sie zurückschreiben. Am Wochenende haben sie nur ein Team zur Störungsbehebung, der normale Support ist nur unter der Woche besetzt. Aber klar, ich gebe dir schon recht, hinsichtlich Routerfreiheit nicht der Hit. V.a. ist die Dokumentation auf ihrer Seite auch mehr als dürftig, was wohl daran liegt, dass 99,9% der Kunden keine Ambitionen haben, etwas anderes zu betreiben als die Fritz!Box.

Dein Tipp für's Mitschreiben der Pakete ist sehr gut, das werde ich mal versuchen! An Wireshark dachte ich auch schon, wusste aber nicht, wie man mit der OPNsense alle Pakete auf VLAN40 aufzeichnet. Werde ich nach der Arbeit mal testen.

Die OPNsense Konfig habe ich sofort gesichert, als es mit der FB endlich ging ;-)

Nachtrag 1:

Hab es getestet: In den SIP Paketen steht als Benutzer genau der mir bekannte und der SIP-Registrar ist ebenfalls der gleiche. Das Passwort ist allerdings verschlüsselt. Als User-Agent wird natürlich die Fritzbox Kennung (Typ + FW-Stand) übermitelt. Ich sehe da jetzt aber keinen wirklichen Grund, weshalb es mit dem Telefon direkt nicht gehen sollte, außer der User Agent wird geprüft.

Nachtrag 2:
Aus den Paketen erkenne ich, dass die VoIP-Verbindung über einen anderen Provider erledigt wird (Regensburger Telekommunikations GmbH oder auch Glasfaser Ostbayern). Die Informationen dort sind genauso spärlich, aber ich habe einen Blog-Eintrag gefunden, in dessen Kommentare genau mein Problem angeprangert wird. Die Leute haben dein Eindruck, als würde der Provider VoIP an die Fritzbox binden: https://www.timoschindler.de/die-r-kom-und-das-routerwahlrecht/
Wer muss das Routerwahlrecht eigentlich durchsetzen? Die Bundesnetzagentur?

Nachtrag 3:
Hier geht es genau um mein Problem nur beim besagten Provider R-Kom:
https://www.ip-phone-forum.de/threads/c610a-ip-direkt-am-glasfaser-ostbayern-ftth-anschluss.298371/