22
Asterisk-voip + cisco +"ip-anlagAS vodafone" + watchguard
Hallo,
wenn man eine Business-Vodafone Internetleitung mit einem
(Vodafone) CISCO C1111-4PLTE hat....
Frage: Kann man dann den alten BINTEC R123 (bisherige Router für PCs,Server) auch abkoppeln und ins Regal tun?
Es geht um 3 PCs + Ansitel-PBX + Yealink im selben LAN.
Antwort meines Wissens nach: NEIN unüblich/geht nicht.
Vodafone geht davon aus, Firmenkunden immer noch eigene Router/Firewall verwenden möchten und bietet das nicht an.
Provider "managed" Router haben ja den Nachteil, das Portforwarding u.ä. Tage dauern kann und bei o2 z.B. 50€ kostet. (wenn One Access vorh.)
Grund der Frage: on-premises die Ansitel PBX hat sporadisch ausgehend kein Amt
Fehler: man hört nix und kann einfach nicht rauswählen - nach paar Minuten geht es von selbst wieder...
Wenn nun Bintec als Fehlerquelle ausgeschlossen wird und stattdessen der o.g. CISCO der neue "All-in-One" Router wäre, dann wäre ein Kreuztest durchgeführt ob der Fehler weg ist. ANSITEL und VODAFONE verweisen auf eine falsche Routereinstellung.
Eingehend wird offenbar nur 5060 TCP zur PBX benötigt sonst nix. (unter NAT beim BINTEC) (laut Vodafone)
Der BINTEC Wizard "PBX im LAN" verweist auf die lokale Ansitel PBX IP.
Sonst ist der BINTEC eigentlich im Urzusand wie aufgefunden. (sieht nach DEFAULT aus) und hat die aktuelle FIRMWARE.
Der BINTEC Support verweist natürlich auf ein PCAP während der Störung.
Laut Vodafone ist der Fehler dahingehend zu sehen das die "Option Pings" in beide Richtungen nicht sauber hin-und-her laufen.
Gruß
wenn man eine Business-Vodafone Internetleitung mit einem
(Vodafone) CISCO C1111-4PLTE hat....
Frage: Kann man dann den alten BINTEC R123 (bisherige Router für PCs,Server) auch abkoppeln und ins Regal tun?
Es geht um 3 PCs + Ansitel-PBX + Yealink im selben LAN.
Antwort meines Wissens nach: NEIN unüblich/geht nicht.
Vodafone geht davon aus, Firmenkunden immer noch eigene Router/Firewall verwenden möchten und bietet das nicht an.
Provider "managed" Router haben ja den Nachteil, das Portforwarding u.ä. Tage dauern kann und bei o2 z.B. 50€ kostet. (wenn One Access vorh.)
Grund der Frage: on-premises die Ansitel PBX hat sporadisch ausgehend kein Amt
Fehler: man hört nix und kann einfach nicht rauswählen - nach paar Minuten geht es von selbst wieder...
Wenn nun Bintec als Fehlerquelle ausgeschlossen wird und stattdessen der o.g. CISCO der neue "All-in-One" Router wäre, dann wäre ein Kreuztest durchgeführt ob der Fehler weg ist. ANSITEL und VODAFONE verweisen auf eine falsche Routereinstellung.
Eingehend wird offenbar nur 5060 TCP zur PBX benötigt sonst nix. (unter NAT beim BINTEC) (laut Vodafone)
Der BINTEC Wizard "PBX im LAN" verweist auf die lokale Ansitel PBX IP.
Sonst ist der BINTEC eigentlich im Urzusand wie aufgefunden. (sieht nach DEFAULT aus) und hat die aktuelle FIRMWARE.
Der BINTEC Support verweist natürlich auf ein PCAP während der Störung.
Laut Vodafone ist der Fehler dahingehend zu sehen das die "Option Pings" in beide Richtungen nicht sauber hin-und-her laufen.
Gruß
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1644957168
Url: https://administrator.de/contentid/1644957168
Printed on: May 5, 2024 at 02:05 o'clock
22 Comments
Latest comment
Um eine Aussage zu treffen, müsste man wissen, wie der Cisco-Router konfiguriert ist. Da müsste man dann halt verschiedene Sachen abfragen (NAT aktiv, DHCP/DNS-Server/-Relay aktiv (wenn gewünscht), Firewall konfiguriert, ...)
Grundlegend ist der bintec nicht mehr nötig, wenn die Konfiguration stimmt. Der bintec ist sogar nur eine weitere Fehlerquelle.
Ich kenn jetzt weder Ansitel als PBX noch Vodafone als Business-SIP-Provider, aber heute ist es unüblich, dass man eine Portweiterleitung für die Telefonie machen muss. Mit Ausnahme von SIP-Trunks, die ohne Authentifizierung, dafür stattdessen mit fest hinterlegten IP-Adressen arbeiten, lernen die SBC beim Provider die nötigen IP-Adressen des Kunden und sollten mittlerweile alle NAT-fähig sein. Bei Privatkunden-SIP sieht es hier noch anders aus.
Es klingt aber so, dass die SIP-Registrierung bei dir verloren geht. Ich weiß, dass ich 2014 bintec RS353j mit Telekom-SIP verflucht habe, so dass ich später noch Fritzboxen davor geschaltet habe. Genau mit diesem Problem. Die selben Anschlüsse sind dann zwei Jahre später auf LANCOM-Router umgebaut werden, Problem weg. War nie wirklich greifbar. Schau mal, ob das NAT-Timeout geringer ist als das NAT-Keepalive, welches der SIP-Provider ausweist und welches in deiner Telefonanlage konfiguriert ist.
Grundlegend ist der bintec nicht mehr nötig, wenn die Konfiguration stimmt. Der bintec ist sogar nur eine weitere Fehlerquelle.
Ich kenn jetzt weder Ansitel als PBX noch Vodafone als Business-SIP-Provider, aber heute ist es unüblich, dass man eine Portweiterleitung für die Telefonie machen muss. Mit Ausnahme von SIP-Trunks, die ohne Authentifizierung, dafür stattdessen mit fest hinterlegten IP-Adressen arbeiten, lernen die SBC beim Provider die nötigen IP-Adressen des Kunden und sollten mittlerweile alle NAT-fähig sein. Bei Privatkunden-SIP sieht es hier noch anders aus.
Es klingt aber so, dass die SIP-Registrierung bei dir verloren geht. Ich weiß, dass ich 2014 bintec RS353j mit Telekom-SIP verflucht habe, so dass ich später noch Fritzboxen davor geschaltet habe. Genau mit diesem Problem. Die selben Anschlüsse sind dann zwei Jahre später auf LANCOM-Router umgebaut werden, Problem weg. War nie wirklich greifbar. Schau mal, ob das NAT-Timeout geringer ist als das NAT-Keepalive, welches der SIP-Provider ausweist und welches in deiner Telefonanlage konfiguriert ist.
Der Satz...
Wenn sie davon ausgehen das Firmenkunden sowas machen (was sie in der Regel aus guten Gründen ja auch immer tun, Router in eigener Hoheit) sollten sie genau das ja fördern. Was sie natürlich bei ihren Business Kunden auch machen sonst wären sie diese alle los. Keiner von den Business Kunden lässt sich da eine Consumer Plastebox hinstellen von denen.
Fakt ist das der 1100er völlig problemlos an einem Vodkafön Anschluss rennt. Siehe auch entsprechende Setups im hiesigen Cisco Router Tutorial.
Wie Kollege @tikayevent oben schon richtig sagt ist das Setup relevant. Ganz besonders wie die Firewall eingestellt ist und vor allem welche (CBAC oder ZFW). Ohne die Konfig (show run) zu kennen ist das Kristallkugel...
Zumindestens mit Asterisk, 3CX, Auerswald, Yealink, Gigaset, Cisco 79xx und 88xx Phones usw. rennt VoIP völlig fehlerlos. Egal welcher SIP Provider.
Vodafone geht davon aus, Firmenkunden immer noch eigene Router/Firewall verwenden möchten
Ist ja irgendwie wirr und unverständlich der Satz. Wenn sie davon ausgehen das Firmenkunden sowas machen (was sie in der Regel aus guten Gründen ja auch immer tun, Router in eigener Hoheit) sollten sie genau das ja fördern. Was sie natürlich bei ihren Business Kunden auch machen sonst wären sie diese alle los. Keiner von den Business Kunden lässt sich da eine Consumer Plastebox hinstellen von denen.Fakt ist das der 1100er völlig problemlos an einem Vodkafön Anschluss rennt. Siehe auch entsprechende Setups im hiesigen Cisco Router Tutorial.
Wie Kollege @tikayevent oben schon richtig sagt ist das Setup relevant. Ganz besonders wie die Firewall eingestellt ist und vor allem welche (CBAC oder ZFW). Ohne die Konfig (show run) zu kennen ist das Kristallkugel...
Zumindestens mit Asterisk, 3CX, Auerswald, Yealink, Gigaset, Cisco 79xx und 88xx Phones usw. rennt VoIP völlig fehlerlos. Egal welcher SIP Provider.
Eingehend wird offenbar nur 5060 TCP zur PBX benötigt
Wenn ich das lese, denke ich Du musst erstmal noch im VOIP-Urschleim beginnen. Der Austausch von Routern macht nichts magisches. Router bleibt Router. Die Einstellung machts. Offene Ports eingehend braucht man nur für standortübergreifenden (externen) Zugriff. Ansonsten nicht, wie Kollege @tikayevent schon angemerkt hat.Das von Dir geschilderte Problem liegt sehr oft bei den UDP-Timeouts von Anlage und Router. Also Timeouts kontrollieren. Ach so, hat Kollege @tikayevent ja auch schon geschrieben. Doppelt hält vielleicht besser
Good luck.
Viele Grüße, commodity
liegt sehr oft bei den UDP-Timeouts von Anlage und Router.
Zumindestens der Cisco hat mit der ZFW ein ALG für VoIP so das das weniger kritisch ist. Wenn man es denn richtig konfiguriert...?! STUN bei VoIP zu aktivieren ist also auch hier immer angeraten. 
Zitat von @aqui:
liegt sehr oft bei den UDP-Timeouts von Anlage und Router.
Zumindestens der Cisco hat mit der ZFW ein ALG für VoIP so das das weniger kritisch ist. Wenn man es denn richtig konfiguriert...?! STUN bei VoIP zu aktivieren ist also auch hier immer angeraten. Solche pauschalen Aussagen sollte man nicht tätigen. Viele SIP-Provider verbieten die Nutzung von SIP-ALGs, was ich auch verstehen kann, da es so viele Dialekte gibt, dass ein ALG die gar nicht verstehen kann. Bei STUN das gleiche. Nur wenn der Anbieter es vorgibt.
Hallo,
trotz Test-Wechsel auf Watchguard (gegen BINTEC) ist das Problem weiterhin vorhanden.
Die Ansitel PBX hat sporadisch ausgehend kein Amt (sozusagen)
Fehler: man hört nix und kann einfach nicht rauswählen, die Yealink Telefone zeigen no serivce.
Nach paar Minuten geht es von selbst wieder.
trotz Test-Wechsel auf Watchguard (gegen BINTEC) ist das Problem weiterhin vorhanden.
Die Ansitel PBX hat sporadisch ausgehend kein Amt (sozusagen)
Fehler: man hört nix und kann einfach nicht rauswählen, die Yealink Telefone zeigen no serivce.
Nach paar Minuten geht es von selbst wieder.
"Schau mal, ob das NAT-Timeout geringer ist als das NAT-Keepalive, welches der SIP-Provider ausweist und welches in deiner Telefonanlage konfiguriert ist"
Ok - wird geprüft
Ok - wird geprüft
Geht es denn überhaupt noch um den Cisco Router ??
Wenn ja und du eine ZFW Firewall Konfig nutzt (leider macht du dazu ja keinerlei Angaben ! ) auf dem C1111 dann sollte die so aussehen:
Damit rennt jegliche VoIP Anlage im lokalen Netz fehlerlos !
(Wenn du kein IPv6 am Router hast oder nutzt kannst du alle IPv6 bezogenen Konfig Schritte oben weglassen !)
Wenn ja und du eine ZFW Firewall Konfig nutzt (leider macht du dazu ja keinerlei Angaben !
) auf dem C1111 dann sollte die so aussehen:class-map type inspect match-any ALLOW_IN
match access-group name ALLOWv4
match access-group name ALLOWv6
class-map type inspect match-any ICMPv6
match access-group name ICMPv6
class-map type inspect match-any LocalAllowed
match protocol dns
match protocol http
match protocol https
match protocol pop3s
match protocol pop3
match protocol imaps
match protocol imap3
match protocol imap
match protocol smtp
match protocol sip
match protocol sip-tls
match protocol rtsp
match protocol ftp
match protocol ftps
match protocol ssh
match protocol ntp
match protocol tcp
match protocol udp
match protocol icmp
class-map type inspect match-any RouterProtocols
match class-map ALLOW_IN
match protocol tcp
match protocol udp
match protocol icmp
!
policy-map type inspect ICMPv6
description Traffic ICMPv6 to LAN
class type inspect ICMPv6
inspect
class class-default
drop
policy-map type inspect RouterToInternet
description Traffic Router to Internet
class type inspect RouterProtocols
inspect
class class-default
drop
policy-map type inspect LocalToInternet
description Traffic LAN to Internet
class type inspect LocalAllowed
inspect
class class-default
drop
policy-map type inspect InternetToRouter
description Permitted traffic Internet to router
class type inspect ALLOW_IN
pass
class class-default
drop
!
!
zone security Local
zone security Internet
zone-pair security LocalToInternet source Local destination Internet
service-policy type inspect HomeToInternet
zone-pair security ICMPv6 source Internet destination Local
service-policy type inspect ICMPv6
zone-pair security InternetToRouter source Internet destination self
service-policy type inspect InternetToRouter
zone-pair security RouterToInternet source self destination Internet
service-policy type inspect RouterToInternet
!
ip access-list extended ALLOWv4
10 permit udp any any eq isakmp
20 permit udp any any eq non500-isakmp
30 permit esp any any
!
ipv6 access-list ALLOWv6
sequence 10 permit udp any eq 547 any eq 546
!
ipv6 access-list ICMPv6
sequence 10 permit icmp any any unreachable
sequence 20 permit icmp any any packet-too-big
sequence 30 permit icmp any any hop-limit
sequence 40 permit icmp any any reassembly-timeout
sequence 50 permit icmp any any header
sequence 60 permit icmp any any next-header
sequence 70 permit icmp any any parameter-option
sequence 80 permit icmp any any echo-request
sequence 90 permit icmp any any echo-reply
sequence 100 permit icmp any any dhaad-request
sequence 110 permit icmp any any dhaad-reply
sequence 120 permit icmp any any mpd-solicitation
sequence 130 permit icmp any any mpd-advertisement
!(Wenn du kein IPv6 am Router hast oder nutzt kannst du alle IPv6 bezogenen Konfig Schritte oben weglassen !)
Hi,
danke für die beiträge!
Vodafone sagt, der CISCO ist nicht als "managend-router für das lokale-Kundennetzwerk gedacht" sondern für Standortvernetzung bzw. als vorgeschalteter Router. Kunden müssen immer noch ihr eigenen Router verwenden.
danke für die beiträge!
Vodafone sagt, der CISCO ist nicht als "managend-router für das lokale-Kundennetzwerk gedacht" sondern für Standortvernetzung bzw. als vorgeschalteter Router. Kunden müssen immer noch ihr eigenen Router verwenden.
Beobachtung war: im Watchguard Log sind diese Meldungen gewesen, möglicherweise zu dem Zeitpunkt des VOIP Fehlers, wird noch geprüft.
2022-01-04 15:35:27 Deny 192.168.0.35 176.95.xx.x sip/tcp 47154 5060 1-Trusted Firebox tcp syn checking failed (expecting SYN packet for new TCP connection, but received ACK, FIN, or RST instead). 1047 64 (Internal Policy) proc_id="firewall" rc="101" msg_id="3000-0148" tcp_info="offset 8 A 3048894853 win 266"
2022-01-04 15:37:28 Deny 192.168.0.35 176.95.xx.x sip/tcp 47154 5060 1-Trusted Firebox tcp syn checking failed (expecting SYN packet for new TCP connection, but received ACK, FIN, or RST instead). 1047 64 (Internal Policy) proc_id="firewall" rc="101" msg_id="3000-0148" tcp_info="offset 8 A 3048894853 win 266"//
edit:
unter Watchguard/Globalsettings ist es jetzt temporär ausgeschaltet
"Enable TCP SYN packet and connection state verification"
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fir ...
https://techsearch.watchguard.com/KB?type=Article&SFDCID=kA16S000000 ...
192.168.0.35 - asterisk-pbx im lokalen watchguard netzwerk
176.95.xx.x - vodafone sbc (scheint mir extern zu sein)
watchguard WAN: cisco von vodafone
watchguard trusted: lokaler netzwerk-switch
Habe noch nicht im Dimension geprüft wie oft die Meldung kommt.
Ich vermute, das zu dem Zeitpunkt die ausgehende Telefonie nicht ging.
"Service not available" steht dann im Grandstream+Yealink Display. Eingehend läuft des durchgehend.
Anders gesagt: sporadisch gehen Calls für ca. 10-30min (mehrmals wöchentlich/täglich)
Vodafone sieht eindeutig, das nix bei sich ankommt >> wenn versucht wird ausgehend anzurufen.
Asterisk sieht das lokal "was rauswill" wenn man einen ausgehenden Call probiert. (fehlermeldung ist mir unbekannt)
In schriftlicher Abstimmung mit dem Eigentümer sind die Watchguard-Settings aktuell temporär nicht so streng abgesichert.
Der Watchguard-SNAT auf die Asterisk ist richtig erstellt. (es keine Häkchen gesetzt oder Felder eingetragen)
nur Anyexternal + die interne IP.
Andere mögliche vorstellbare Fehlerursache: der Vodafone SIP Anlagenanschluss wurde ohne vodafone-template d.h. benutzerdefiniert manuell in der Asterisk eingefügt. (kann auch eine Ursache sein m.A. nach) (nicht von mir)
Es handelt sich wohl um so ein Anschluss, d.h. es ist kein SIP Trunk.
https://www.vodafone.de/media/downloads/pdf/ip-anlagen-anschluss-schnitt ...
2022-01-04 15:35:27 Deny 192.168.0.35 176.95.xx.x sip/tcp 47154 5060 1-Trusted Firebox tcp syn checking failed (expecting SYN packet for new TCP connection, but received ACK, FIN, or RST instead). 1047 64 (Internal Policy) proc_id="firewall" rc="101" msg_id="3000-0148" tcp_info="offset 8 A 3048894853 win 266"
2022-01-04 15:37:28 Deny 192.168.0.35 176.95.xx.x sip/tcp 47154 5060 1-Trusted Firebox tcp syn checking failed (expecting SYN packet for new TCP connection, but received ACK, FIN, or RST instead). 1047 64 (Internal Policy) proc_id="firewall" rc="101" msg_id="3000-0148" tcp_info="offset 8 A 3048894853 win 266"//
edit:
unter Watchguard/Globalsettings ist es jetzt temporär ausgeschaltet
"Enable TCP SYN packet and connection state verification"
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fir ...
https://techsearch.watchguard.com/KB?type=Article&SFDCID=kA16S000000 ...
192.168.0.35 - asterisk-pbx im lokalen watchguard netzwerk
176.95.xx.x - vodafone sbc (scheint mir extern zu sein)
watchguard WAN: cisco von vodafone
watchguard trusted: lokaler netzwerk-switch
Habe noch nicht im Dimension geprüft wie oft die Meldung kommt.
Ich vermute, das zu dem Zeitpunkt die ausgehende Telefonie nicht ging.
"Service not available" steht dann im Grandstream+Yealink Display. Eingehend läuft des durchgehend.
Anders gesagt: sporadisch gehen Calls für ca. 10-30min (mehrmals wöchentlich/täglich)
Vodafone sieht eindeutig, das nix bei sich ankommt >> wenn versucht wird ausgehend anzurufen.
Asterisk sieht das lokal "was rauswill" wenn man einen ausgehenden Call probiert. (fehlermeldung ist mir unbekannt)
In schriftlicher Abstimmung mit dem Eigentümer sind die Watchguard-Settings aktuell temporär nicht so streng abgesichert.
Der Watchguard-SNAT auf die Asterisk ist richtig erstellt. (es keine Häkchen gesetzt oder Felder eingetragen)
nur Anyexternal + die interne IP.
Andere mögliche vorstellbare Fehlerursache: der Vodafone SIP Anlagenanschluss wurde ohne vodafone-template d.h. benutzerdefiniert manuell in der Asterisk eingefügt. (kann auch eine Ursache sein m.A. nach) (nicht von mir)
Es handelt sich wohl um so ein Anschluss, d.h. es ist kein SIP Trunk.
https://www.vodafone.de/media/downloads/pdf/ip-anlagen-anschluss-schnitt ...
..
UDP-Timeouts
Schau mal, ob das NAT-Timeout geringer ist als das NAT-Keepalive, welches der SIP-Provider ausweist und welches in >deiner Telefonanlage konfiguriert ist. Das von Dir geschilderte Problem liegt sehr oft bei den UDP-Timeouts von >Anlage und Router.
Schau mal, ob das NAT-Timeout geringer ist als das NAT-Keepalive, welches der SIP-Provider ausweist und welches in >deiner Telefonanlage konfiguriert ist. Das von Dir geschilderte Problem liegt sehr oft bei den UDP-Timeouts von >Anlage und Router.
Ich befasse mich damit aktuell noch, danke für die Hinweise!
Kenne aktuell nur diese Schalter in der Watchguard:
Unter Webui-Globalsettings, TCP connection idle timeout = 1 Hour
Zitat von @commodity:
Das von Dir geschilderte Problem liegt sehr oft bei den UDP-Timeouts von Anlage und Router. Also Timeouts kontrollieren. Ach so, hat Kollege @tikayevent ja auch schon geschrieben. Doppelt hält vielleicht besser
Good luck.
Viele Grüße, commodity
Eingehend wird offenbar nur 5060 TCP zur PBX benötigt
Wenn ich das lese, denke ich Du musst erstmal noch im VOIP-Urschleim beginnen. Der Austausch von Routern macht nichts magisches. Router bleibt Router. Die Einstellung machts. Offene Ports eingehend braucht man nur für standortübergreifenden (externen) Zugriff. Ansonsten nicht, wie Kollege @tikayevent schon angemerkt hat.Das von Dir geschilderte Problem liegt sehr oft bei den UDP-Timeouts von Anlage und Router. Also Timeouts kontrollieren. Ach so, hat Kollege @tikayevent ja auch schon geschrieben. Doppelt hält vielleicht besser
Good luck.
Viele Grüße, commodity
Hi,
also bei UNIFY TK Anlagen (vodafone+telekom) die im lokalen Netzwerk hinter der Watchguard stehen kann ich das absolut bestätigen, das Port 5060 eingehend nicht "geforwarded" werden muss.
Bei der Asterisk hat die TK-Firma das mündlich angeordnet.
Vodafone sagt,...
Typische 1st Level Antwort von DAUs für DAUs. Muss man bei Vodafone sicher nicht weiter kommentieren... Aber egal...ist ja nun scheinbar kein Cisco Problem mehr sondern ein Wireguard Problem.
nee
Nee, Vodafone ist aktuell wirklich gut.
Als der Fehler vorhin "spürbar war" , da konnte Vodafone Support in den IP Anlagenanschluss reingucken und sehen das nix ankommt.
Falls du nicht kanntest: mittels dem Vodafone-Message-Tracker (Screenshots + TXT an Support übermitteln) kann man immerhin auch paar Infos "one-way" schicken.
Zitat von @aqui:
Aber egal...ist ja nun scheinbar kein Cisco Problem mehr sondern ein Wireguard Problem.
Vielleicht wäre es dann sinnvoller diesen Thread zu schliessen: How can I mark a post as solved? und einen neuen mit entsprechender neuer, aussagekräftiger Thread Überschrift zu öffnen...?!
Vodafone sagt,...
Typische 1st Level Antwort von DAUs für DAUs. Muss man bei Vodafone sicher nicht weiter kommentieren... Aber egal...ist ja nun scheinbar kein Cisco Problem mehr sondern ein Wireguard Problem.
Vielleicht wäre es dann sinnvoller diesen Thread zu schliessen: How can I mark a post as solved? und einen neuen mit entsprechender neuer, aussagekräftiger Thread Überschrift zu öffnen...?!
Nee, Vodafone ist aktuell wirklich gut.
Als der Fehler vorhin "spürbar war" , da konnte Vodafone Support in den IP Anlagenanschluss reingucken und sehen das nix ankommt.
Falls du nicht kanntest: mittels dem Vodafone-Message-Tracker (Screenshots + TXT an Support übermitteln) kann man immerhin auch paar Infos "one-way" schicken.
Nee, Vodafone ist aktuell wirklich gut.
Wenn du das sagst...P.S.:
Etwas korrekte Rechtschreibung (Groß- Klein) in geänderten Überschriften wäre vielleicht auch nicht falsch... Sieht dann nicht ganz so kryptisch aus und man wüsste was gemeint ist !
Nee, Vodafone ist aktuell wirklich gut.
Den hänge ich mir an die Wand 
Viele Grüße, commodity
Hallo,
bis neulich in der lokalen Firewall nur nur 5060 TCP eingehend zur Asterisk PBX erlaubt,
weil es ja zu 2/3 lief mit sporadisch ausgehendem fehler (keine ausgehende telefone möglich für ca. 30min)
Ferner hatte der Techniker der Asterisk Firma und der Vodafonetechniker keine anderen Portfreigaben "gewollt/gewußt"
Anders gesagt, hinzufügen von Firewall-Regeln war die Lösung, d.h. UDP 5060 + RTP Ports eingehend
udp 10.000-20.000
Davon ist auf Seite 17 die Rede:
https://www.vodafone.de/media/downloads/pdf/ip-anlagen-anschluss-schnitt ...
** Der SBC erkennt, dass die IP-Adressen in den SIP- und SDP-Signalisierungen von der Transport-IPAdresse (NAT-Router) abweichen. Deshalb ignoriert er diese Adressen und sendet seine SIP-Antworten
sowie RTP-Daten an den NAT-Router. Für die SIP-Antworten existiert bereits ein Eintrag in der NAT
Session Table. Damit dies identisch für RTP umgesetzt werden kann, muss allerdings zunächst die TKAnlage oder ein Telefon RTP-Daten zum SBC gesendet haben.
Potentielle Probleme: Wenn die TK-Anlage bzw. das Telefon nicht sofort RTP-Daten versendet, sind
keine Early-Media-Ansagen zu hören. Wenn die TK-Anlage bzw. das Telefon während einer bestehenden
Verbindung über einen längeren Zeitraum keine RTP-Daten versendet (z.B. bei Sprachpausenerkennung oder Halten), löscht der NAT-Router ggf. den Eintrag aus der Session Table und lässt damit keine
RTP-Daten vom SBC mehr passieren.
Lösung: Port Forwarding für RTP aktivieren.
bis neulich in der lokalen Firewall nur nur 5060 TCP eingehend zur Asterisk PBX erlaubt,
weil es ja zu 2/3 lief mit sporadisch ausgehendem fehler (keine ausgehende telefone möglich für ca. 30min)
Ferner hatte der Techniker der Asterisk Firma und der Vodafonetechniker keine anderen Portfreigaben "gewollt/gewußt"
Anders gesagt, hinzufügen von Firewall-Regeln war die Lösung, d.h. UDP 5060 + RTP Ports eingehend
udp 10.000-20.000
Davon ist auf Seite 17 die Rede:
https://www.vodafone.de/media/downloads/pdf/ip-anlagen-anschluss-schnitt ...
** Der SBC erkennt, dass die IP-Adressen in den SIP- und SDP-Signalisierungen von der Transport-IPAdresse (NAT-Router) abweichen. Deshalb ignoriert er diese Adressen und sendet seine SIP-Antworten
sowie RTP-Daten an den NAT-Router. Für die SIP-Antworten existiert bereits ein Eintrag in der NAT
Session Table. Damit dies identisch für RTP umgesetzt werden kann, muss allerdings zunächst die TKAnlage oder ein Telefon RTP-Daten zum SBC gesendet haben.
Potentielle Probleme: Wenn die TK-Anlage bzw. das Telefon nicht sofort RTP-Daten versendet, sind
keine Early-Media-Ansagen zu hören. Wenn die TK-Anlage bzw. das Telefon während einer bestehenden
Verbindung über einen längeren Zeitraum keine RTP-Daten versendet (z.B. bei Sprachpausenerkennung oder Halten), löscht der NAT-Router ggf. den Eintrag aus der Session Table und lässt damit keine
RTP-Daten vom SBC mehr passieren.
Lösung: Port Forwarding für RTP aktivieren.
...oder etwas intelligenter und STUN verwenden !
STUN erspart einem die scheunentorartige Öffnung der Firewall für die gesamte dynamische RTP Range.
STUN erspart einem die scheunentorartige Öffnung der Firewall für die gesamte dynamische RTP Range.
Überleg vielleicht noch mal:
Kenne ich durchaus als Administrationsmethode: Wenn irgendwas nicht geht, einfach alle Rechte freigeben, Firewall abschalten usw., irgendwann geht es dann schon.
Dass das Einzug in die offiziellen Manuals von Vodafone gehalten hat, wenn auch nur als Doppelsternchen, passt irgendwie auch zu Vodafone. Insofern: Immerhin konsequent.
Viele Grüße, commodity
Der SBC erkennt ...
Das ist gleichermaßen technisch richtig, wie fachlich Blödsinn. Letzeres deshalb, weil Du die Firewall völlig unnötig aufreißt. Dies wiederum einzig, weil Du Timeouts und Keepalives nicht konfiguriert hast. In dem Absatz, den Du verlinkt hast, wird das "UDP Hole Punching" genannt. Darauf hat bereits im ersten Antwortpost Kollege @tikayevent hingewiesen. Wenn Du das erste * dort liest, siehst Du auch, dass Du Dir das Öffnen von Ports eingehend komplett ersparen kannst (wie ich oben auch schrieb). Das ** ist nur für Leute, die das partout nicht hinbekommen (und trotzdem telefonieren wollen). Der als "Lösung" bezeichnete TextLösung: Port Forwarding für RTP aktivieren.
bedeutet nichts anderes als die Firewall in diesem Bereich zu deaktivieren. Für mich nicht der Sinn einer Firewall. Schon gar nicht, wenn VOIP dahinter liegt.Kenne ich durchaus als Administrationsmethode: Wenn irgendwas nicht geht, einfach alle Rechte freigeben, Firewall abschalten usw., irgendwann geht es dann schon.
Dass das Einzug in die offiziellen Manuals von Vodafone gehalten hat, wenn auch nur als Doppelsternchen, passt irgendwie auch zu Vodafone. Insofern: Immerhin konsequent.
Viele Grüße, commodity
1
Hallo commodity,
danke für die mitteilung.
Port 5060 tcp/upd und 10000-20000 udp für RTP ist nur für Source-IP-Vodafone-SBC erlaubt.
Gibt es ein Security-Fachausdruck, wenn ein externer Angreifer mit der Vodafone SBC-IP versuchen würde zu verbinden? (attacking via false-flag-IP-HOST Source-camouflaged as whitelist-member")
Würde behaupten: beim Troubleshouting ist das temporäre öffnen der Ports für bestimmte Sources im Rahmen des Eliminationsverfahren keine so schlechte Methode, weil es sonst nicht so viele Möglichkeiten übrigbleiben und wenn keiner der Beteiligten eine bessere Idee hat.
Ja danke - ich werde das nochmal suchen in Watchguard + Asterisk.
Fakt ist, dass Vodafone Techniker + Asterisk Techniker
NAT-Timeout und NAT-Keepalive nicht erwähnt haben und ich beide auch noch nicht drauf ansprechen konnte.
danke für die mitteilung.
Port 5060 tcp/upd und 10000-20000 udp für RTP ist nur für Source-IP-Vodafone-SBC erlaubt.
Gibt es ein Security-Fachausdruck, wenn ein externer Angreifer mit der Vodafone SBC-IP versuchen würde zu verbinden? (attacking via false-flag-IP-HOST Source-camouflaged as whitelist-member")
Würde behaupten: beim Troubleshouting ist das temporäre öffnen der Ports für bestimmte Sources im Rahmen des Eliminationsverfahren keine so schlechte Methode, weil es sonst nicht so viele Möglichkeiten übrigbleiben und wenn keiner der Beteiligten eine bessere Idee hat.
Schau mal, ob das NAT-Timeout geringer ist als das NAT-Keepalive, welches der SIP-Provider ausweist und welches in >deiner Telefonanlage konfiguriert ist.
Ja danke - ich werde das nochmal suchen in Watchguard + Asterisk.
Fakt ist, dass Vodafone Techniker + Asterisk Techniker
NAT-Timeout und NAT-Keepalive nicht erwähnt haben und ich beide auch noch nicht drauf ansprechen konnte.
Hi Manu,
Wenn Du das auf die IP des Providers festzurrst, geht das schon. Du wirst nur wenig Spaß haben, denn die Provider ändern auch hin und wieder die Adressen. Dann setzt das Telefon aus und Du wirst wieder lange suchen.
Leider wird in der IT zu wenig gelesen. Schon das Standardwerk Asterisk - The Future Of Telephony stellt unmissverständlich klar, dass Asterisk keinerlei Ports von außen benötigt (die Seite suche ich jetzt nicht raus, sorry).
Viele Grüße, commodity
im Rahmen des Eliminationsverfahren(s)
dafür kann man das natürlich mal machen. Ansonsten aber tunlichst vermeiden. Das als Handbuchlösung ist geradezu eine Einladung für Hacker.Wenn Du das auf die IP des Providers festzurrst, geht das schon. Du wirst nur wenig Spaß haben, denn die Provider ändern auch hin und wieder die Adressen. Dann setzt das Telefon aus und Du wirst wieder lange suchen.
Fakt ist, dass Vodafone Techniker + Asterisk Techniker NAT-Timeout und NAT-Keepalive nicht erwähnt haben
Das wundert bei Vodafone überhaupt nicht. Wer war denn der vermeintliche "Asterisk-Techniker"? BinTec, AnsiTel? Das war sicherlich ebenfalls mies bezahlter und überlasteter 1st level support, da darfst Du leider gar nichts erwarten. Wie sonst auch.Leider wird in der IT zu wenig gelesen. Schon das Standardwerk Asterisk - The Future Of Telephony stellt unmissverständlich klar, dass Asterisk keinerlei Ports von außen benötigt (die Seite suche ich jetzt nicht raus, sorry).
Viele Grüße, commodity
