Gelöst

VoIP/SIP-Registrierung: Ports in firewall

vor 2 Jahren

Hallo,

bisher diente ein Fritz.Box als Gateway zum Internet (MagentaZuHause). VoIP hat ohne Problem funktioniert, da die Fritz.Box bereits alle notwendigen ports freigeschalten hatte.

 

Die Fritz.Box wurde durch eine einge Firewall ersetzt (nftables Filterregeln). Das Telefonieren nach außen funktioniert.

Allerdings klappt das Angerufenwerden noch nicht, d.h. die Registrierung scheint nicht korrekt zu sein. Es erfolgt kein Rufzeichen beim Anrufer und das Gigaset klingelt nicht.

 

Welche ports sind hierfür notwendig?

 

Setting: Internet => Modem (im Bridge-Mode) => Firewall (NAT) => Switch => Gigaset

 

Telefon: Gigaset C430A GO 

SIP-Ports: 5060 - 5076

RTP-Ports: 5004 - 5020

 

Folgende Pakete sind auf der LAN-Schnittstelle ( PBX ; lokale IP: 10.0.1.40) zu sehen:

IP 10.0.1.40.5060 > 217.0.21.2.5060: SIP

IP 186.42.174.226.5060 > 10.0.1.40.5060: SIP: OPTIONS sip:100@84.170.1.1 SIP/2.0

IP 10.0.1.40.5060 > 217.0.21.2.5060: SIP: REGISTER sip:tel.t-online.de SIP/2.0
IP 217.0.21.2.5060 > 10.0.1.40.5060: SIP: SIP/2.0 200 OK

 

WAN.Schnittstelle (Firewall; öffentlich IP: 84.170.1.1):

IP 84.170.1.1.5060 > 217.0.21.2.5060: SIP
IP 217.0.21.2.5060 > 84.170.1.1.5060: SIP: INVITE sip:<hier steht die TelNo>@84.170.1.1:5060 SIP/2.0 <= Anruf !
IP 217.0.21.2 > 84.170.1.1: ip-proto-17

IP 84.170.1.1.5060 > 217.0.21.2.5060: SIP: REGISTER sip:tel.t-online.de SIP/2.0
IP 217.0.21.2.5060 > 84.170.1.1.5060: SIP: SIP/2.0 200 OK

6073

39

    • vor 2 Jahren

      keine!  VOIP braucht niemals eingehende freigeschaltet Ports

       

      alles andere sind Falschinformationen oder aber ein anderer Fehler liegt vor.

       

      Auf der Firewall sollte kein SIP ALG laufen

      12

      Antwort

      von

      vor 8 Monaten

      PaloAltoNetworks

      Daß immer wieder Probleme auftreten wenn Telekom-Kunden ihre Telefonie - egal mit welchem Gerät - hinter einer Firewall laufen lassen möchten, liegt daran, daß keinerlei Offenlegung der benötigten Informationen (z. B. IP Addressen der SIP Server) trotz bestehender gesetzlicher Verpflichtungen erfolgt.

       

      Daß immer wieder Probleme auftreten wenn Telekom-Kunden ihre Telefonie - egal mit welchem Gerät - hinter einer Firewall laufen lassen möchten,

      liegt daran, daß keinerlei Offenlegung der benötigten Informationen (z. B. IP Addressen der SIP Server) trotz bestehender gesetzlicher Verpflichtungen erfolgt.

      PaloAltoNetworks

       

      Daß immer wieder Probleme auftreten wenn Telekom-Kunden ihre Telefonie - egal mit welchem Gerät - hinter einer Firewall laufen lassen möchten,

      liegt daran, daß keinerlei Offenlegung der benötigten Informationen (z. B. IP Addressen der SIP Server) trotz bestehender gesetzlicher Verpflichtungen erfolgt.


      Die stehen im DNS, öffentlicher geht es wohl kaum.

       

      PaloAltoNetworks

      Die DNS SRV Requests sind bislang KEIN gängiger Standard in der Industrie!

      Die DNS SRV Requests sind bislang KEIN gängiger Standard in der Industrie!
      PaloAltoNetworks
      Die DNS SRV Requests sind bislang KEIN gängiger Standard in der Industrie!

      Dass das nicht stimmt erkennst Du doch schon daran, dass praktisch alle aktuellen SIP-Telefone SRV unterstützen.

      Antwort

      von

      vor 8 Monaten

      Vielen Dank, genau diese Dokumentation hat mir gefehlt!

      Antwort

      von

      vor 8 Monaten

      @PaloAltoNetworks 

      RFC2782 ist durch RFC3263 ergänzt

      Uneingeloggter Nutzer

      Antwort

      von

    • vor 2 Jahren

      ogx

      VoIP hat ohne Problem funktioniert, da die Fritz.Box bereits alle notwendigen ports freigeschalten hatte.

      VoIP hat ohne Problem funktioniert, da die Fritz.Box bereits alle notwendigen ports freigeschalten hatte.

       

      ogx

      VoIP hat ohne Problem funktioniert, da die Fritz.Box bereits alle notwendigen ports freigeschalten hatte.

       


      Hallo @ogx ,

      wo wurde denn das Gigaset 430A GO registriert (Telekom direkt per DNS-SRV oder an der FRITZ!Box)?

      24

      Antwort

      von

      vor 2 Jahren

      Stefan

      das hatte ich gestern auch schon vermutet und geschrieben.

      das hatte ich gestern auch schon vermutet und geschrieben.
      Stefan
      das hatte ich gestern auch schon vermutet und geschrieben.

      Sorry, der Thread ist inzwischen etwas unübersichtlich geworden.

      Antwort

      von

      vor 2 Jahren

      lejupp

      Sorry, der Thread ist inzwischen etwas unübersichtlich geworden.

      Sorry, der Thread ist inzwischen etwas unübersichtlich geworden.
      lejupp
      Sorry, der Thread ist inzwischen etwas unübersichtlich geworden.

      So hatte ich das gar nicht verstanden haben wollen - wollte eigentlich nur bestätigen, dass es daran liegen könnte

       

      alles gut

      Antwort

      von

      vor 2 Jahren

      lejupp

      Muss kein Firewallproblem sein, kann auch einfach sein dass das NAT-Timeout für UDP zu kurz gefasst ist.

      Muss kein Firewallproblem sein, kann auch einfach sein dass das NAT-Timeout für UDP zu kurz gefasst ist.

      lejupp

      Muss kein Firewallproblem sein, kann auch einfach sein dass das NAT-Timeout für UDP zu kurz gefasst ist.


      Ich glaube nicht, daß es an zu kurzen NAT-Timeouts für UDP liegt.

      NAT basiert auf conntrack. Daher habe ich die sysctls net.netfilter.nf_conntrack_udp_timeout_stream und net.netfilter.nf_conntrack_udp_timeout jeweils auf 300s gesetzt. Es hat nichts gebracht.

       

      Im conntrack sehe ich keine Daten bzgl. port 5060 bzw. dem Telekom-Netz.

       

      Das deckt sich mit meiner Beobachtung, daß die Pakete auf der WAN-Schnittstelle eintreffen, aber nicht in das Netz weitergeleitet werden. D.h. tcpdump auf der Schnittstelle an der das Gigaset hängt sehe ich keine UDP aus dem Telekom-Netz.

      Uneingeloggter Nutzer

      Antwort

      von

      Uneingeloggter Nutzer

      Frage

      von