Beiträge von X-Dimension

Den SIP Proxy gibt es soweit ich weiß nicht mehr. Es reicht im Prinzip aus die nötigen Ports freizugeben.
SIP nutzt im Normalfall die Ports 5060 und 5061, aber für die Sprachübertragungen selbst müssen noch bestimmte RTP Ports geöffnet werden, die je nach
Hersteller unterschiedlich sind. Manche Hersteller nutzen irgendwas über 9000, andere irgendwas über 7000 usw.
Hier hilft beim Telefonier-Versuch in die Firewall-Protokolle der Endian zu gucken, dann nach der IP des Gerätes zu filtern und gucken ob dort
irgendwas von DROP steht. Die angezeigten Ports dann nach und nach freigeben bis es läuft.

Nein, die Chiper stehen dort immernoch so drin wie ich es eingetragen habe und die Einstellungen aus der tmpl Datei werden auch für die jeweilige VPN Verbindung in der Clientconfig übernommen. Dann mache ich mal einen Bugreport.

Hallo,

nachdem unsere GW2GW Verbindung zwischen 2 Endians mittels OpenVPN über Wochen scheinbar gut funktionierte, musste ich mittlerweile
feststellen, dass es nun fast täglich Probleme nach der 24 Stunden Zwangstrennung der Telekom gibt.
Zwar wird der Tunnel zwischen beiden Endians aufgebaut, aber es gehen keine Daten durch.
Die Ursache konnte ich bereits anhand der Logs finden: Aus irgendwelchen Gründen, werden nach der Zwangstrennung auf beiden Seiten unterschiedliche MTU Werte
und unterschiedliche Chiper verwendet!
Trenne ich den Tunnel nun manuell über die Weboberfläche auf der Client-Seite und baue ihn wieder auf, funktioniert der Tunnel wieder Problemlos.

Ich habe nun gestern zum Testen schon auf der Serverseite den Chiper auf AES 256 CBC gestellt und dies auch auf der Clientseite in der /etc/openvpn/openvpnclient.conf.tmpl eingetragen, aber heute konnte ich anhand der Logs sehen, dass auf der Client-Seite AES 256 GCM verwendet wurde und nicht CBC wie in der config Datei eingetragen ist.
Nach der Zwangstrennung lagen auch die MTU Werte bei 1578 auf der Server und 1582 auf der Client Seite.
Nach der manuellen Trennung wird hingegen auf beiden ein MTU Wert von 1500 eingestellt.

Wie kann ich das Verbindungsproblem nach der Zwangstrennung am besten beheben und warum wird der Chiper auf der Client-Seite offenbar nicht aus der Konfigurationsdatei übernommen? Legt die Chiper-Einstellung ggf. nur einen Mindestwert fest?

Mal kurz zur Info:
Die Endian läuft bei uns jetzt hinter einem Deutschland LAN Connect SIP Trunk mit einem DrayTek Vigor 130 als VDSL Modem vorgeschaltet.
Für mich ist etwas irritierend dass wir für die Unify Anlage ausgehend sämtliche Ports freischalten mussten, weil das System sich scheinbar wahllos irgendwelche Ports für die RTP Verbindungen gesucht hat und es nicht ausreichte, nur die dem Telekom Techniker bekannten Ports freizuschalten.
Optimal finde ich das jetzt nicht, aber es funktioniert zumindest erst einmal.

Falls noch jemand eine Unify Anlage an einem SIP Trunk betreibt und mir sagen kann welche Ports er dabei freigeschaltet hat, dann schon einmal vielen Dank für eine Rückmeldung!

Hallo,

hat hier jemand vielleicht bereits eine Endian an einem Telekom Deutschland LAN SIP-Trunk Anschluss in Betrieb und eine VoIP Telefonanlage dahinter geschaltet?
Falls ja, würde mich mal interessieren wie ihr das Ganze konfiguriert habt, welche Ports in der Firewall freigeschaltet werden müssen usw.

Vielen Dank!

Vielen Dank! Irgendwie habe ich es jetzt hinbekommen.

Hallo,

ich sitze gerade an einer kniffligen Aufgabe:
Ich habe zwischen 2 Endians einen openVPN Tunnel eingerichtet (aktuell im Routing Modus mit TAP Device) der auch funktioniert.
Auf beiden Seiten gibt es die Netzwerkzonen GRÜN, ORANGE und BLAU.

Endian A:
Grün: 192.168.1.0
Orange: 192.168.2.0
Blau: 192.168.3.0

Endian B:
Grün: 192.168.4.0
Orange: 192.168.5.0
Blau: 192.168.6.0

Nun möchte ich es möglich machen, dass Netzwerkzone Orange von Seite A (192.168.2.0) durch den Tunnel mit Zone Blau (192.168.6.0) auf Seite B Kommunizieren kann.
Wie setze ich da die entsprechenden Routen?

Vielen Dank für einen kleinen Denkanstoß!

Hallo Wolfili,

ich habe die Lösung nun gefunden!
Bei der obigen Anleitung fehlte ein wesentlicher Punkt, der aber in folgender Anleitung zu finden war:

http://help.endian.com/hc/en-us/artic…2Net-Connection

Auf Seite des openVPN Servers muss für den Benutzeraccount, den die "Client-Endian" verwendet, noch der Punkt "Networks behind client"
ausgefüllt und das Client Netzwerk angegeben werden.
Wie du aber richtig gesagt hast, müssen dann noch auf beiden Seiten in der VPN-Firewall die entsprechenden Regeln gesetzt werden und dann funktioniert es!

Hallo,

ich versuche derzeit 2 Endians per OpenVPN miteinander zu verbinden.
Hierfür bin ich nach dieser Anleitung vorgegangen: http://help.endian.com/hc/en-us/artic…2Net-Connection

Zwar baut die Endian auf der Client-Seite zuverlässig den Tunnel auf, jedoch kann ich von PC-1 im lokalen Netz keinen PC im Remote-Netz erreichen und
umgekehrt. Die VPN Firewall hatte anfangs auf der lokalen Seite (Client) auch Pakete gedropt, aber dies konnte ich per VPN-Firewallregel lösen und jetzt sehe ich ein Accept im Protokoll. Allerdings scheint auf der Remoteseite (VPN-Server) nichts anzkukommen. In den Logs finde ich zumindest keine Anfragen.
In der VPN Firewall (Remote) darf der openVPN User mit dem der Tunnel auf dem Client aufgebaut wird, jedoch komplett in die zone grün.

Was habe ich hier übersehen?

Du kannst den Proxy auch auf "transparent" schalten, dann läuft jeglicher Datenverkehr generell über den Proxy. Dann muss an den Clients auch nichts eingestellt werden. Wir handhaben das in unseren Schulen immer so.

Hmpff...
Ich mag die Endian ja sehr, aber dieser Umgang mit der Community Edition... *kopfschüttel*. Eine Beta ist eine nicht-produktionsreife Vorabversion und ein Devel-Release ein aktueller Stand einer Enwicklerversion... Bei anderen Programmen gibt es dann in den Dokus große Warnhinweise, dass man die Software nur zum Testen und zur Fehlersuche einsetzen sollte. Früher haben die Jungs bei Endian ja auch Beta, RC und dann irgendwann die Finale Version raus gebracht. Was ist denn daran in den letzten Jahren so kompliziert geworden?

Nungut, ich werde die Beta mal an einem Standort testen und wenn es Probleme gibt zurück auf 3.0 rollen.
Die 3.0 war als "Devel-Release" ja auch recht stabil, wenn man mal von dem etwas verbugten Proxy absieht.

Sabine
Aktuell gibt es eigentlich keine "echten" DSL Modems mehr. Es sind alles nur noch kleine Router, auch wenn die Hersteller sie als Modem verkaufen.
Wenn man ein Annex-J fähiges DSL Modem sucht, gibt es aktuell auch nur noch die Auswahl zwischen dem Allnet 0333CJ und eben dem D-Link DSL-321.
Beide bieten eine Konfigurationsoberfläche an, beim Allnet ist sie eher inoffiziell und man findet die Information darüber nur über diverse Hardware-Foren, beim D-Link "Modem" kann man hingegen alles konfigurieren was man in jedem Router auch konfigurieren kann, jedoch gibt es hier zusätzlich einen Modus, mit dem es sich von einen Router als reines Modem ansteuern lässt. Aber auch in diesem Fall ist es über eine feste IP erreichbar.

ffischer
Die Standard-IP vom D-Link ist wie du bereits geschrieben hast 192.168.1.1 und wenn ich mich direkt an das D-Link hänge komme ich auch rauf, aber durch die Endian klappt es einfach nicht.
Muss ich noch irgendwo eine Route setzen? Ich habe auch schon versucht die IP des Modems entsprechend meines lokalen Subnetzes anzupassen, aber auch das klappte nicht.

Hallo,

ich bin etwas irritiert, warum es für die 3.0.5 schon einen eigenen Bereich im Forum gibt, obwohl diese doch eigentlich aktuell noch frühen Beta Status hat. Wie ist denn der Stand der Dinge? Wird es mittelfristig auch eine Finale Version der 3.0.5 geben, oder bleibt die Beta Version der "letzte Stand" und man entwickelt schon die nächsten Version? Die 3.0.0 wird ja in der Community Edition bis heute auch noch als "Development-Version" deklariert, ist aber trotzdem der letzte öffentliche Stand.

Vielen Dank für ein wenig Aufklärung.

Hallo,

ich habe ein D-Link DSL-321B Modem vor der Endian, das mir eine Konfigurationsoberfläche anbietet.
Wie kann ich durch die Endian auf die Konfigurationsoberfläche des Modems zugreifen um z.B. die DSL Verbindungsdaten einzusehen?

Habe 7 Endian Community Firewalls im Produktiveinsatz, sofern die Hardware unterstützt wird gibt es eigentlich kaum Probleme damit. Gibt es doch mal welche ist dieses Forum für mich immer noch Anlaufstelle Nummer 1!
Für mich gibt es aktuell auch keine wirklichen Alternativen wenn es nichts kosten darf.

Vielen Dank für den Tipp!

Erfahrungsgemäß werden "zu neue" Netzwerkkarten manchmal nicht erkannt, da die Endian noch einen Kernel 2.6.30 einsetzt.
Für aktuelle Intel Netzwerkkarten ist zwar mittlerweile ein Treiber-Paket "durchgesickert", dass man nachträglich Installieren kann, allerdings
will man als Einsteiger/Umsteiger ja dass alles möglichst einfach funktioniert und mann gleich nach der Installation mit seiner
Firewall los legen kann.
Aktuelle Prozessoren und Mainboard-Chipsätze sind hingegen meist kein Problem, ich habe zum Beispiel auch Endians mit Intel Core-i3-4xxx und Intel C224 Chipsatz im Einsatz.

Ich versuche gerade verzweifelt zwei Endians miteinander per OpenVPN Gw2Gw zu verbinden.
Dabei habe ich ein ähnliches Problem wie hier:
https://www.efw-forum.de/www/forum/viewtopic.php?f=77&t=1891&start=10

Die Verbindung selbst steht zwar zwischen beiden Endians, aber ich komme von PCs an
Standort B (Client-Konfiguration) nicht auf Standort A (Server-Konfiguration) und umgekehrt.
Ich kann jedoch von der Web-Konsole der Endian an Standort B sämtliche PCs an Standort A anpingen,
jedoch von den PCs die dahinter hängen nicht. (umgekehrt geht es übrigens nicht)

Die VPN Firewall ist an beiden Standorten deaktiviert, auf Serverseite werden zwei Netzwerke
(192.168.11.0/24 und 192.168.22.0/24) gepusht und die Schnittstelle ist gebridged auf Zone Grün.
An Standort B ist Clientseitig routing aktiviert (also Default Einstellung),

Woran könnte es haken?

Das trifft allerdings nicht auf die Community Edition zu. (getestet mit Version 3.0)

Mit folgendem Skript kann man seine Endian testen:

curl -k https://shellshocker.net/shellshock_test.sh | bash

Im Normalfall sollte bei der Community Edition fast überall "vulnerable" stehen.

Als "Workaround" kann man die bereits gepatchte bash Version von Oracle Linux 4 installieren:

rpm -Uvh http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/bash-3.0-27.0.3.el4.i386.rpm

Führt man anschließend das oben genannte Skript nun wieder aus, sollte überall "not vulnerable" angezeigt werden.

Das ist zwar nicht die "schönste" Lösung, aber da Endian für die Community Edition quasi keine Updates mehr heraus bringt,
ist das soweit mir bekannt ist der einzige Weg sie gegen Shellshock zu schützen.

Danke für den Tipp mit Securepoint, die Systeme werde ich mir bei Gelegenheit mal genauer ansehen.

Aktuell habe ich meine beiden "Problemkinder" mit der Endian Community Version doch noch zum laufen bringen können.
Die Treiber-Probleme habe ich mit einem 3.x Kernel aus der Brasilianischen Endian Gemeinschaft umgehen können
und um mehr als 3 Zonen zu nutzen, hat für meinen Fall folgender "Workaround" ausgereicht:

http://help.endian.com/entries/253918…ne-in-sub-zones

Ich habe die Zone Grün einfach auf zwei Netzwerkschnittstellen unterteilt und über Interzone-Firewallrichtlinien die Netzwerkverbindung
zwischen den zwei Schnittstellen untersagt. Den Teil "Bind an IP Address or Subnet to the Interface" dieser Anleitung brauchte ich in meinem Fall nicht.
Es ist sicher nicht die "schönste Lösung" aber es macht erstmal was es soll.

Schade finde ich nur, dass ich auch einen Monat nach meiner E-Mail-Anfrage immer noch keine Antwort vom Endian Support bekommen haben.
Das war vor zwei Jahren noch ganz anders, dort hatte man mir beispielsweise sogar einen fehlenden Treiber zur Verfügung gestellt. Allerdings scheinen heutzutage offenbar nur noch die zahlenden Kunden eine Antwort auf E-Mails zu erhalten.