[Solved] Yet another VoIP Thread.

[inDane]

Nabend!

Ich bin am Ende meines Lateins angekommen und hoffe, dass irgendwer von euch mir einen Impuls geben kann, warum der shit nicht funktioniert.
Kurzer Kontext: Mein VoIP funktioniert nicht. Das ging aber, als ich meine pfSense, anstelle der OPNsense, als Router hatte. Ich dachte mir aber, ich wechsel zu OPNsense.Die Config habe ich (meines Wissens nach) 1 zu 1 von der pfSense übertragen. WAN klappt alles, Internet ist da. Für VoIP benutze ich primär eine GO-Box 100, das ist eine DECT Station von Gigaset. Die kann sich anmelden, SIP Registrierung geht. Ich kann Anrufe starten und empfangen, aber es kommt ums verrecken kein Ton...

Hier der Aufbau:

      WAN / Internet
            :
            :
            :
      .-----+-----.
      |  Modem  | 
      '-----+-----'
            |
        WAN_1und1 | PPPoE
            |
      .-----+------.   
      |  OPNsense |
      '-----+------'   
            |
        LAN | 192.168.178.1
            |
      .-----+------.
      | LAN-Switch |
      '-----+------'
            |
    ...-----+------ .-----+------.
                        | GO-BOX    | 192.168.178.7
                        '-----+------'


Ich habe Outbound NAT auf static gestellt für die Go-Box. Ich habe hier schon einiges rumprobiert: "manual", "hybrid", das ganze LAN zu WAN static zu NATten etc etc. Es half nichts bisher.

s. Attachment.

Es ist kein Port-Forwarding zu meiner GO-Box aktiv, da dass eigentlich unnötig sein sollte.

Ich hatte auch testweise floating rules drin, die in und out von den 1und1 SIP/RTP Servern erlauben.
Alles ohne Erfolg.


Ich möchte fast sage OPNsense hat hier einen Bug. Oder vielleicht pfSense, weil es dort funktioniert hat?... Keine Ahnung, ich bin am Ende. Ich teste seit drei Tagen. Dieser Post ist quasi die letzte Chance, danach installiere ich wieder pfSense. Auch wenn ich das eigentlich doof finde, weil mir OPNsense sympathischer ist.


Beste Grüße
inDane


Info am Rande: Mit Linphone auf meinem Laptop gingen SIP calls. Allerdings ging das ganze über ipv6 (hab das via Wireshark gesehen). Die GO Box kann kein IPv6.

[robgnu]

Hallo inDane,

ich möchte dir noch zwei Möglichkeiten vorschlagen:

1. Mach doch mal eine Portweiterleitung auf die Go-Box. Die entsprechenden Ports kannst du der Go-Box Oberfläche entnehmen. Wir nutzen bei einigen Kunden ebenfalls die GO-Box. Es gibt eigentlich keine Probleme. Ich würde mir die Optionen auf der Go-Box Config aber auch nochmals ansehen. Evtl. ist da etwas schief.

2. Nimm dir ein Wireshark. Mach mit den OPNsense (oder per SSH-Tunnel) ein dump des traffics. Anschließend schaust du es dir mir Wireshark an. Du kannst bei SIP/RTP sehr gut sehen, wie die Kommunikation läuft. Kleiner Tipp: Mach ein Dump auf der WAN-Seite und auf der LAN-Seite. So kannst du ggf. sehen, welche Pakete nicht durchkommen.

Falls du Linux benutzt, ich mache ein Dump wie folgt:

Code: [Select]

ssh root@OPNsense -p22 "tcpdump -i igb1 -U -w - port not 22" | wireshark -i - -k
Dieser Befehl baut eine SSH-Verbindung zur OPNsense auf und leitet den gesamten Traffic von igb1 direkt an das Wireshark. Ausgenommen ist die SSH-Verbindung selbst.

Gruß
Robert

[inDane]

Hallo Robert,
danke Dir für deine Ideen!

zu 1.
Ich habe Port Forwards gebaut für die SIP und RTP ports. (s. Attachment)
Auf der GO-Box sind folgende Ports eingetragen. 5060 und 7078:7082. (s. Attachment)

Hat nichts verändert. Ich habe die portforwards jetzt aber vorerst drin gelassen.



zu 2.
Was auffällt ist, dass die RTP Pakete nur nach außen gehen, aber keins rein kommt.
Im wireshark habe ich folgenden filter benutzt"sip || rtp || stun".
Ich habe in den folgenden Bildern meine Telefonnummer und meine public IP entfernt.


https://i.imgur.com/K87niJN.png

https://i.imgur.com/I58L6Wn.png


Die RTP Pakete haben SRC Port 7078 und Dest Port 40286.

Hast Du eine Idee dazu?

VG
inDane

[Saarbremer]

Hi,

als ehemaliger VoIP Debugger kann ich nur dazu raten wie vorgeschlagen den WAN traffic mitzuschneiden und anzuschauen, welche Pakete da via RTP zurückkommen. Hatte mal an einem Trunk Anschluss die merkwürdigsten Probleme bis hin zu falsch dokumentierten UDP ports (und ja, das war eine pfSense - ist aber schon ein paar Jahre her).

Die konnte man leicht sehen, weil die Pakete im Dump auftauchten aber dann in der Wirewall versandeten.

P.S.: Nach Anlegen des Port Forwardings hast du die Firewall Regeln neu geladen UND die States zurückgesetzt? Wenn nein, bitte erst durchführen, sonst nutzen die schönsten Regeln nicht viel.

[inDane]

Hi Saarbremer,
ich habe sogar noch einen drauf gesetzt und hab die Karre komplett rebootet!

Via ipv4 kommen gar keine zurück, wie es ausschaut. In meinem vorherigen Post ist auf der rechten seite jeweils das WAN interface pcap.


Via ipv6 (vom Laptop mit Linphone) klappt alles wie man es erwarten würde. Via Ipv4 kommt kein RTP zurück.

VG
inDane

[robgnu]

Hallo inDane,

schau doch mal, ob du die Ports von der Go-Box auf zufällig stellst. Die NAT Regel dann so konfigurieren, dass alle Pakete von der IP-Adresse der Go-Box auf "STATIC Port" gesetzt sind. Zum Debuggen bitte auch mal alle Ports an die Go-Box weiterleiten. Das muss später aber unbedingt raus.

Und noch etwas: Bitte benutze kein STUN. Bitte STUN in der GO-Box mal komplett abschalten.

Gruß
Robert

[inDane]

Hi Robert,

habe ich gemacht. Stun ist aus und die Einstellung in der Go-Box "Zufällige Ports benutzen" ist gesetzt 5060-5076 (das sind die default werte).

Ich habe das Modem als auch die opnsense neugestartet. Ohne Erfolg.
Was mich wirklich skeptisch macht, ist, dass am OPNsense WAN interface überhaupt keine ipv4 RTP-Pakete zurück kommen. Also ausgehend sendet er die ganze Zeit, wenn ich einen Anruf gestartet habe, aber es kommt gar nichts zurück. Die SIP Aushandlung funktioniert einwandfrei und bei RTP ist dann einfach Ende.
Selbst wenn NAT an dieser Stelle kaputt wäre, müsste doch irgendwas am WAN interface ankommen oder? In dem Paket was raus geht, steht ja meine public ipv4 als source drin...

EDIT: Das steht im SIP Header... Versucht die Gegenstelle möglicherweise an 192.168.178.7 zurück zu schicken?

Via: SIP/2.0/UDP 192.168.178.7:5069;received=<meineWAN_IP>;branch=<xyz>;rport=5069
    Transport: UDP
    Sent-by Address: 192.168.178.7
    Sent-by port: 5069
    Received: <meineWAN_IP>
    Branch: <xyz>
    RPort: 5069

EDIT2:
mhh IETF RFC 3581 schreibt:

   When a server attempts to send a response, it examines the topmost
   Via header field value of that response.  If the "sent-protocol"
   component indicates an unreliable unicast transport protocol, such as
   UDP, and there is no "maddr" parameter, but there is both a
   "received" parameter and an "rport" parameter, the response MUST be
   sent to the IP address listed in the "received" parameter, and the
   port in the "rport" parameter. The response MUST be sent from the
   same address and port that the corresponding request was received on.
   This effectively adds a new processing step between bullets two and
   three in Section 18.2.2 of SIP [1].




Vielen Dank für die Unterstützung.
inDane

[robgnu]

Hallo inDane,

es stimmt, natürlich werden Pakete an 192.168.178.xxx verworfen. Hierfür ist eigentlich STUN da, damit die GO-Box die eigene öffentliche IP-Adresse herausbekommen kann und diese ins Paket schreibt.
Welcher STUN-Server ist denn in der GO-Box eingestellt? Bei 1und1 sollte es wohl stun.1und1.de sein?

Nur noch eine Rückfrage: Aufgrund von 192.168.178.xxx vermute ich eine FRITZ!Box? Was hast du denn da für ein Modem?

Gruß
Robert

[inDane]

Hi Robert,

Welcher STUN-Server ist denn in der GO-Box eingestellt? Bei 1und1 sollte es wohl stun.1und1.de sein?

Korrekt.

Folgende Beobachtungen im WAN.pcapng:
- Mit STUN, Anruf zu 0311: RTP hin und zurück zwischen WAN_IP und 1und1 in Ordnung, ich höre etwas.
- Ohne STUN, Anruf zu 0311: source ip ist die local ip der GO-Box... Ich höre nichts.
- Mit STUN, Anruf zu meiner Handynummer: RTP lediglich von meiner WAN_IP zu 1und1. Ich höre nichts.
- Ohne STUN, Anruf zu meiner Handynummer: RTP lediglich von meiner WAN_IP zu 1und1. Ich höre nichts.

Das bezieht sich alles auf die GO-Box ipv4 +NAT.
Linphone via IPv6 funktioniert einwandfrei ohne STUN.

Aufgrund von 192.168.178.xxx vermute ich eine FRITZ!Box? Was hast du denn da für ein Modem?

Jain, ich hatte eine FB und aufgrund von statischer IP vergabe das Netz so beibehalten. Eine FB befindet sich derzeit bei mir nicht im LAN. Die Komponenten sind Draytek Vigor 167, OPNsense, GO-Box 100.

Beste Grüße
inDane

[Saarbremer]

<exkurs>Noch ein Grund mehr, IPv4 scheiße zu finden. Und alle Provider, die nur das können, unbedingt meiden.</exkurs>

Bei deinen Beobachtungen hast du auch die SIP Pakete mitgeschnitten und die IP+Portnummern jeweils mitnotiert? Damit könnte man dann sehen, ob da was falsches annonciert wird.

Ohne STUN wird das ganze nicht funktionieren, da deine Box ihre eigene public IPv4 nicht kennt.

Wenn nichts an WAN ankommt, dann ist die Verbindung falsch aufgesetzt. Kommt was an, aber wird nicht durchgelassen, liegt's an deinem NAT Router.

[inDane]

OK, klarer Anwender Fehler... ?

Ich hatte Floating Rules drin die sagten:
Von VoIP_1und1 zu LAN erlauben v4 + v6
Von LAN zu VoIP_1und1 erlauben v4 + v6

VoIP_1und1 ist ein Alias mit allen RTP SIP Stun-Servern von 1und1.

Diese Floating rules hatte ich bei der pfSense ebenfalls drin und ich meine auch, dass die notwendig waren... anyways... ich habe die entfernt und siehe da.. VoIP via GO-Box/ipv4 Funktioniert. Das ist mir peinlich.

Ich könnte mir vorstellen, dass die Floating Rules die NAT rules übertrumpft haben und deswegen die NAT Outbound rules kaputt gegangen sind...

Die Rules die ich in der pfSense hatte, habe ich mal als Attachment angehängt. OPNsense scheint das nicht zu mögen... Ich mache aber gleich noch den Gegentest und versuche VoIP mit der Regel wieder kaputt zu machen.

EDIT: Jop, das ist der Fehler. Baue ich die Floating rules wieder ein, klappt VoIP (IPv4) nicht mehr. Ist das as expected oder ist das ein Bug?

Beste Grüße
inDane

[robgnu]

Hallo inDane,

schön, dass du es lösen konntest. Es wäre schade, deswegen wieder zur pfSense zu wechseln.
Ich nutze die Floating Rules nur, wenn ich mehreren LAN Interfaces die gleichen Regeln zuweisen möchte, sonst halte ich die Regeln lieber beim entsprechenden Interface.

Gruß
Robert

[Saarbremer]

EDIT: Jop, das ist der Fehler. Baue ich die Floating rules wieder ein, klappt VoIP (IPv4) nicht mehr. Ist das as expected oder ist das ein Bug?

Ohne die OPNSense Regeln gesehen zu haben wird das schwierig zu beantworten.

Floating Rules sind aber generell eher unübersichtlich. Alternativ könnte man auch Schnittstellengruppen definieren. Damit habe ich hier zuhause so eine Art Zonensystem erstellen können.