Auerswald Compact 3000 VOIP

Dunkelfalke

Hallo,

ich glaube das Problem ist nicht das Portforwarding.

Habe gerade noch mal alles neu eingerichtet mit Aliasen (Screenshot).

Auerswald -> interne IP Adresse der Anlage
VOIP_Ports -> UDP Ports 5060, 5070, 5080, 30000-31000, 40000-41000 (lt. Telekom Support Seite)

Zusätzlich habe ich zum testen noch Port 80 dazu genommen.

Wenn ich jetzt via Smartfon mit einem Browser auf meine öffentliche IP Adresse gehe dann lächelt mich die Login Seite der Auerswald an….

Tjo, jetzt bin ich ratlos.

Mfg
DF

Port_Forward_Alias.jpg_thumb

-flo- 0

SIP und RTP sind UDP basiert. Stell das mal um!

Dann dürfte das schon laufen (wenn Deine Auenwald keine Ports < 5000 verwendet. :-)

Die angegebene Ports von der Telekom brauchst Du nicht. Das sind aus Deiner Sicht Zielports oder aus Telekom-Sicht Source-Ports. Das kannst Du ignorieren.

Was Du brauchst sind die SIP- und RTP-Ports. Schau da nach:

"Eine Auflistung der in der TK-Anlage verwendeten Ports finden Sie im Konfigurationsmanager der TK-Anlage unter Service > Portübersicht." (Quelle: Handbuch zur Anlage)

Damit kannst Du Deine Freigaben passend eingrenzen.

-flo-

Dunkelfalke

Autsch, das kommt davon wenn man zu lange auf den Bildschirm schaut….

Habs natürlich auf UDP umgestellt, lt. der Portübersicht der Anlage (und einem Fritzbox Forum) benutzt die Anlage

5062-5069 und 49152-49408

Wenn ich diese und die Telekom Angaben (30000:31000, 40000:41000) mit drinn lasse bekomme ich einen Showstates wie im Screenshot dargestellt

Zumindest scheint sich die Auerswald 192.168.111.111 und tel.t-online.de 217.0.23.100 schonmal nicht ganz unbekannt zu sein.

Allerdings scheitert die Anlage beim Anmeldung immer noch mit einem Timeout.

Die Zugangsdaten habe ich übrigens heute noch mit Phonerlite gestestet, mit der Software ist die Rufnummer sofort erreichbar und bei der Telekom somit alles ok.

ShowStates.jpg_thumb

-flo- 0

Also mit den Einstellungen seitens pfSense müßte sich die Anlage wirklich im Netz anmelden können. Bei mir sieht das mit einer FB Fon ganz ähnlich aus. Siehst Du die SIP-Ports im Firewall-Log? Die Telefonate sind dann noch eine andere Sache. Wenn Du STUN aktiviert hast, dann das mal abschalten. Das ist wegen des Static Port unnötig.

@Dunkelfalke:

Die Zugangsdaten habe ich übrigens heute noch mit Phonerlite gestestet, mit der Software ist die Rufnummer sofort erreichbar und bei der Telekom somit alles ok.

Das heißt aus Deinem Netz hinter der pfSense? Klappen da auch Telefonate? Dann ist die pfSense ja offenbar ok eingerichtet. Sieht dann wirklich eher nach den Einstellungen in der Auerswald aus …

-flo-

Dunkelfalke

Stun habe ich mal komplett abgeschaltet, TK Anlage neu gestartet und gewartet bis zur Fehlermeldung "Timeout" kommt.

Das Firewall Log mit dem Zeitraum ist nicht vie los, die Kommunikation wird IMHO durchgelassen.

Der Software Client zum testen hat auch geklingelt als ich den mit dem Handy angerufen hab. Wie der sich jetzt aber durchtunnelt hab ich keine Ahnung. In der pfsense ist für den überhaupt nichts konfiguriert.

Mfg
DF

Firewall_Log.jpg_thumb

Dunkelfalke

Hallo,

kleines Update:

Hab heute eine Fritzbox 7050 via Kleinanzeigen für 10,-EUR gekauft, die zwei Aliase eingerichtet, VOIP Daten in die Fritzbox geklimmert und Telefon geht sofort, Zeitaufwand 5min.

Ich hab grad nen ziemlichen Hals auf Auerswald…..seufz

Mfg
DF

-flo- 0

Kann ich verstehen. Es wäre schon interessant zu wissen, worin das Problem mit der Auerswald liegt. Aber wenn Du mit Hilfe der FritzBox telefonieren kannst, läßt der Antrieb zur Fehlersuche wahrscheinlich stark nach …

-flo-

Dunkelfalke

Ne, das Rätsel will ich lösen, die 14 Tage Rückgabefrist der Auerswald sind leider schon rum. Support Anfrage bei Auerswald läuft.

Immerhin ist hier jetzt erstmal der Druck aus dem Kessel "Warum können wir immer noch nicht telefonieren?"…..;-)

Mfg
DF

Docadmin

Grüße,

wir hatten auch eine VoIP-Anlage hinter der pfSense …. nachdem ALLES nicht funktioniert hat und immer wieder der von Dir beschrieben Fehler auftauchte, haben wir ein 2. Netz "neben" der pfSense gebaut - damit funktionierte es dann tadellos innerhalb kürzester Zeit.

Meiner Ansicht nach liegt der Fehler nicht bei Auerswald .....

@Docadmin:

Grüße,

wir hatten auch eine VoIP-Anlage hinter der pfSense …. nachdem ALLES nicht funktioniert hat und immer wieder der von Dir beschrieben Fehler auftauchte, haben wir ein 2. Netz "neben" der pfSense gebaut - damit funktionierte es dann tadellos innerhalb kürzester Zeit.

Kann man natürlich auch machen, nur wenn dann jemand an eines der Telefone ran kommt und
damit ein Wochenende nach Japan telefoniert, ist das auch nicht so pralle. :o

Meiner Ansicht nach liegt der Fehler nicht bei Auerswald …..

Das mag schon sein nur bei pfSense auch nicht, denn dort kann man ein FreePBX
Paket installieren und das funktioniert damit auch sehr gut, also denke ich mal eher
das es hier an der Konfiguration der pfSense liegt.

Ist echt nicht böse gemeint oder sogar gehässig nur ich kenne eben Leute die unterschiedliche
VOIP Anlagen betreiben vor der pfSense, in der DMZ, auf der pfSense und nur auf der vorgelagerten
AVM FB zu Hause, dort funktioniert das überall, also ist da einfach nur eine kleine Ungereimtheit die
@Dunkelfalke garantiert nur übersehen hat.

Docadmin

Ja, er hat mit Sicherheit was übersehen … die pfSense ist wohl eine der Firewalls, die für Bastler und Vielklicker gemacht ist.

In meinen Augen ein Produkt welches man nicht für den professionellen Einsatz empfehlen sollte ... ach doch...., wenn der Admin "Eh-Da"-Kosten sind.

JeGr

die pfSense ist wohl eine der Firewalls, die für Bastler und Vielklicker gemacht ist.
In meinen Augen ein Produkt welches man nicht für den professionellen Einsatz empfehlen sollte …

Halte ich für eine völlig falsche Aussage. Und da ich keine Verbindung zum pfSense Team irgendwelcher Art habe (bevor mir das mal wieder unterstellt wird), kann ich das m.E. auch vertreten.
Ich habe an anderer Stelle dir bereits geschrieben, dass das auch stark von der Ausgangshaltung abhängt. Wenn ich eine Windows-Klickibuntu-fertig Firewall haben möchte, dann ist pfSense sicher nichts. Für "Bastler und Vielklicker" ist aber schon ziemlich verrückt. Ich musste zumindest weder "basteln", "frickeln", noch sonstwas und bin in zigfachen Jahren BSD und Linux sicher auch kein Vielklicker.

Ich sehe solche Statements eher von Leuten, die sich - so liest es sich zumindest für mich, man mag mich gerne korrigieren - noch nie mit anderen großen/führenden Firewall- oder Netzwerkkomponenten Herstellern auseinander gesetzt haben. Cisco PIX? Cisco ASA? Juniper SRX/SSG? Watchguard? etc. etc.
Wenn ich da sehe, dass bspw. eine Juniper nicht mehr über ihre UI konfigurierbar ist, weil keine Regel mehr gelöscht werden kann (Browser gibt nur Fehler aus), Cisco ASAs zum Teil nur über einen frickeligen Java Client konfigurierbar sind, weil diverse Optionen nicht via CLI erreichbar sind usw. usf. und das sowohl vom Preis als auch der Leistung im Vergleich mit pfSense sehe, kann ich hier wirklich keinen Sinn in deiner Aussage sehen, außer einem Rant.

ach doch...., wenn der Admin "Eh-Da"-Kosten sind.

Wer ein Produkt wie pfSense einsetzt, hat entweder jemand, der sich damit auseinander setzen (sollte), oder einen Partner/Systemhaus/whatever, der ihn an der Stelle betreut. Aber jemand "mal eben" eine Firewall aufbauen lassen, ist genauso schlau, wie dem Buchhalter "mal eben" einen WLAN AP aufsetzen zu lassen. Genau, das sind dann die Dinger, die offen ohne Crypto in irgendwelchen Büros rumstehen über die man dann auf die ganzen Unterlagen zugreifen kann... Alles schon erlebt. Aber wer braucht auch schon Admins, Sys/NetOps ..?

Grüße

tpf

Servus,
ich gebe kurz meinen Senf dazu. Ich betreibe selbst eine PBX hinter pfSense. Dazu habe ich mich an die Standartportvorgaben gehalten: TCP5060 (kann auch UDP sein, maschinenabhängig) und UDP10000-20000 auf die PBX genattet.

Läuft einwandfrei mit Sipgate, keine extra Geschichten notwendig. Bis auf anbieterspezifische andere Ports kann und muss das mit pfSense laufen.

@Docadmin:

Ja, er hat mit Sicherheit was übersehen … die pfSense ist wohl eine der Firewalls, die für Bastler und Vielklicker gemacht ist.

Das würde ich jetzt auch eher mit gemischten Gefühlen betrachten wollen!
Denn wenn das auch sicherlich so für den einen oder anderen erscheinen mag,
ist doch sicherlich eine ganz andere Tendenz zu erkennen und ich finde das auch
gut so. Und nicht vergessen das es sich hier um ein OpenSource Projekt handelt!!!

Es wird Hardware verkauft die eigentlich ein recht großes Spektrum abdeckt
Alix APU basieren für den Heimbereich
Intel C2358 basierend für den ambitionierten Heimbereich bis hin zum SOHO Bereich
Intel C2558 basierend für den KMU Bereich
Intelc C2758 basierend für den KMU Bereich mit erhöhten Anforderungen

pfSense wird von Netgate und deren Geräten unterstützt Lanner ist sehr verbissen daran
zu arbeiten das selbst bei Ihren Appliances, und das auch sicherlich bei den großen Geräten
nicht nur vorher Test gemacht werden, sondern selbst das Bios abgeändert wird, damit pfSense
darauf installiert werden kann z.B. FW-8895 aktuell. Ebenso die breite Unterstützung von Intel
basierenden NICs und nicht mehr von allen Realtek NICs ist ein Indiz dafür das es eben auch
nicht nur auch die 20 e Hardware abzielt sondern sich auch Hardware seitig etwas tut.

pfSense erhält auch zusätzlichen Code der Intel QuickAssist API´s nutzt genauso wie Pakete
wie Snort die davon profitieren, und es wird von der AES-NI Funktioni Gebrauch gemacht die
in vielen Intel CPU´s vorhanden ist um einen höheren Durchsatz zu erzielen!

Sicherlich steht das gerade erst alles in den Startlöchern und braucht seine Zeit, aber ich würde
mich doch sehr freuen wenn damit Geld für die Entwicklung und eventuell einmal eine ICSAS Prüfung
zusammen käme, denn genau dann kann man den Versicherungen auch sagen das die Version XYZ
von ICSAS geprüft wurde und die haften dann auch dafür, und genau das ist der Grund warum sich
in Deutschland und auch ganz Europa zur Zeit noch sehr viele Leute scheuen diese Firewall in ihren
Betrieben einzusetzen, da die rechtliche Variante nicht geklärt ist!!!

Ich denke was pfSense selber einmal gefährlich werden könnte ist mehr OpenBSD mit einer GUI
denn ein CLI bringen die BSD basierenden Systeme schon von Haus aus mit!

Und andere Distributionen sind noch lange nicht dort wo pfSense jetzt steht, allerdings wäre
ein aktualisiertes pfSense Buch und vor allem in englischer und deutscher Sprache nicht schlecht
und puscht das System bestimmt noch mehr, bzw. sorgt auch im deutschsprachigen Raum für eine
höhere Verbreitung Schweiz, Deutschland, Österreich. Genau so wie Kurse an Unis oder gar Zertifikate
ähnlich wie MikroTik, Cisco, Juniper, und Ubiquiti sie schon anbieten wäre mal eine Überlegung wert.

In meinen Augen ein Produkt welches man nicht für den professionellen Einsatz empfehlen sollte … ach doch...., wenn der Admin "Eh-Da"-Kosten sind.

Das hat zum Einen mit der Zertifizierung zu tun und zum Anderen damit das auch pfSense,
obwohl es OpenSource ist gerne sehr potente Hardware haben möchte, also so wie ich das
sehe fühlt sich pfSense erst auf X86_64 Hardware so richtig und bringt dort auch erst im
Zusammenspiel mit Snort, Squid, + SquidGuard, DansGuardian, ClamAV oder Suricata sein
volles Potential zur Geltung und das ist eben auch der einen oder anderen "Heimhardware"
nicht so der "Bringer".

Also so eine Appliance mit kann dann auch schon einmal die 20.000 € erreichen
Dual Xeon E5
Intel Crystal Forest aka QuickAssist Karte
Tilera Gx 72 Core Karte
Exar VPN Karte 17xx, 18xx oder 19xx
PCIe Kompressionskarte

das sind erst einmal Hausnummern mit denen andere zurecht kommen müssen, aber
man kann sich das bei bzw. mit pfSense alles selber zusammenstellen und ist nicht
auf vorkonfigurierte Firewalls oder Router angewiesen!

JeGr

Kurz zu Hardware: Also 20k€ hab ich hier noch lange nicht. Wenn man bspw. nen halbwegs potenten Server nimmt, muss da gar nichts großartiges mehr rein. Wir haben 2 Server mit einen 4-Kern Xeon mit 20GB RAM am Start. Und das auch nur, weil es verflixt nochmal kaum was sinnvolleres gab, kleinere Komponenten hatten kaum Ersparnis, größere würden nichts bringen. Da der Paketfilter - noch - recht single-core lastig läuft, wird nichtmal der 4-Kerner groß beansprucht (von HT mal zu schweigen) und das Paar läuft bei uns als Datacenter Firewall vor etlichen Kundenpräsenzen mit ordentlich Traffic. Und dabei haben wir noch mehr als die Hälfte an Ausgaben gespart im Gegensatz zu dem Angebot, das wir von Cisco oder Juniper hatte inklusive Support-Stunden beim pfSense Team selbst. Kleinere Problemchen hatten wir schon und waren deshalb auch mit dem Team schon in Kontakt - die wurden sehr flott behoben oder gebugfixt. Bspw. die Aliase auf CARP Interfaces, die plötzlich weg waren (Update 2.1.3) -> pfSense Support behoben nach ca. 30min mit einem custom fix, neues Release etc. kam später auch raus. Im Gegensatz dazu sind zwei Cases bei Juniper wegne unserer alten Firewall immer noch offen und die Truppe wäre "am Untersuchen warum das auftreten sollte"…
QuickAssist und Derlei mehr sind Dinge, die brauche ich bei einem großen Xeon noch gar nicht, weil die CPU eh genug Power hat. Selbst bei mehreren VPN Tunneln zu Kunden langweilen sich die Büchsen noch.
Wenn aber bspw. ein C2758 mit QA und AES dann ähnlich viel wuppen kann wie eine mittlere Xeon Kiste, weil Intel mit FreeBSD/pfSense Entwicklern eben Support dafür ins Spiel bringt ist das großartig und drückt nochmals das Preisgefüge erheblich bzw. bringt die Performance nach vorne. Und die Arbeiten an ARM als Plattform sind nun ebenfalls schon angelaufen. IDS, Proxies, AV/Malware Filter etc. lassen sich andere mit extra Appliances bezahlen (oder bieten es gar nicht an). Wer da behauptet, das wäre "Spielzeug Bastelsoftware", hat meiner Ansicht nach was grundlegendes verpasst. Zumal auch im Heim/SOHO Bereich eine ALIX/APU preislich nicht mehr einschlägt, als die neueste Fritzbox oder der Kram, dafür aber wenns um den Hauptaspekt geht - Netzwerk (und keine All in Wonder Box die nichts richtig kann) - alles andere im Regen stehen lässt.

Zu VoIP @tpf:

Das bestärkt eigentlich meine Vermutung, dass es sich meistens um Rand- oder Spezialfälle dreht, in denen Abhängigkeiten bestehen. Sei es, dass die Telekom andere Ports o.ä. nutzt als andere, oder eben bestimmte Anlagen anders konfiguriert sein müssen oder im Extremfall nicht funktionieren (weil 'keiner' damit gerechnet hat, dass da mal nen Gateway davor steht)
Aber gerade VoIP hinter NAT kann da schon ein Problemfall sein, wie es lange bei IPSEC ja auch der Fall war, ich bin da gespannt ob mit der Anlage noch was rauskommt, was ggf. allen weiterhilft wenns ums Thema VoIP geht.

Docadmin

Und nicht vergessen das es sich hier um ein OpenSource Projekt handelt!!!

Genau … und der prof. Support von pfSense sagt Dinge wie:

"No support incident will consume more than one (1) hour of time." ..... scheint irgendwie ne andere Welt zu sein.

Ich habe lieber kein OpenSource sondern einen Hersteller, den ich anrufe der mir genau sagt warum, weshalb und wieso.

alles andere ist Bastelkram und für Enthusiasten ... dies ist wohlgemerkt meine Meinung, die kein anderer teilen muss.

Ich werde froh sein wenn diese Box in die untergehende Sonne reitet.

JeGr

Ich habe lieber kein OpenSource sondern einen Hersteller, den ich anrufe der mir genau sagt warum, weshalb und wieso.

Oh cool, kannst du mir den verraten? Und zwar nicht den, der mir irgendwelchen Nonsense Mist erzählt, sich dann 3x korrigiert, das an die "Fachabteilung" weitergibt und die das dann ein halbes Jahr lang liegen lassen. Gibts nicht? Doch, bei HP, Cisco, Juniper,… Das mag bei so kleinen User-Konfigurations-Fehlern ja toll klappen, aber bei richtigen Bugs sind die "Großen Hersteller" keinen Strich besser als ein pfSense Team, das einen Bug verifiziert, prüft und mir innerhalb von 15min per Patch einen Fix zur Verfügung stellt. Sorry, aber wenn du doch offensichtlich eh keine Lust auf pfSense hast (aus welchen Gründen auch immer), dann verstehe ich nicht, warum du hier versuchst Dinge madig zu reden, die so einfach nicht stimmen.

"No support incident will consume more than one (1) hour of time." ..... scheint irgendwie ne andere Welt zu sein.

Verstehe nicht, wass daran weltfremd ist. Wenn man es aus dem Zusammenhang reißt, liest sich das natürlich dämlich, wird aber klar, wenn man weiß, dass der Satz von der Subscription Seite stammt. Dort kauft man sich eben 2, 5 oder 10 Incidents, die das Team für einen löst. Dass dieser "Incident" auch nicht unendlich lange sein kann, weil das niemand bezahlt, ist mir zumindest irgendwo klar. Wenn ich also ein "Problem" lösen lassen will und möchte dafür, dass das Team sich 10MT hinsetzt und mir ne bunte Lösung bastelt, ist das natürlich NICHT im Incident drin. Irgendwo muss man ja eine Grenze ziehen, ab wann ein Vorfall zahlungstechnisch abgegolten ist, sonst kommt garantiert jemand, der das eben ausnutzt. Und hier ist ein Incident eben 1h Problemlösung. Wohlgemerkt steht da nicht eine Mannstunde. Somit kann das Problem auch eine Stunde lang das ganze Team beschäftigen und wenn es so heikel ist, wird es wohl zumindest nicht nur einen Kunden betreffen und das Team hat eh einen eigenen Grund, das Problem so vollständig wie möglich zu lösen und das Update an alle zu verteilen (bspw. Interface Alias Problem beim 2.1er Update Branch).

Da sehe ich das Problem nicht, warum sowas weltfremd sein soll. Aber wenn man was zu meckern sucht, findet man sicher was.

Genau … und der prof. Support von pfSense sagt Dinge wie:
"No support incident will consume more than one (1) hour of time." ..... scheint irgendwie ne andere Welt zu sein.

Na ja also wenn ein OpenSource Project Support anbietet und das für 199 € im Jahr zusammen mit einer
Appliance von Ihnen und das sind dann ~17 € im Monat und wenn diese Leute sich dann 4 Stunden im
Monat mit jeweils einem Problem von mir beschäftigen sollen, dann waren das mal gerade ~4,50 € pro
Stunde und Mann und das ist nun wirklich ein Spottpreis! Sollten das aber 10 Mann sein die sich eine
Stunde jeden Monat mit einem Problem von mir beschäftigen, kostet das gerade mal 1,70 € pro
Problem also da kann ich sicherlich verstehen wenn das nicht mehr als eine Stunde dauern soll.

Und mit dem Verkauf von mehr Aplliances kommt zwar mehr Geld rein, aber es ist sicherlich nicht für
die Supporter gedacht sondern eher um das gesamte Projekt weiter zu finanzieren.

Ich habe lieber kein OpenSource sondern einen Hersteller, den ich anrufe der mir genau sagt warum, weshalb und wieso.

Also Juniper und Cisco machen das sicherlich, aber da zahlt man auch für eine CRS-3 470.000 €
und für den Support für 5 Jahre 15.000 €, das sind dann eben auch ganz andere Summen.

Zum einen sind es auch Versicherungsverträge und Vorschriften die einem vorschreiben was man
im Betrieb zu benutzen hat und da kann man eh nicht so viel hin und her entscheiden denn den Rest
gibt so oder so das Budget vor.

alles andere ist Bastelkram und für Enthusiasten … dies ist wohlgemerkt meine Meinung, die kein anderer teilen muss.

Ich werde froh sein wenn diese Box in die untergehende Sonne reitet.

Naja also solche Dinge haben ja zum Einen auch immer einen gewissen Wiederverkaufswert
und zum Anderen kann man darauf auch ZeroShell, Untangle, mOnOwall, IPFire, IPCop, ClearOS,
Vyatta, OpenBSD & OpenBGPD, Quagga, OpenWRT oder DD-WRT, fli4l, CentOS, Smoothwall,….
vielleicht hast Du damit ja mehr Glück oder Spaß daran als mit pfsense.

Muss halt jeder selber wissen was er macht und das eine oder andere Mal haben wir alle
schon etwas gekauft und haben dann eher Lehrgeld gezahlt als das es sich ausgezahlt hätte.

hornetx11

Moin,

dies kam gerade per E-Mail:

Sehr geehrter Herr hornetx11,

seit Anfang April haben sich bei uns im Support Kunden gemeldet, die über ihren Festnetzanschluss der Telekom plötzlich nicht mehr 
erreichbar waren. Es handelte sich dabei immer um All-IP-Anschlüsse, an denen es offenbar technische Änderungen gab.

Unsere sofort eingeleitete Untersuchung hat ergeben, dass bei diesen Anschlüssen während des Verbindungsaufbaus die SIP-Informationen 
jetzt in einem veränderten Format als bisher übermittelt werden. Die Telekom ist der erste Provider, der diese Veränderung implementiert 
hat – eine kleine April-Überraschung.

Da Nutzer unserer IP-basierten Anlagen nicht mehr erreichbar waren, mussten wir schnell reagieren. 
Unsere Entwickler haben trotz der Ostertage fieberhaft an einer Lösung gearbeitet, die jetzt als Beta-Version über unsere 
Webseite verfügbar ist:

• Beta-FW für COMpact 3000 (alle Versionen)  
http://auerswald.info/bc/servlet/rl?r=AQAAACYABBy2ArI4EAAR6VMAAAAAAAAAAAAAAAAqRw
• Beta-FW für COMmander Business, COMmander Basic.2 und COMpact 5010/5020 VoIP  
http://auerswald.info/bc/servlet/rl?r=AQAAACYABBy2ArI4EAAR6VQAAAAAAAAAAAAAAABtTA
• Beta-FW für COMmander 6000, COMpact 5000 und COMpact 4000 
http://auerswald.info/bc/servlet/rl?r=AQAAACYABBy2ArI4EAAR6VUAAAAAAAAAAAAAAADsTg

Wir hoffen, dass wir damit schnelle und effiziente Hilfe leisten können.

Ihr Auerswald Team

hornetx11

-flo- 0

Cool, danke für das Weiterleiten! Ich schätze die Details bzgl. der Änderungen wird man kaum rauskriegen, oder?

Hast Du das schon getestet?

-flo-