Messages

1

German - Deutsch / Re: MagentaTV läuft ohne Ruckler

« on: March 22, 2022, 08:44:16 pm »

Ja, waren/sind in allen Regeln aktiviert gewesen.
Wie gesagt kam vom MR die Meldung, dass eine veraltete IGMP Version (bzw. ein Gerät im LAN welche nur eine alte Version unterstützt) das Problem ist.
Ich habe das IGMPPROXY Plugin aus dem mimugmail Repo muss hier evtl. noch etwas per CLI eingestellt werden?

2

German - Deutsch / Re: MagentaTV läuft ohne Ruckler

« on: March 22, 2022, 05:59:12 pm »

Habe mich an die Anleitung gehalten, die Regeln waren drin hab auch mal ne „Allow all“ Regel erstellt, ohne Erfolg.
Habe den MR im „LAN“ und auch in einen eigenen Netz getestet (FW-Regeln und IGMPPROXY angepasst)
Der Unterschied von den Anleitungen zu meiner Konstellation ist, das ich kein separates ETH-Interface für MagentaTV habe sondern mit VLAN arbeite.
Auch machte die OPNsense das VLAN-Tagging für den INetZugang, da dies der Speedport als Modem nicht kann.

3

German - Deutsch / Re: 2 VoIP Provider und keinen Plan vom Thema

« on: March 22, 2022, 04:48:27 pm »

In der 510IP gibt es unter:
Netzwerk —> IP-Konfiguration—> „Weitere Einstellungen“
Den Punkt „ Zugriff aus anderen Netzen zulassen“. Damit funktioniert dann auch der Zugriff (bei mir) aus dem „LAN“ auf die 510IP (VOIP NETZ).

@bringha
Ich habe auch „nur“ einen All IP Anschluss und keinen SIP-Trunk und dass läuft ohne STUN.

MfG

4

German - Deutsch / Re: MagentaTV läuft ohne Ruckler

« on: March 22, 2022, 04:41:44 pm »

Nach dem umschalten von Uni- auf Multicast stockt/stottert Bild und Ton bis zum Abbruch des Streams. Der Systemtest des Receivers gibt als Fehlermeldung eine veraltete IGMP Version als Ursache aus.

5

German - Deutsch / Re: Probleme mit VPN-Tunneln

« on: March 22, 2022, 11:56:17 am »

Benutzt "Cisco EZVPN" irgendwelche Proprietären Protokolle?
Kenn das von Lancom, diese können im MainMode (Klassisches IKE) "Dynamisches VPN" dabei übermittelt der Aufbauende Router (je nach Einstellung) seine WAN-IP per ISDN, ICMP- oder UDP-Paket.
Evtl. macht Cisco hier ja etwas ähnliches.

Oder aber der DPD-Timer ist größer wie der Aging-Timer der Firewall

6

German - Deutsch / Re: MagentaTV läuft ohne Ruckler

« on: March 22, 2022, 11:46:21 am »

Hallo @bringha

hast du auch schon ein Update auf die 22.1.3 durchgeführt und funktioniert es da immer noch?

Ich habe es nicht zum laufen gebracht mit der Konfiguration
Telekom MagentaZuhause XL --> Speedport Smart 3 (Modem Modus) --> Opnsense mit igmpproxy --> Lancom GS-2326P+ Switch mit IGMP Snooping --> MR601
Aktuell läuft es so:
Telekom MagentaZuhause XL --> Fritz!Box7530 --> GS-2326P+ Switch mit IGMP Snooping (seperaten VLAN für die 2 Ports) --> MR601
und paralel dazu
Telekom MagentaZuhause XL --> Fritz!Box7530 --> Opnsense --> Lancom GS-2326P+ Switch mit IGMP Snooping --> LAN

7

German - Deutsch / Re: 2 VoIP Provider und keinen Plan vom Thema

« on: March 22, 2022, 11:18:51 am »

Ich habe zwar das Gigaset N510 IP Pro aber die Einstellungen sollten ja die gleichen sein:
DNS SRV Lookup
Lookup benutzen    Ja

Allgemeine Anmeldedaten Ihres VoIP-Providers
Domain:    tel.t-online.de
Proxy-Serveradresse:    tel.t-online.de
Proxy-Serverport:    
Registration-Server:    tel.t-online.de
Registration-Serverport:    
Anmelde-Refreshzeit:    600 Sek.

Allgemeine Netzwerkdaten Ihres VoIP-Providers
STUN benutzen:    Nein (Wird auch nur benötigt wenn mehr wie ein mal "geNATed" wird // siehe erklärung unten)
Outbound-Proxymodus: Nie
Netzwerkprotokoll auswählen: "Automatisch"

Erläuterung zu STUN aus den TEchnischen Unterlagen der Telekom:
STUN
Die VoIP-Plattform der Telekom hat eine eingebaute automatische NAT-Erkennung.

• Hierfür muss die TK-Anlage symmetrisches RTP unterstützen, d.h. bei ein- und ausgehenden Gesprächen muss die TK-Anlage den RTP-Strom selbst als erstes aufbauen. Nach drei eingegangen RTP-Paketen erkennt die Plattform den Datenstrom und baut ihrerseits zur selben Port (und IP) eine RTP-Verbindung auf. Die Erkennung basiert auf der abgehenden IP (aus dem SIP-Paket) des angesprochenen Telekom Gateways (aus dem SDP) und den angesprochenen Gateway-IP-Ports (SDP). Weitere Angaben im SDP (insb. TK-seitige IPs und Ports) werden ignoriert.
• STUN „torpediert“ diese NAT-Erkennung, da die Plattform NAT nicht mehr erkennen kann.
• Wenn STUN zum Einsatz kommt, muss aus jeden Fall sichergestellt sein, dass eingehende RTP-Verbindungen akzeptiert werden (mit einer normalen NAT-Firewall ist dies normalerweise nicht möglich), da die Plattform kein symmetrisches RTP anwendet.
• STUN sollte daher nur in Ausnahmefällen eingesetzt werden.
• Mit symmetrischen NAT ist eine Verbindung in Verbindung mit STUN in der Regel gar nicht möglich. Einige Router (z.B. Bintec) bieten aber mittels eines Assistenten die Möglichkeit, auf "Full Cone" NAT umzustellen. Damit ist dann eine Verbindung auch möglich, wenn die TK-Anlage STUN erzwingt.

Symmetrisches RTrtP / NAT-Erkennung / STUN
Die VoIP-Plattform der Telekom hat eine eingebaute automatische NAT-Erkennung. Hierfür muss die TK-Anlage symmetrisches RTP unterstützen. STUN „torpediert“ diese NAT-Erkennung und sollte nur in Ausnahmefällen eingesetzt werden.

8

German - Deutsch / Re: 2 x LAN, gleicher IP-Adressbereich, Blocking UPNP usw...

« on: March 22, 2022, 08:02:44 am »

Also ich habe/hatte bei mir die Fritz im "LAN" und außer den Standartregeln ("Default allow LAN to any rule") nichts eingestellt. Auch 2 SIP-Telefone und eine Asterisk (FreePBX) funktioniert so ohne Probleme, Sowohl bei der Registrierung über die Asterisk als auch bei Registrierung direkt in der Platform.

Ich musste die Fritz nur wieder vor die OpnSense hängen, damit mein Magenta-TV fehlerfrei Funktioniert. Telefonie macht diese nun aber nicht mehr.

9

German - Deutsch / Re: 2 VoIP Provider und keinen Plan vom Thema

« on: March 22, 2022, 07:58:16 am »

Da die Telekom gerade ihre IMS Plattform umstellt/erneuert kann es helfen die SIP-Registrierung von UDP auf TCP umzustellen (Wenn es sich um einen ALL-IP Anschluss handelt, bei SIP-Trunk funktioniert eh nur TCP oder TLS)

Zum Thema DNS habe ich folgende Informationen für dich:
Damit die Telefonie Reibungslos funktioniert habe ich im, AdGuard u.g. DNS-Server für meine VoiP Geräte (2 SIP-Telefone und 1 FreePBX) als Upstream-DNS-Server hinterlegt.

DNS im VoIP-Umfeld an Telekom-Anschlüssen
Grundsätzlich soll in einem TK-System (bzw. Router) immer der DNS Server des jeweiligen Internetzugangsanbieters eingetragen werden. Bei Telekom-Anschlüssen mit PPPoE Einwahl (xDSL) werden diese automatisch bei der Einwahl vergeben. Bei CompanyConnect (CoCo)/DeutschlandLAN Connect IP (DCIP) sowie beim Business Premium Access (BPA) sind diese auf dem Kundenanschreiben hinterlegt.

DNS im VoIP-Umfeld bei Fremdaccess
Falls der Kunde einen Fremdaccess nutzt (z.B. Vodafone als Trägerleitung) sollten auch die DNS Server des Anbieters eingetragen werden. Falls diese kein eDNS und ECS unterstützen, kann der DNS-Server der BPA-Anschlüsse verwendet werden.

DNS-Server für BPA

Standort	IPv4 Adresse	IPv6 Adresse	Reverse Lookup Name
Frankfurt	194.25.0.70	2003:40:2000::0B9A	resolvbpa-f.t-ipnet.de
Hannover	194.25.0.62	2003:56::0B9A	resolvbpa-h.t-ipnet.de
Leipzig	194.25.0.54	2003:40:4000::0B9A	resolvbpa-l.t-ipnet.de

Was passiert, wenn ich einen falschen DNS-Server nutze?
Wird beispielsweise an einem Fremdaccess oder Company Connect ein DNS-Server verwendet, der eigentlich für PPPoE-Anschlüsse der Telekom (z.B. xDSL, FTTH) vorgesehen ist, wird dieser entsprechend die SIP-Proxys (P-CSCF) zurückgeben, welche eine aktivierte Bandbreitenreservierung beherrschen. Diese Bandbreitenreservierung würde aber fehlschlagen, da das RACS (Resource and Admission Control Subsystem) beim Fremdaccess oder Company Connect keine Bandbreitenreservierung ermöglichen kann. Somit würde die SIP-Registrierung erfolgreich durchgeführt, aber keine Gespräche möglich.

Umgekehrt wäre bei einem PPPoE Anschluss und Abfrage eines DCIP-DNS Servers keine Bandbreitenreservierung möglich, da vom DCIP-DNS Server der falsche RACS zurückgegeben würde.

Eine weitere Fehlerquelle besteht darin, dass am Fremdaccess bei Verwendung eines DNS-Servers der Telekom  bei einer SRV-Anfrage Server für die Nutzung von Diensten angeboten werden, die über den Fremdaccess nicht erreichbar sind.

10

German - Deutsch / Re: 2 x LAN, gleicher IP-Adressbereich, Blocking UPNP usw...

« on: March 21, 2022, 11:56:01 am »

Normalerweise musst du bei einer sym. Firewall nichts freigeben. Auch ein Portforwarting zu den VoIP-Clients (FritzBoxen musst du nicht einlegen, da die Verbindungen immer von Client (Fritz) zum Provider aufgebaut werden.
Zumindest habe ich schon diverse FritzBoxen als VoIP Client hinter verschiendensten Routern gehapt und musste nie einen Port von WAN ins LAN explizit weiterleiten. Lediglich der Verkehr von den FitzBoxen ins WAN musste erlaubt sein.

11

German - Deutsch / Re: Unifi APs bekommen keine IP-Adressen per VLAN

« on: March 11, 2022, 02:41:44 pm »

Na dein AP tagged die Pakete doch (auf VLAN 199). Also muss dein Switch das VLAN auch kennen/durchlassen

12

German - Deutsch / Re: QinQ / 802.1ad Support ?

« on: March 11, 2022, 02:39:48 pm »

Ich kann dir auf die Frage was ein „dummer unmanaged Switch“ macht zwar eine Antwort geben, diese wird dich aber nicht weiter bringen:
Es kommt darauf an/ alles ist möglich.
Bei meiner Arbeit habe ich schon alles erlebt:

• Dem Switch war das VLAN-TAG egal und er hat das Paket einfach weiter geleitet
• Der Switch hat Pakete mit VLAN-TAG einfach verworfen
• Der Switch hat das VLA-TAG entfernt

Mit freundlichen Grüßen
Roland

13

German - Deutsch / Re: 2 x LAN, gleicher IP-Adressbereich, Blocking UPNP usw...

« on: March 11, 2022, 02:28:56 pm »

Wenn er aber in jeder Wohnung das gleiche Netz (Die Gleiche Netz-Adresse) haben will, so müsste er mit NAT arbeiten, oder?

14

German - Deutsch / Re: OPNsense Glasfaser - mehrere Ports, LAN geht, WLAN nicht

« on: March 11, 2022, 02:26:51 pm »

Wenn ich mich recht erinnere, wird nur beim “LAN“ (bei dir vital. „Desktop-PC“) die
„Default allow LAN to any rule“ angelegt. Für alle weiteren Netze musst du aktiv werden werden, denn wenn keine Regel vorhanden ist, wird alles geblockt (Deby all)

Mit freundlichen Grüßen
Roland

P.S. Da vmtl. das WLAN und der Desktop ins gleiche Netz sollen müsstest du mit Bridge arbeiten:
https://docs.opnsense.org/manual/how-tos/lan_bridge.html

15

German - Deutsch / Re: 2 x LAN, gleicher IP-Adressbereich, Blocking UPNP usw...

« on: March 11, 2022, 02:12:28 pm »

So wie ich das verstanden habe, möchte @alxemosel dies ja genau so haben.
Also das die UPNP/Multicast Geschichten nicht über die Netze hinweg funktionieren.
Des Weiteren sollen aber RemoteDesktop, SMB-Freigaben etc. aus beiden Netzen erreichbar sein.

So habe ich es zumindest verstanden