Messages

76

German - Deutsch / Re: Korrekte VOIP/SIP Konfiguration für 1&1 mit 20.7?

« on: August 31, 2020, 10:40:06 am »

Hallo,
ich denke, das sieht gut aus. Wenn es funktioniert, musst du dir keine Sorgen machen.
Wenn du Probleme damit hast, gib nochmal kurz Bescheid.

Kleiner Tipp: 1&1 SIP ist IPv6 fähig. Wenn du der FRITZ!Box sagst, dass sie IPv6 benutzen soll (VoIP Eigenschaften), dann kannst du dir das ganze NAT und Port-Forwarding sparen. Dann benötigst du nur eine Firewall-Regel, die den Traffic zulässt.

Hier die 1&1 Server für VoIP:

Code: [Select]

sip.1und1.de has IPv6 address 2001:8d8:104:100:212:227:124:129
sip.1und1.de has IPv6 address 2001:8d8:104:100:212:227:124:130

Gruß
Robert.

77

German - Deutsch / Re: (V)LAN verliert IPv6 Konnektivität

« on: August 28, 2020, 11:50:48 am »

Hallo,

ein kleines Update, falls es jemand anderes ein ähnliches Problem hat: Durch die Umstellung des RADVD Mode von "Stateless" auf "Unmanaged" scheint das Problem vorläufig beseitigt zu sein.

Da die nötigen Daten "Router, DNS, Search-Domain" auch per RADVD übermittelt werden, ist ein DHCPv6 nicht erforderlich. Unmanaged scheint mir hier deswegen sowieso die beste Option zu sein.

Gruß
Robert

78

German - Deutsch / Re: (V)LAN verliert IPv6 Konnektivität

« on: August 25, 2020, 12:15:57 pm »

Ich sehe gerade, dass mein Problem evtl. mit diesem hier zusammenhängt bzw. vielleicht sogar das gleiche ist.

https://forum.opnsense.org/index.php?topic=18663.0

Dazu noch die kleine Info, dass ein System von 20.1 aktualisiert wurde, das andere war eine Neuinstallation. Beide verhalten sich jedoch gleich.

Gruß
Robert.

79

German - Deutsch / (V)LAN verliert IPv6 Konnektivität

« on: August 25, 2020, 11:14:54 am »

Hallo Zusammen,

seit dem Upgrade auf 20.7 und nun auf 20.7.1 habe ich bei zwei Installationen das Problem, dass in den (V)LANs die IPv6 Adressen verschwinden. Da sich der Syslog-ng auch nicht starten lässt, habe ich leider keine Logs zur Verfügung. Das Problem soll sich ja mit 20.7.2 lösen?

Hier die Beobachtung:
Nach ein paar Tagen bekommen die Geräte in den (V)LANs keine IPv6 Adressen mehr per Router Advertisement. Durch einen Neustart von radvd ist das Problem jedesmal sofort behoben. Leider ist der radvd vorher und nachher gestartet, d.h. ein Monitoring mit monit ist auch nicht möglich.

Netzwerk-Konfiguration:
Die OPNsense (APU2) ist mit einem Vigor VDSL Modem verbunden. Die PPPoE Verbindung wird durch die OPNsense aufgebaut. Die IPv6 Adressen werden per "Track Interface" zugewiesen und der RADVD Daemon steht bei allen (V)LANs auf "Stateless".

Das Ganze passiert bei unserem Firmennetz und bei einem unserer Kunden, der die gleiche Konfiguration benutzt. Bei den 20.1.9 Instanzen haben wir keine Probleme.

Gerne stelle ich noch mehr Informationen zur Verfügung, wenn ihr mir sagt, was ihr benötigt.

Gruß
Robert.

80

German - Deutsch / Re: LAN Schnittstellen bekommen kein IPv6 nach WAN reconnect

« on: August 21, 2020, 05:37:02 pm »

Hallo,

ich schließe mich Mal an. Ich konnte das Problem neulich auf einer 20.7.1 auch beobachten. Alle (V)LAN Interfaces waren morgens ohne IPv6 Adressen. Durch einen PPPoE reconnect war wieder alles gut.

Da es bisher nur einmal vorkam, habe ich leider noch keine genaueren Infos.

Gruß
Robert

81

General Discussion / Re: How to block TOR

« on: August 21, 2020, 06:39:20 am »

Hi,

you can create an alias (URL table) with a blacklist file. Then you can define Block/reject rules on your interfaces.

I use this list:
http://panwdbl.appspot.com/lists/ettor.txt

Robert

82

German - Deutsch / Re: Firewall Probleme mit VOIP und Datenverkehr zwischen VLANs

« on: August 20, 2020, 08:14:21 am »

Hallo,

versuch bitte mal die Telekom VoIP-Server als 217.0.0.0/13 im Alias zu hinterlegen.

Gruß
Robert

83

German - Deutsch / Re: Verschiedene Gateway und Public IP Adress

« on: August 04, 2020, 09:53:10 pm »

Ich würde auch sagen, dass es sich im CGNAT handelt. Die 100er IP Adressen sind für diesen Zweck gedacht.
Lösung: Versuch doch Mal IPv6 zum laufen zu bekommen. Ansonsten kannst du evtl. mit deinem Provider reden?

Robert

84

German - Deutsch / Re: [Siproxd & VOIP Support] Problem- und Lösungsthread

« on: July 20, 2020, 07:33:24 am »

Hallo Andreas,
ich habe das so verstanden, dass du deiner OPNsense und allen Clients im DNS "vorgaukeln" sollst, dass sip.1und1.de nur eine IP-Adresse hat. Das kannst du bei einer Standardkonfiguration unter Services -> Unbound DNS -> Overrides erledigen.
Dadurch werden deine Clients nicht mehr die korrekte Antwort des Internets erhalten sondern die von dir vorgegebene Antwort.

Insgesamt finde ich das schon etwas unschön als Lösung. Schließlich funktionieren die 1und1 Server ja sonst auch.
Wenn die Portweiterleitung auf einer der 1und1 IP-Adressen nicht funktioniert, könnte es sein, dass vielleicht ein anderes Gerät (App, TK-Anlage, USG o.ä.) sich dort registriert und dadurch die Ports bereits auf ein anderes Gerät umgeleitet sind? Hast du vielleicht die USG noch im Netz, die sich Ports "krallt"?

Etwas weiter vorne hatte ich dir den Vorschlag gemacht, eine FRITZ!Box vor die OPNsense zu hängen und dann die TK darüber laufen zu lassen. Wenn dein Szenario nicht zu groß für eine FRITZ!Box ist, halte ich das durchaus für einen gangbaren Weg. Ja, es gibt zig SIP-Scanner, die versuchen Calls zu initiieren. Jedoch sind 99% alle FRITZ!Boxen in Deutschland direkt online und AVM hat effiziente Maßnahmen ergriffen damit nichts passiert. Insgesamt also nicht die schlechteste Option - auch wenn es mich wirklich interessieren würde, was die Ursache bei dir ist.

Gruß
Robert.

85

German - Deutsch / Re: [Siproxd & VOIP Support] Problem- und Lösungsthread

« on: July 15, 2020, 05:31:27 am »

Moin,
die ganze Sache kommt mir irgendwie komisch vor und so langsam gehen mir die Ideen aus. Irgendwie müssen wir ja voran kommen und die Anzahl der möglichen Fehlerquellen reduzieren.

Ich fasse mal zusammen:
- Die Starface kann kein IPv6, welches die Komplexität nehmen würde und von 1&1 und Sipgate unterstützt wird.
- Die Starface kann keinen STUN-Server, man muss die externe IP selbst eintragen oder per DynDNS ermitteln lassen. Meiner Meinung nach ist ein STUN-Server die "bessere" Wahl, da er dafür gemacht wurde. DynDNS ist immer mit einem gewissen delay verbunden.
- Du willst ein paar 1&1 Nummern und ein paar Sipgate Nummern registrieren - früher ging das, seit OPNsense nicht, korrekt?
- Die SIP-Registrierung funktioniert nicht, daher ist RTP zunächst nicht wichtig. Erst muss die SIP-Registrierung laufen.

Um die Anzahl der Fehlerquellen zu reduzieren würde ich mal schauen, dass man einzelne Komponenten "aus dem Spiel" nimmt.

Mein erster Vorschlag zur Problemlösung wäre, eine (ggf. ältere) FRITZ!Box zu nehmen und diese als IP-Client zu konfigurieren. (Die Box wird Teil deines (V)LANs und deaktiviert DSL-Modem und Routing-Funktion) Die FRITZ!Box soll dann zunächst die IP-Adresse der TK-Anlage bekommen und die Nummern registrieren. Wenn das funktioniert, wissen wir, dass es an der TK-Anlage liegt (oder an der Konfiguration). Wenn es dort auch nicht geht, würde ich bei der OPNsense nochmal schauen.

Mein zweiter Vorschlag wäre, die Situation nochmals umzudrehen: Mit einer FRITZ!Box würde ich die DSL-Verbindung aufbauen und die TK-Anlage die Nummern registrieren lassen (aktuelle Konfiguration). Anschließend kann man beurteilen, ob die TK-Anlage die gleichen Probleme verursacht oder ob alles läuft.

Das Ganze setzt natürlich voraus, dass du eine FRITZ!Box zum Testen hast. Wir verwenden in der Firma häufig die FRITZ!Boxen als TK-Anlage hinter OPNsense (früher pfSense) und haben im Prinzip keine Probleme.

Noch ein Vorschlag: Telefonie und LAN zu trennen ist natürlich immer eine gute Idee, daher könnte man auch ein Setup wie folgt umsetzen. Auch dieses Setup fahren wir bei einigen Kunden:

Code: [Select]

WAN / Internet
            :
            : DSL/Kabel/o.ä.
            :
      .-----+-------.   Telefonie       .------------.
      |  FRITZ!Box  +-------------------+ TK-Anlage  |
      '-----+-------'   192.168.178.0   '------------'
            |
        WAN | IPv4 + IPv6 PD
            |
      .-----+------.
      |  OPNsense  +
      '-----+------'
            |
        LAN | IPv4 + IPv6
            |
      .-----+------.
      | LAN-Switch |
      '-----+------'
            |
    ...-----+------... (LAN und ggf. verschiedene VLANs)

Gruß
Robert

86

German - Deutsch / Re: [Siproxd & VOIP Support] Problem- und Lösungsthread

« on: July 14, 2020, 07:01:57 am »

Hallo Andreas,

es freut mich zu hören. Schade, dass wir jetzt nicht wissen, was der entscheidende Schalter war. :-)
Aliase sind toll, sie machen das Leben so viel leichter. Habe gerade gestern eine Fritzbox (nur TK Anlage hinter der OPNsense) aus dem Haupt-LAN in ein separates LAN gelegt. Ich musste nur den Alias ändern und alles andere hat sich automatisch angepasst.

Gruß
Robert

87

German - Deutsch / Re: [Siproxd & VOIP Support] Problem- und Lösungsthread

« on: July 13, 2020, 06:44:45 am »

Hi,
kleiner Schuss ins Blaue: Verwende doch mal anstatt eines Subnetzes /30 einen Firewall-Alias, der die beiden IP-Adressen enthält. Bei den Regeln wählst du dann einfach den Alias aus.

Bei IPv4 ist ja jedes Subnetz prinzipiell mit einer Netzadresse und einer Broadcast-Adresse versehen. (/24 = x.x.x.0 bis x.x.x.255 wobei 0 das Netz ist und 255 die Broadcast-Adresse). Je kleiner die Bereiche werden, desto mehr Adressen werden ja bekanntlich verschwendet.

Robert.

88

German - Deutsch / Re: [Siproxd & VOIP Support] Problem- und Lösungsthread

« on: July 12, 2020, 07:39:39 am »

Hallo Andreas,
um die externe IP-Adresse zu ermitteln benutzt man eigentlich einen STUN-Server. Ich sehe auf deinem Screenshot leider keine Option dafür, aber schau doch nochmal bei deiner SIP-Config nach.

https://de.m.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT

Zum RTP: Eine Portweiterleitung sollte nicht unbedingt nötig sein, jedoch würde ich unbedingt nochmal Google nutzen oder in der Anleitung wühlen.
Der Portbereich muss ja irgendwo dokumentiert sein. Bei Fritz Boxen ist es z.B. 7078:7109 und bei  Auerswald hatte ich mal 49152:49407 recherchiert.

Wichtig ist auch hier wieder Outbound-NAT mit Static-Port. Wenn du den Portbereich eingrenzen könntest, wäre das hilfreich.

Gruß
Robert.

PS. Wenn du ein paar Paketmitschnitte von Telefonaten aufzeichnest, kannst du die ausgehandelten RTP Ports mit Wireshark in den SIP-Paketen nachlesen.

89

German - Deutsch / Re: [Siproxd & VOIP Support] Problem- und Lösungsthread

« on: July 10, 2020, 07:05:38 am »

Hallo Andreas,

versuch doch bitte mal folgende Punkte:

- Stell mal bei der Outbound-NAT Regel die Option "Source port" von Any (*) auf SIP (5060) um.
- Funktioniert der Verbindungsaufbau, wenn du die anderen SIP-Registrierungen (Sipgate etc.) deaktivierst?

Gruß
Robert.

90

German - Deutsch / Re: [Siproxd & VOIP Support] Problem- und Lösungsthread

« on: July 09, 2020, 08:23:12 am »

Hallo Andreas,

kurz zur Erklärung, vielleicht hilft es dir weiter: VoIP funktioniert mit zwei Protokollen. Die "Steuerung" der Session erfolgt mit dem SIP-Protokoll, meistens Port 5060/udp. Damit werden Anrufe signalisiert, beendet usw. Die Sprachdaten gehen dann über RTP. Welche Ports für die RTP-Verbindung genutzt werden hängt von der TK-Anlage ab. Auch diese Ports werden über SIP ausgehandelt.

Bei dir scheint das Problem ja schon bei der Registrierung zu liegen. Ich vermute, dass bei deine SIP-Anfrage der Absender-Port 5060 durch das NAT umgeschrieben wird. D.h. es wird nicht nur die private IP-Adresse durch die öffentliche IP-Adresse ausgetauscht, es wird auch der Absender-Port geändert. Dadurch schlägt die Registrierung vmtl. fehl. Ich denke du müsstest die Outbound-NAT Konfiguration anpassen, damit der Absender-Port nicht umgeschrieben wird. Das Stichwort lautet "STATIC PORT".

Kurzfassung:
- Zuerst muss der Mode auf Hybrid outbound NAT rule generation gestellt werden.
- Unter Firewall → NAT → Outbound legt man eine neue Regel an:
Interface: WAN
Protocol: UDP
Source address: <IP-Adresse der TK-Anlage>
Source port: *
Static-port: aktiviert (WICHTIG)
Description: VoIP

Die Ausführliche Anleitung findest du hier: https://forum.opnsense.org/index.php?topic=4712.0

Ich hoffe, du kommst damit weiter.

Gruß
Robert.

ps. Es lohnt sich IPv6 zu aktivieren und sich damit zu beschäftigen. Das Leben wird damit leichter! (Kein NAT, kein Port-Forwarding - keine "dreckigen" Lösungen mehr...)