21
VOIP Firewallregeln für OPNSENSE mit Telekom Anschluß (Magenta S)
Hi,
ich suche seit geraumer Zeit nach verlässlichen Aussagen zu den VOIP Firewallregeln für die Opnsense für einen Telekom-Anschluß (Magenta S, keine feste externe IP Adresse) in dem Setting:
Internet=>Opnsense=>Switch=>PBX
Und, ja, ich habe alle und ich meine wirklich alle Posts im Forum gelesen, insbesondere die von Aqui.
Die meisten der Beispiele betreffen andere Provider, Cloud gehostete Dienste oder irgendwelche seltsame Lan-Konfigurationen.
Jeder schreibt etwas anderes, was ziemlich frustrierend ist.
Mal sollen Ports per NAT auf die PBX forwardet werden (was dazu führt, daß die PBX mit Anfragen auf 5060 aus dem gesamten Internet geflutet wird, weil ja die Source nicht eingeschränkt wird), mal soll outbound NAT mit manuellen Regeln erstellt werden, mal sollen die Ports 5060 und 5061 von Lan zu Wan freigegeben werden, mal mit Stun, mal ohne.
Ist es für diese in Deutschland wohl am häufigsten anzutreffende 0815 Konstellation nicht möglich, verbindliche Angaben zu bekommen??
Die Telekom selbst empfiehlt unter
Sip Trunk technische Unterlage
unter 5.8 folgendes:
UDP (out): Ports 53, 123,3478
UDP (in): Ports 5070, 5080
TCP (out): Port 53, 80, 443, 5060, 5061
in/out ist immer aus Sicht der TK-Anlage gemeint
Plattformseitiger RTP Portrange ist 9000-27000.Die RTP-Ports an der TK-Anlage können von dieser frei gewählt werden (>1023)Http(s) wird für das Telefoniecenter benötigt.Je nach TK-Anlagen-Konfiguration können diese Ports auch abweichenoder eingeschränkt sein
und in 11.3:
IP & Port-Ranges
Für vom Kunden initiierte Verbindungen zu SP-SSEs der Deutschen Telekom werden die in Kapitel 5.8 genannten Zielports
verwendet.
Da jede Verbindung vom Client initiiert und am Leben erhalten werden soll, werden TCP-Sitzungen auf Basis von RFC5923
wiederverwendet. NAT-Pinholing- und Firewall-Richtlinien sollten für diese einzelne Sitzung dynamisch durch das erste TCP-Paket
festgelegt werden.
Der Quellport für RTP wird durch die PBX definiert und es wird davon ausgegangen, dass alle NAT-Bindungs- und Firewall-Regeln
durch die ursprünglichen ausgehenden RTP-Pakete festgelegt werden. Der Ziel-Port für die RTP-Payload wird innerhalb des SDP-
Angebots/Antwort von SP-SSE definiert.
Es wird empfohlen, für RTP und RTCP ein aufeinander folgendes Paar Ports gemäß RFC 3550 zu verwenden. Auch das RTCP-
Attribut in SDP wird gemäß RFC 3605 unterstützt.
Da symmetrisches RTP verwendet wird, ist es nicht notwendig, Ports für eingehenden Datenverkehr zu konfigurieren.
Es wird empfohlen, kein statisches Port-Mapping zu verwenden, sondern dynamisches Pinholing in Kombination mit Keep-Alive.
Wenn Sie den Static Mode verwenden, müssen Sie Ihren listening port für SIP definieren. Die Verwendung des Static Mode ohne
vom Client initiierte Verbindungen würde zu einem hohen Risiko eines Pinhole für die SIP-Kommunikation führen. Aufgrund
hochskalierbarer Cluster von SP-SSEs der Deutschen Telekom ist es nicht geeignet, die Quell-IPs der Deutschen Telekom
einzuschränken. Es ist vorzuziehen, stattdessen Client-initiierte Verbindungen zu verwenden und jeglichen eingehenden
Datenverkehr außer dieser Verbindung zu blockieren.
Bitte beachten Sie, dass die Deutsche Telekom über verschiedene Mechanismen verfügt, um jede Art von Missbrauch zu vermeiden.
Daher ist es nicht erlaubt, beliebig viele TCP-Sessions einzurichten (z.B. eine separate TCP-Session für jeden Anruf / INVITE), da die
Anzahl der TCP-Sessions auf fünf pro IP-Adresse beschränkt ist.
Kann mir jemand mit diesen Angaben sagen, wie die Opensense für die Telekom zu konfigurieren ist?
1000 Dank, simbea
ich suche seit geraumer Zeit nach verlässlichen Aussagen zu den VOIP Firewallregeln für die Opnsense für einen Telekom-Anschluß (Magenta S, keine feste externe IP Adresse) in dem Setting:
Internet=>Opnsense=>Switch=>PBX
Und, ja, ich habe alle und ich meine wirklich alle Posts im Forum gelesen, insbesondere die von Aqui.
Die meisten der Beispiele betreffen andere Provider, Cloud gehostete Dienste oder irgendwelche seltsame Lan-Konfigurationen.
Jeder schreibt etwas anderes, was ziemlich frustrierend ist.
Mal sollen Ports per NAT auf die PBX forwardet werden (was dazu führt, daß die PBX mit Anfragen auf 5060 aus dem gesamten Internet geflutet wird, weil ja die Source nicht eingeschränkt wird), mal soll outbound NAT mit manuellen Regeln erstellt werden, mal sollen die Ports 5060 und 5061 von Lan zu Wan freigegeben werden, mal mit Stun, mal ohne.
Ist es für diese in Deutschland wohl am häufigsten anzutreffende 0815 Konstellation nicht möglich, verbindliche Angaben zu bekommen??
Die Telekom selbst empfiehlt unter
Sip Trunk technische Unterlage
unter 5.8 folgendes:
UDP (out): Ports 53, 123,3478
UDP (in): Ports 5070, 5080
TCP (out): Port 53, 80, 443, 5060, 5061
in/out ist immer aus Sicht der TK-Anlage gemeint
Plattformseitiger RTP Portrange ist 9000-27000.Die RTP-Ports an der TK-Anlage können von dieser frei gewählt werden (>1023)Http(s) wird für das Telefoniecenter benötigt.Je nach TK-Anlagen-Konfiguration können diese Ports auch abweichenoder eingeschränkt sein
und in 11.3:
IP & Port-Ranges
Für vom Kunden initiierte Verbindungen zu SP-SSEs der Deutschen Telekom werden die in Kapitel 5.8 genannten Zielports
verwendet.
Da jede Verbindung vom Client initiiert und am Leben erhalten werden soll, werden TCP-Sitzungen auf Basis von RFC5923
wiederverwendet. NAT-Pinholing- und Firewall-Richtlinien sollten für diese einzelne Sitzung dynamisch durch das erste TCP-Paket
festgelegt werden.
Der Quellport für RTP wird durch die PBX definiert und es wird davon ausgegangen, dass alle NAT-Bindungs- und Firewall-Regeln
durch die ursprünglichen ausgehenden RTP-Pakete festgelegt werden. Der Ziel-Port für die RTP-Payload wird innerhalb des SDP-
Angebots/Antwort von SP-SSE definiert.
Es wird empfohlen, für RTP und RTCP ein aufeinander folgendes Paar Ports gemäß RFC 3550 zu verwenden. Auch das RTCP-
Attribut in SDP wird gemäß RFC 3605 unterstützt.
Da symmetrisches RTP verwendet wird, ist es nicht notwendig, Ports für eingehenden Datenverkehr zu konfigurieren.
Es wird empfohlen, kein statisches Port-Mapping zu verwenden, sondern dynamisches Pinholing in Kombination mit Keep-Alive.
Wenn Sie den Static Mode verwenden, müssen Sie Ihren listening port für SIP definieren. Die Verwendung des Static Mode ohne
vom Client initiierte Verbindungen würde zu einem hohen Risiko eines Pinhole für die SIP-Kommunikation führen. Aufgrund
hochskalierbarer Cluster von SP-SSEs der Deutschen Telekom ist es nicht geeignet, die Quell-IPs der Deutschen Telekom
einzuschränken. Es ist vorzuziehen, stattdessen Client-initiierte Verbindungen zu verwenden und jeglichen eingehenden
Datenverkehr außer dieser Verbindung zu blockieren.
Bitte beachten Sie, dass die Deutsche Telekom über verschiedene Mechanismen verfügt, um jede Art von Missbrauch zu vermeiden.
Daher ist es nicht erlaubt, beliebig viele TCP-Sessions einzurichten (z.B. eine separate TCP-Session für jeden Anruf / INVITE), da die
Anzahl der TCP-Sessions auf fünf pro IP-Adresse beschränkt ist.
Kann mir jemand mit diesen Angaben sagen, wie die Opensense für die Telekom zu konfigurieren ist?
1000 Dank, simbea
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 512277
Url: https://administrator.de/contentid/512277
Printed on: April 16, 2024 at 07:04 o'clock
21 Comments
Latest comment
Moin,
was bei mir funktioniert hat ist folgendes:
Port 5060 TCP nur aus dem Telekom Netz von extern auf die PBX forwarden.
Die RTP ports static durchs NAT schieben.
Das ganze eben auf einer PfSense. Aber wird auf der OpenSense identisch funktionieren.
Alternative musst du sipproxd nutzen, konfigurieren und "keine!" portforwarding Regel anlegen.
Gruß
Spirit
was bei mir funktioniert hat ist folgendes:
Port 5060 TCP nur aus dem Telekom Netz von extern auf die PBX forwarden.
Die RTP ports static durchs NAT schieben.
Das ganze eben auf einer PfSense. Aber wird auf der OpenSense identisch funktionieren.
Alternative musst du sipproxd nutzen, konfigurieren und "keine!" portforwarding Regel anlegen.
Gruß
Spirit
Port 5060 TCP nur aus dem Telekom Netz von extern auf die PBX forwarden.
Ja, das wäre schön..aber was genau ist denn das Telekom Netz?? Welche IP Adressen oder Netze??
Die RTP ports static durchs NAT schieben.
Das verstehe ich nicht. Erstens welche und zweitens wie und wo konfiguriere ich das??
Gruß Simbea
Also ich hab nicht eine einzige Weiterleitung drin und es funktioniert mit Pfsense. Registriert sind die Nummern in ner OpenScape Business, die erkennt den Anschluss als symmetrisches NAT. Einzig zum Spaß hab ich die Kommunikation über Port 5060 auf das Netz 217.0.0.0/16 eingeschränkt, da dort die Telekom SIP Server stehen.
Das Ganze ist natürlich nur ein Anschluss mit Einzelrufnummern, SIP Trunk kann ich dir aber meinetwegen auch noch mal durchtesten bei Bedarf.
Das Ganze ist natürlich nur ein Anschluss mit Einzelrufnummern, SIP Trunk kann ich dir aber meinetwegen auch noch mal durchtesten bei Bedarf.
in dem Setting: Internet=>Opnsense=>Switch=>PBX
Leider sagt das rein gar nix ob du die OpenSense mit einer Routerkaskade:IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
oder direkt mit einem NUR Modem angebunden hast ??
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Sprich wird das Internet direkt auf der Firewall terminiert (Modem) oder ist ein NAT Router davor ?
Beides hat entscheidenden Einfluss auf die Regeln.
Eigentlich steht aber auch alles in den Weiterführenden Links im o.a. Firewall Tutorial unter der Rubrik "VoIP bzw. Telefonie mit FritzBox oder Anlage hinter pfSense Firewall:"
Wie Kollege @shadynet oben schon sagt müsste man bei Verwendung von STUN in der lokalen Anlage eigentlich nix eintragen. Ohne STUN musst du die dynamische RTP Portrange freigeben.
P.S.: Irgendwas stimmt mit deiner Formatierung oben nicht. Du hast da irgendwo 2 Doppelsterne zuviel so das das alles fett gedruckt ist.
OK, sorry, hatte ich vergessen:
Internet => Vigor165 => Opnsense =>Switch => PBX.
Also keine Routerkaskade.
Internet => Vigor165 => Opnsense =>Switch => PBX.
Also keine Routerkaskade.
...Und welche PBX?
ansitel IPsmart
Was schreibt denn der Hersteller zu den Firewall Ports?
Wenn die Anlage Stun unterstützt, diesen nutzen und nur ausgehend die Ports 5060 und 10000-20000 UDP durchlassen. Alternativ ausgehend zum Testen Ports 1-65535 UDP erlauben.
Wenn der Stun geht, brauchst Du kein Portforwarding.
P.S.: Gerade noch gesehen.... Du siehst in der falschen Unterlage nach: Magenta S hat Einzelnnummern, keinen SIP Trunk.
Wenn der Stun geht, brauchst Du kein Portforwarding.
P.S.: Gerade noch gesehen.... Du siehst in der falschen Unterlage nach: Magenta S hat Einzelnnummern, keinen SIP Trunk.
nur ausgehend die Ports 5060 und 10000-20000 UDP durchlassen.
Na ja, ausgehend am internen LAN Port des Voice Netzes hat man ja zuallererst mal eine Scheunentor Regel das man erstmal alles erlaubt. Da stellt man sich ja nun wohl kaum selber ein bein bei der Setup Phase indem man sich dort Hardcore Regeln erstellt. Das kommt später wenn alles geht. So weiss man wenigstens das es dann nur an falschen Regeln liegen kann !Wenn man also intern erstmal alles aus dem Subnetz erlaubt und STUN verwendet wird sollte es eigentlich schon klappen ! Ansonsten wie immer: Ins Firewall Filter Log sehen ! Da steht ja genau drin was hängenbleibt.
Ansonsten wie immer: Ins Firewall Filter Log sehen ! Da steht ja genau drin was hängenbleibt.
Stimmt....habs gerade nochmal nachgesehen. Die Telekom hält sich da nicht an irgendwelche Port-Ranges. Deswegen habe ich ausgehend UDP 1-65535 erlaubt.
Leider ist die Dokumentation der verwendeten PBX mehr als dürftig was Firewall-Regeln angeht.....da sind andere Hersteller besser aufgestellt.
Wir verwenden bei uns den Magenta M und derzeit noch den SIP Trunk Pure. Beide laufen damit.
P.S.: Noch eine Anmerkung am Rande.....Du solltest die Telefonie in ein separates VLAN packen, gerade, wenn solche Scheunentor-Regeln erforderlich sind.
Deswegen habe ich ausgehend UDP 1-65535 erlaubt.
Das sollte der TO erstmal nicht so spezifisch machen ! Das wäre wenig zielführend in einer Troubleshooting Phase 
Auf dem lokalen LAN Segment in der die Anlage steckt reicht:
PASS, IP Source: <lokales_LAN_net> Port: any, Destination: any, Port: any
erstmal als Regel und fertig ist der Lack.
Besser man schafft sich nich gleich vorab extra Hürden durch Fesseln im Regelwerk !!
Telefonie gehört bei Firmennetzen rein schon aus arbeitsrechtlichen Gründen in ein separates VLAN.
Damit kommt die PBX nicht zur Registrierung der Telefonnummern, die Logs laufen mit fehlgeschlagenen Registrierungsversuche voll.
Die PBX und DECT Basis steht selbstverständlich im eigenen VLAN, das ist hier jedoch völlig irrelevant.
Und ich halte nochmal fest: Magenta S sind tatsächlich Einzelrufnumern und KEIN Sip-Trunk.
Die bisher aufgelaufenen Threads bestätigen meinen Eindruck in der Ausgangsfrage, dass hier anscheinend jeder seine eigene Vorstellung hat, wie es zu konfigurieren ist.
Das ist frustrierend, immerhin dürfte das Setting nicht selten anzutreffen sein.
Hat keiner eine klare Anleitung??
Gruß simbea
Die PBX und DECT Basis steht selbstverständlich im eigenen VLAN, das ist hier jedoch völlig irrelevant.
Und ich halte nochmal fest: Magenta S sind tatsächlich Einzelrufnumern und KEIN Sip-Trunk.
Die bisher aufgelaufenen Threads bestätigen meinen Eindruck in der Ausgangsfrage, dass hier anscheinend jeder seine eigene Vorstellung hat, wie es zu konfigurieren ist.
Das ist frustrierend, immerhin dürfte das Setting nicht selten anzutreffen sein.
Hat keiner eine klare Anleitung??
Gruß simbea
Eine OpenScape Business dürfte nicht mit mit meiner PBX vergleichbar sein, ohne Portfreigabe funktioniert hier nix.
Gruß simbea
Gruß simbea
Zitat von @simbea:
Eine OpenScape Business dürfte nicht mit mit meiner PBX vergleichbar sein, ohne Portfreigabe funktioniert hier nix.
Gruß simbea
Eine OpenScape Business dürfte nicht mit mit meiner PBX vergleichbar sein, ohne Portfreigabe funktioniert hier nix.
Gruß simbea
Naja, wo ne Osbiz läuft läuft gefühlt alles
dagegen ist deine ja ein Spielzeug.Zitat von @simbea:
Damit kommt die PBX nicht zur Registrierung der Telefonnummern, die Logs laufen mit fehlgeschlagenen Registrierungsversuche voll.
Welche?Damit kommt die PBX nicht zur Registrierung der Telefonnummern, die Logs laufen mit fehlgeschlagenen Registrierungsversuche voll.
Und ich halte nochmal fest: Magenta S sind tatsächlich Einzelrufnumern und KEIN Sip-Trunk.
Ist meistens so, außer man hat einen SIP Trunk Pure oben drauf.Die bisher aufgelaufenen Threads bestätigen meinen Eindruck in der Ausgangsfrage, dass hier anscheinend jeder seine eigene Vorstellung hat, wie es zu konfigurieren ist.
Naja, STUN (wobei ichs nicht nutze) anschalten, Provider einrichten, geht. TK-Anlage darf über alle Ports ins Internet. Das war so der grundlegende Tenor, wirklich viele Abweichungen sehe ich da gerade nicht.Das ist frustrierend, immerhin dürfte das Setting nicht selten anzutreffen sein.
Hat keiner eine klare Anleitung??
Was ist denn klar?Hat keiner eine klare Anleitung??
Erlaube der TK-Anlage erstmal alles: IP-TK-Anlage -> WAN, Protocol any, Ports any, alles any.
Freischaltungen von außen nach innen nicht nötig, weil symmetrisches RTP genutzt wird, gleicher Port ein und ausgehend.
Welchen Fehler gibts denn bei der Registrierung? Du gehst auch ganz sicher über den richtigen Anschluss raus? Nicht dass es zwei oder mehr gibt und die TK möchte gerne über den falschen registrieren. Also: Fehlermeldung?
Das VLAN darf auch ins Internet?
Eine OpenScape Business dürfte nicht mit mit meiner PBX vergleichbar sein, ohne Portfreigabe funktioniert hier nix.
Irgendwie unverständlich....Hier werkeln diverse Auerswald 4000 VoIP mit der pfSense. Da musste man rein gar nichts einstellen. Das lief so out of the box mit den Default Settings und aktiviertem STUN.
Eigentlich sollten andere PBXen da nicht anders funktionieren, da die VoIP Protokolle weltweit standartisiert sind ?!
Warum nimmst du nicht einfach mal einen Wireshark und siehst dir den SIP Regristrierungs Traffic mal an, dann weisst du doch sofort wo es kneift.
Ganz einfach: Weil ich das nicht kann und nicht verstehe!
Könnte ich es, müßte ich vermutlich nicht in diesem Forum um Hilfe bitten.
Vieleicht hilft es ja, wenn mir mal jemand erklärt, wo und wie ich Stun aktiviere.
Soweit mir bekannt ist, ist ein Stun-Server ein Dienst im Internet, der es einem lokalen Client ermöglicht, die Kommunikation mit einem VoIP-Anbieter außerhalb des lokalen Netzwerks aufzubauen.
Somit muß also, wenn ich das richtig verstehe auf der PBX der Zugriff auf die Telekom STUN-Server eingestellt werden.
Auf der Firewall müssen dann die dabei vewendeten Ports vom LAN zu WAN freigegeben werden.
Ist das korrekt?
Weiß jemand, auf welche IP Adressen diese Server stehen und über welche Ports und Protokolle sie kommunizieren.
Das mit dem Stun Server habe ich nämlich definitiv noch nicht versucht.
simbea
Gruß, simbea
Könnte ich es, müßte ich vermutlich nicht in diesem Forum um Hilfe bitten.
Vieleicht hilft es ja, wenn mir mal jemand erklärt, wo und wie ich Stun aktiviere.
Soweit mir bekannt ist, ist ein Stun-Server ein Dienst im Internet, der es einem lokalen Client ermöglicht, die Kommunikation mit einem VoIP-Anbieter außerhalb des lokalen Netzwerks aufzubauen.
Somit muß also, wenn ich das richtig verstehe auf der PBX der Zugriff auf die Telekom STUN-Server eingestellt werden.
Auf der Firewall müssen dann die dabei vewendeten Ports vom LAN zu WAN freigegeben werden.
Ist das korrekt?
Weiß jemand, auf welche IP Adressen diese Server stehen und über welche Ports und Protokolle sie kommunizieren.
Das mit dem Stun Server habe ich nämlich definitiv noch nicht versucht.
simbea
Gruß, simbea
Oder mache ich hier einen Denkfehler und der Stun Server muß nur auf dem Client (in meinem Fall eine Gigaset N670 Pro DECT Basis, die an der Ansitel PBX hängteingetragen werden?
Wenn du Stun nutzt, ist kein Portfarwarding nötig.
Außer vielleicht 5060.
Stun informiert ja quasi über das NAT hinweg wie die dahinter liegenden Dienste zu erreichen sind. Respektiv eben die verwendeten Ports zur Kommunikation.
Außer vielleicht 5060.
Stun informiert ja quasi über das NAT hinweg wie die dahinter liegenden Dienste zu erreichen sind. Respektiv eben die verwendeten Ports zur Kommunikation.
All die bisherigen Kommentare der Experten waren wenig hilfreich!
Für die Margenta Tarife (das sind, wie oben richtig beschrieben Einzelrufnummern und KEIN Sip-Trunking) sind folgende Settings auf einer OPNSENSE erforderlich:
Hier ist die Lösung:
Unter Nat => Outbound
-zuerst den Button "Hybrid rule generation setzten". Damit werden die automatisch generierten Regeln übernommen und eine manuelle kann eingefügt werden.
-neue Manual Rule generieren:
Interface: WAN
TCP/IP Version: Ipv4
Protocol: any
Source Adress: die LAN Adresse der PBX
source post: any
Destination adress: any
Destination port any
Translation/ target: Interface address
und last but not least Static port: angehakt => dieser Punkt ist wichtig!!!
Weiterhin müssen vom LAN zu WAN die Ports freigegeben werden, mit denen die PBX mit den WAN seitigen Servern kommuniziert, in meinem Fall 5060 und 5061, dieser Punkt lässt sich aber auch leicht über das Log klären.
UND DAS WARS !!!!!!!!!!!!!!!!!!!!
Nix Port forwarding und somit eine direkte Erreichbarkeit vom WAN und damit einer potientiell unsicheren Konfiguration der dafür nicht ausgelegten PBX!!! NIX sipproxd !!! Und vor allem nix Sip-Trunk !!!
Bin ein wenig enttäuscht über die Experten, Jungs da hättet ihr auch früher mal drauf kommen können.
Trotzdem Dank ans Forum,
Gruß Simbea.
Für die Margenta Tarife (das sind, wie oben richtig beschrieben Einzelrufnummern und KEIN Sip-Trunking) sind folgende Settings auf einer OPNSENSE erforderlich:
Hier ist die Lösung:
Unter Nat => Outbound
-zuerst den Button "Hybrid rule generation setzten". Damit werden die automatisch generierten Regeln übernommen und eine manuelle kann eingefügt werden.
-neue Manual Rule generieren:
Interface: WAN
TCP/IP Version: Ipv4
Protocol: any
Source Adress: die LAN Adresse der PBX
source post: any
Destination adress: any
Destination port any
Translation/ target: Interface address
und last but not least Static port: angehakt => dieser Punkt ist wichtig!!!
Weiterhin müssen vom LAN zu WAN die Ports freigegeben werden, mit denen die PBX mit den WAN seitigen Servern kommuniziert, in meinem Fall 5060 und 5061, dieser Punkt lässt sich aber auch leicht über das Log klären.
UND DAS WARS !!!!!!!!!!!!!!!!!!!!
Nix Port forwarding und somit eine direkte Erreichbarkeit vom WAN und damit einer potientiell unsicheren Konfiguration der dafür nicht ausgelegten PBX!!! NIX sipproxd !!! Und vor allem nix Sip-Trunk !!!
Bin ein wenig enttäuscht über die Experten, Jungs da hättet ihr auch früher mal drauf kommen können.
Trotzdem Dank ans Forum,
Gruß Simbea.
1
Das Problem ist in der Konfiguration die Opnsense. Mit einer pfsense wärst Du schneller am Ziel gewesen.