Messages

Ich ergänze:
# dig _sip._udp.tel.t-online.de SRV

;; ANSWER SECTION:
_sip._udp.tel.t-online.de. 3600 IN      SRV     10 0 5060 stg010-l01-mav-pc-rt-001.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 3600 IN      SRV     20 0 5060 hno002-l01-mav-pc-rt-001.edns.t-ipnet.de.
_sip._udp.tel.t-online.de. 3600 IN      SRV     30 0 5060 nes008-f01-mav-pc-rt-001.edns.t-ipnet.de.


# dig hno002-l01-mav-pc-rt-001.edns.t-ipnet.de

;; ANSWER SECTION:
hno002-l01-mav-pc-rt-001.edns.t-ipnet.de. 3600 IN A 217.0.147.197

Beide Anfragen habe ich nicht an den Telekom DNS gerichtet sondern an meinen eigenen. Die GoBox arbeitet mit dem Telekom-DNS.

Im tcpdump sieht es so aus, als ob die GoBox SIP Requests an die Firewall schickt, die diese dann NATtet und raushaut an den 2. Server aus der obigen Antwortliste - die IP 217.0.147.197. Scheinbar kommt aber nie eine Antwort zurück.

Die Dumps habe ich mir über 2 SSH Terminals parallel direkt auf der Sense geholt (einmal vom pppoe interface und einmal vom vlan Interface an dem die GoBox hängt).

Ja da dachte ich, ich könnte einfach in einem Thread die Lösung meines Problems abgreifen oder wenigstens "same" reinschreiben - und dann wars leider doch nicht same, weil ich eben kein IDS/IPS installiert habe.

Habe gestern das Update auf 24.1.3_1 gemacht und nu geht meine IP Telefonie nicht mehr.

Anbieter: Telekom, FTTH
Tarif: Magenta Zuhause

Telefonie über Gigaset Go Box 100 in eigenem VLAN.
Konfiguration in der sense und in der goBox habe ich mal angehängt.

Was ich versucht habe:
Neustart der goBox (früher hatte ich mal Probleme, wenn sie länger lief, dass sie plötzlich aufgehört hat SIP Requests zu schicken)
Umstellen STUN ja/nein
Umstellen Protokoll Auto/TCP/UDP
Zuweisung eines Telekom DNS für die GoBox statt des von mir selber eingesetzten DNS
Aktualisierung des PBX Profils in der GoBox

Was ich noch nicht versucht habe:
Hab schon wieder vergessen, wie ich geschickt den Traffic zwischen der GoBox und dem Telekomserver mitschneide. Denke, der Dump könnte zumindest mal sagen, wo es hakt.

Was mich wundert ist, dass ich nix verändert habe und es einfach nach dem Update aufgehört hat zu laufen.
Übersehe ich was offensichtliches?

Danke, den Wink mit dem Zaunpfahl hab ich verstanden.

Grundsätzlich habe ich schon eine Firma, die mich darin kompetent - und inzwischen auch kostenpflichtig, weil die sense haben wir schon ne Weile im Betrieb - beraten kann. Bevor ich sowas mache, frag ich aber trotzdem nochmal so nach, weil es ja auch was offensichtliches sein kann für das ich gerade betriebsblind bin und dann würde ich mich ärgern, dafür ne Leistung eingekauft zu haben.

Ich hab mir inzwischen mal die Mühe gemacht - weil es mich sowieso gereizt hat - das als Anlass zu nehmen, einen parallelen Server mit einer Sense aufzuziehen. Nun - nach einigem Gebastel (aktuelle Version geht nicht, weil da wohl ein Problem mit der Hardwareerkennung im Kernel existiert) - hatte ich den am Laufen. VPN eingerichtet. Verbindung klappt - gleiches Problem. Es liegt also nicht zwangsläufig an den unterschiedlichen FWs.

Allerdings hab ich danach tatsächlich einen "Tomaten auf den Augen" Fehler gesehen, nachdem ich mich nochmal hingesetzt hab und der Sache per Packet Capture auf den Grund gehen wollte. Ich wunderte mich, warum die Anfragen über das falsche WAN Interface gehen - da konnten sie nicht beantwortet werden - und fand heraus, dass ich eine Regel brauche, die den VPN Verkehr durch das richtige Gateway schickt, denn der normale Internet-Traffic wird bei uns durch ein festgelegtes Gateway geschoben.

Kaum war die Regel da, klappte es wieder. Und dann auch wieder nicht. Ich hab jetzt aber ein anderes Verhalten, mit dem ich mich selber weiter beschäftigen kann. Nur soviel: CIFS Verbindungen zum Zielserver funktionieren immer erst, wenn man es 2x mit unterschiedlichen Protokoll-Versionen versucht. Die erste Anfrage scheitert immer - die zweite klappt.

Ich betrachte das Thema als gelöst. Danke an alle die mich gelesen haben!

Bin mir nicht ganz sicher, ob ich richtig verstanden hab,was du vor hast. Es klingt für mich aber so, als ob du ein HA-Proxy möchtest.

Das ist ein Modus, der ermöglicht, dass mehrere Geräte als Gruppe agieren und wenn eins ausfällt, bleibt das Netzwerk weiterhin unverändert funktionsfähig.
Link zur Doku: https://docs.opnsense.org/manual/hacarp.html

[Port]

@Inkasso:

Port	pfSense	OPNsense
1	WAN	LAN
2	LAN	WAN

Asche auf mein Haupt ;D
Dabei hab ich die PFSense noch nicht mal zum Testen im Einsatz gehabt obwohl mir viele von der opn abgeraten haben. Habe meine Entscheidung bis heute nicht bereut. Und ich hatte mir den Anfang erheblich schwerer vorgestellt, als es eigentlich war - auch wenn ich mich am Anfang gefühlt alle 20 Minuten ausgesperrt hatte und dann ein Rollback der Konfiguration auf einen funtkionierenden Stand gemacht hab :D

PS: Ich persönlich mag das WAN immer auf dem/den höchsten Port(s) haben. Von daher war bei meiner 4-Port-Hardware sowohl 1 als auch 2 für die von mir bevorzugte Lösung falsch.

[Warnung: Folgende Info auf eigenes Risiko!]

Was mich jetzt allerdings wundert, ist, dass die "anti-lockout rule" ja für die Internetzone generiert worden ist. Theoretisch sollte die in dem von mir beschriebenen Zugriff: internet->green-zone eigentlich gar nicht greifen.... wenn schon, dann nur ausgehend, oder ?

Folgendes aus meiner persönlichen Erfahrung mit der Sense:
Das Standard-IF für WAN ist der erste Port - zumindest wenn man den Wizzard benutzt - also scheint sich die automatische anti-Lockout-Rule daran zu orientieren, selbst wenn man das WAN IF eben (später) auf einen anderen Port gelegt hat. Das hat mich auch schon angekotzt, weil man das Verhalten wohl (nachträglich) nicht ändern kann.

Warnung: Folgende Info auf eigenes Risiko!
Du kannst die automatische Anti Lockout Rule deaktivieren, um zu testen, ob sich das gewünschte Verhalten dadurch einstellt. Den Punkt findest du unter Firewall -> Settings -> Advanced -> Disable anti-lockout.

Falls du dich dadurch selbst aus der Firewall aussperrst: ich bins nicht gewesen - du wurdest gewarnt!

[VPN Konfiguartion auf Sense Seite]

So langsam verzweifle ich, weil ich das Problem auch irgendwie nicht (be-)greifen kann...

Ich habe eine Reihe von privaten Netzen auf der opnSense. Zweien davon soll der Zugriff auf ein Drittes möglich sein, dass über einen openVPN client, der auf der Sense läuft, angebunden wird.

Lokale Netze u.A.
10.10.0.0/16
10.20.0.0/16

entferntes Netz
192.168.40.0/24

VPN Konfiguartion auf Sense Seite
Peer to Peer
UDP
tun
WAN Interface

Peer: ***.***.***.*** : 1194

Benutzername + Passwort (sind korrekt)

TLS Auth: disabled
TLS Shared Key: autmatically generate a shared TLS authentication key
Peer CA: (hab das Fremd-CA-Zertifikat in die Sense importiert und ausgewählt)
Client Cert: (hab dem Client auf der Fremd CA eins ausgestellt und in die Sense importiert und ausgewählt)
Encryption: AES-128-CBC (128,128) (wird von der Gegenseite so vorgegeben)
Auth Digest: SHA1

Tunnel v4 Network: 192.169.99.0/24
Remote v4 Network: 192.168.40.0/24

Compression: no Preference
(alle nicht angegebenen Parameter sind leer oder aus)

automatische Routen (die, bei denen ich Relevanz vermute)
Proto  Destination   Gateway Flags Use MTU Netif Netif (name) Expire
ipv4   192.168.40.0/24   192.168.99.49   UGS   NaN   1500   ovpnc2           
ipv4   192.168.99.0/24   192.168.99.49   UGS   NaN   1500   ovpnc2           
ipv4   192.168.99.49   link#30   UH   NaN   1500   ovpnc2           
ipv4   192.168.99.50   link#30   UHS   NaN   16384   lo0   Loopback       

Das Problem

Die VPN Verbindung wird erfolgreich aufgebaut. Von der Sense aus kann man problemlos den einzigen Computer im Zielnetz hinter der Firewall pingen, sofern man bei Source Address "Default" stehen lässt. Stellt man auf eins der Netzwerke, die die VPN Verbindung nutzen können sollen, kommt nichts an Rückmeldung.

Was noch verrückter ist: Manchmal funktioniert es so wie es soll und manchmal nicht. Ich habe aber noch nicht rausbekommen, ob/was sich da ändert, denn an der Konfiguration wird normal gar nichts gemacht. Und wenn es läuft, läuft es gewöhnlich über Wochen gut, bis mal wieder ein Moment kommt, ab dem es dann nicht mehr geht.

Erschwerend hinzu kommt, dass ich das ganze VPN Thema in Verbindung mit Firewalls irgendwie nicht ganz in meinen Kopf bekomme und mir dann bei einidgen Dingen nicht sicher bin. Es fühlt sich für mich so an, als ob die Verbindung "an der Firewall vorbei" geht. Von meiner Erwartung hätte ich eine VPN Verbindung wie eine WAN Verbindung behandelt und genau wie bei WAN Verbindungen Firewall-Regeln erstellt.

Die Gegenseite befindet sich in einem Rechenzentrum mit selbst konfigurierbaren virtuellen Maschinen. Sie wird fremd betreut und Voraussetzung für die Betreuung ist, dass man eben deren bevorzugte Firewall einsetzt. Deswegen läuft auf der Gegenseite auch keine Sense sondern eine Untangle. Ist furchtbar umständlich und langsam finde ich.

Bevor ich mich aus dem Fenster lehne und parallel einen weiteren virtuellen Server aufzuziehen versuche, auf dem dann eine Sense läuft, möchte ich ein letztes Mal versuchen, dieses Problem in den Griff zu bekommen, ohne die FW auf der Gegenseite zu tauschen. Auch, weil ich keine Ahnung habe, ob die Sense überhaupt auf diesen virtuellen Servern laufen wird.

Hab ich irgendwas vergessen?
Jemand eine Idee, was ich probieren kann?

Soo... Das ganze Wochenende über gab es nicht einmal unregistrierte Telefone oder Probleme beim Telefonieren. Es scheint nun alles zu passen.

STUN ist aus.
Magenta Profil statt dem generischen Telekom-Profil.
PortForward ist geblieben wie beschrieben. Habe die Quelle auf 217.0.0.0/16 eingeschränkt.
Habe die GoBox in ein eigenes VLAN gesteckt, aber das sollte egal sein.

Wenn es wieder Probleme geben sollte, schau ich zuerst, ob es ggf. an der "zu engen" Beschränkung auf die Quelle liegen kann.

Danke an alle Helfer!

Gruß

Manuel

So... Erste Nacht ohne dass mich die Telefone mit "ich bin nicht angemeldet" begrüßen :D

Gestern Abend hab ich Telefonie Tests gemacht. Heute früh auch. Scheint alles stabil zu laufen. Ich warte jetzt mal noch 1-2 Tage, ob es so bleibt. Wenn ja, mach ich einen Haken ans Thema.

Danke an alle Mithelfer schonmal!

Gruß

Manuel

Na ich will das ja auch gar nicht in Abrede stellen, dass es bei dir läuft, oder dass du dir was dabei gedacht hast.
Ich will nur verstehen, was ich da tue und warum ich es tue. Sonst hätte ich auch einfach bei ner FritzBox bleiben können ;)

Die Umstellung der Profile + das Abschalten von STUN scheinen bisher aber schon mal was gebracht zu haben. Bisher meine Meldung über nicht angemeldete Rufnummern. Außerdem kam ein Telefonat erfolgreich rein und konnte ganz normal geführt werden. Bin gespannt, wie es heute Abend und morgen früh ausschaut.

Auf sowas soll man kommen :o

Wenn da Provider: Telekom steht, dann geh ich doch nicht erst aufs Dropdown, weil der Provider stimmt. Und wenn es unterschiedliche Configs je Tarif gibt, hätte ich erwartet, dass die danach im nächsten Screen abgefragt werden - halt runtergefiltert auf den gewählten Provider...

Gut. Hab Mangenta entdeckt und nun verwendet. Ist ja auch bei mir ein Magenta Zuhause.
Dabei hab ich jetzt gleich mal das STUN abgeschaltet. Mal sehen was passiert.

Wegen der FW Regel(n):
Wenn ich meine Regel richtig verstehe, hänge ich die Ports von der GoBox direkt ins Internet. Das bedeutet doch PortForwarding?

Und aus dem Handbuch zur Sense bei "NAT Outbound":

If you only have one external IP, then you leave the Outbound NAT options on automatic. However, if you have multiple IP addresses, you might want to change the settings and add some custom rules.

Also: Outbound NAT brauchts nur bei multi WAN. Da hätte es mir auch eingeleuchtet.

Auf der Go Box:
stun benutzen ja, stun refreshzeit 240, NAT refreshzeit 20, DNS SRV lookup ja, wurde letztes Jahr umgestellt bei Telekom.

domain tel.t-online.de, gleiches für proxy Serveradresse und Registration server und outbound Serveradresse
Outbound proxy modus nie

Das hat bei mir der Einrichtungsassistent selbst alles schon so eingerichtet gehabt. Nur DNS SRV lookup hab ich manuell aktiviert - und ja das hatte ich schon gemacht bevor ich hier gepostet habe, weil ich einen Link zu einer Telekom Seite hier im Forum gesehen habe, wo erklärt wurde, was eingestellt werden sollte.

Ich verwende d_magenta_de.bin als Profilversion

Ich weiß nicht wie du das "verwendest". Bei meiner GoBox steht das nur als Profil da - wahrscheinlich das, was die Box selbst identifiziert hat und dann von Gigaset runtergeladen hat. Ich habe allerdings ein anderes Profil da stehen: d_telekom_de.bin

dann bei weitere VOIP Einstellungen: SIP Update ja, Zieladresse ableiten: aus SIP contact Header

die RTP Ports müssen sowohl eingehend als auch ausgehend denen entsprechen, die in den FW/NAT Regeln angegeben sind.

Br br

Die Einstellungen habe ich ebenfalls gleich. Wobei ich mir nicht ganz sicher bin ist, ob die NAT Regel stimmt.
Firewall => NAT => PortFoward

Interface: WAN
TCP/IP: IPv4  (IPv6 hab ich überall disabled und die Firewall dropt es auch)
Protocol: TCP/UDP
Source: any
Source Port range: any
Dest: any
Dest Port range: (Alias VoIP Ports bei from und to)
Redirect Target IP: (Alias für GoBox IP)
Redirect Target Port: (Alias VoIP Ports)

Im Alias für die VoIP Ports sind alle Ports, die auf der GoBox für SIP und RTP gelistet sind.
Also SIP 5060-5076 und RTP 5004-5020

Was mir beim Mitschnitt von heute Nacht auffällt: Ich habe ungefähr um 20 Uhr gestartet und alles läuft zunächst wie ein Uhrwerk. Ab 23:40 Uhr hatte ich dann eigentlich nur noch STUN Requests mit Antwort aber die GoBox hat keine SIPs mehr geschickt.

Um etwa 2 Uhr nachts hat die GoBox dann nach Profil-Updates bei Gigaset gesucht. Hat aber anschließend weiterhin nur STUNs geschickt und keine SIPs.

Erst als ich heute früh die Box über ein Telefon hab neu starten lassen, kam dann wieder reichlich Bewegung in die Aufzeichnung und neben Anfragen an dynreg.gigaset.net gab es dann auch wieder die normalen SIPs an die Telekom.

Hab doch glatt übersehen, dass vor meiner Antwort noch Antworten gekommen sind mit Dingen, die ich ausprobieren sollte. Keine Angst - mache ich morgen!

Aktuell läuft zumindest mal eine Aufzeichnung über die ganze Nacht, denn morgens sind die Telefone immer unregistriert und evtl. sehe ich dann mal warum.

Habe die GoBox nun in ein eigenes VLAN gesteckt (wollte ich ursprünglich ja eh).
Die Einstellungen sind wieder auf Auto für TCP/UDP.

Ich musste eine NAT Regel bauen, damit ich auf die Oberfläche von der GoBox komme, denn sie redet wohl nur mit Geräten im selben Subnetz (was ich für ein vernünftiges Sicherheitsfeature halte).

Probleme sind immer noch da. Jetzt wo die Kiste aber ihr eigenes VLAN hat, kann ich gezielter und länger das Capture laufen lassen. Evtl kommt man dann mal dahinter wo es hakt. Heute hatte ich z.B. wieder Ton Probleme. Ich kann keine MFV Töne übertragen um bei Ansagen durchs Menü zu steuern.

Zunächst mal: ich nutze aktuell gar keinen DNS vom ISP. Bei mir läuft piHole mit 2 freeDNS Servern. piHole ist einziger DNS (per DHCP verteilt) und piHole schickt lokale Anfragen an die Sense weiter um die lokale Namensauflösung zu ermöglichen.

Natürlich könnte ich mir jetzt aus dem PPPoE Log raussuchen, was für DNS die Telekom gern hätte und die der GoBox per DHCP zuweisen lassen. Bin nur noch nicht so ganz überzeugt, dass es daran liegt.

GoBox Firmware ist tatsächlich 42.259, aber die Gigaset.net Dienste hab ich nicht aktiv - will ich auch gar nicht haben. Mich nervt, dass ich sie nur deaktivieren, aber nicht löschen kann.

Ich hab da allerdings noch eine Reihe von Konfigurationsparametern, die mir nichts sagen, und die ich mal googeln muss:

• DNS SRV Lookup benutzen (aktuell testweise ja - hat aber nix gebracht)
• STUN benutzen (aktuell ja, ich hörte aber auch davon, dass manche den nicht nutzen)
• Outbound Proxymodus immer/auto/nie/DHCP Option 120 "SIP Server" benutzen

Probeweise begrenze ich ihn jetzt mal auf TCP und schau, ob sich dadurch was tut.

UPDATE: Also nur TCP funktioniert auch nicht. Von 5 Rufnummern kann ich nur die ersten 2 anmelden. Die Übrigen funktionieren nicht - trotz identischer Einstellung.