Solved

VoIP/SIP-Registrierung: Ports in firewall

2 years ago

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

6077

39

    • 2 years ago

      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

      Answer

      from

      8 months ago

      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.

      Answer

      from

      8 months ago

      Vielen Dank, genau diese Dokumentation hat mir gefehlt!

      Answer

      from

      8 months ago

      @PaloAltoNetworks 

      RFC2782 ist durch RFC3263 ergänzt

      Unlogged in user

      Answer

      from

    • 2 years ago

      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

      Answer

      from

      2 years ago

      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.

      Answer

      from

      2 years ago

      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

      Answer

      from

      2 years ago

      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.

      Unlogged in user

      Answer

      from

      Unlogged in user

      Ask

      from