alexander90
Goto Top

PfSense VOIP inbound nicht möglich - Firewall blockt die Anfrage weg

Hallo zusammen,

da ich bislang keine Lösung im pfSense-Forum gefunden habe und wir endlich wieder telefonieren wollen, stelle ich die Frage bei euch nochmal:

ich hab ein technisches Problem 🙁 und bin verzweifelt. Sind vor 1 Woche auf O2 gewechselt und seit dem funktionieren die eingehenden Telefonate nicht mehr.
Genaues Fehlerbild: Beim Anrufenden klingelt es einmal, danach ist sofort besetzt. In den Logs der Fritzbox wird kein eingehender Anruf registriert. Lasse ich die Fritzbox komplett ausgeschaltet, so klingelt es beim Anrufenden nichtmal einmal, sondern es kommt die Ansage, dass der Teilnehmer zur Zeit nicht erreichbar ist. => Das deutet darauf hin, dass die Verbindung schon irgendwie zustande kommt. Ausgehende Anrufe funktionieren ja auch normal inkl. Sprache.

Mein Aufbau ist: ISP (O2) => Modem => Firewall (pfSense 10.4.4.1)=> Telefonalage (Fritzbox 10.4.4.2)

Hatte zunächst O2 im Verdacht, aber wenn ich die Fritzbox als All-in-One-Lösung einsetze funktioniert alles. Ich denke also es liegt eine Fehlkonfiguration in der Firewall vor.
Dass O2 hier ein wenig speziell ist habe ich schon gemerkt, da ich den O2 DNS-Server einsetzen musste um überhaupt eine Anmeldung in der Fritzbox zu realisieren...
Aber dieses Problem lässt sich auch nach allen Konfigurationsmöglichkeiten die ich im Internet gefunden habe nicht lösen.
Das komische ist: Mit 1und1 ging alles mit dieser (bzw. noch weiter reduzierter) Konfiguration ohne Probleme.

Anbei meine Konfiguration.
pfSense läuft auf einer Proxmox vm. Hardware Intel(R) Pentium(R) Silver J5005 CPU @ 1.50GHz

eine NIC onboard (LAN) und eine per USB (WAN)...


Edit: Sorry es war etwas unübersichtlich...

Jetzt nochmal: bei 1und1 musste ich nur diese beiden Einstellungen vornehmen:

Der Fritzbox sagen, dass Sie die Ports offen halten soll, welche benötigt werden:
rufnummer innerhalb fritzbox detail 3


Der pfSense sagen, dass der Port "static" sein soll.
outbound nat

Danach war eigentlich alles tutti...

Mit O2 ist das irgendwie nicht so. Deshalb habe ich schon alle mögliche probiert... Z.B. ein Port-Forwarding von Port 5060 auf die Fritzbox.
port forward
wan rule
Dieser Port müsste zwar eigentlich eh schon offen sein, da die Fritzbox diesen ja offen halten soll, aber nunja...

Dann kommt das für mich nicht nachvollziehbare: der log wenn ich von extern anrufe sagt, dass Port 5060 geblockt wird. WARUM?
logs bei anruf von extern inbound

Hier der Port-Alias:
port alias

Dazu habe ich dann ein Paket Capture gemacht um die Dateils zu sehen. Da kann ich leider mangels Erfahrung nichts dran ableiten:

Paket Capture :
(Hab meine Ip durch 93.133.ano.nym ersetzt und die telefonummern auch teilweise durch anonym ersetzt...)

13:29:53.710230 AF IPv4 (2), length 1304: (tos 0x68, ttl 249, id 43011, offset 0, flags [+], proto UDP (17), length 1300)
    195.71.31.3.5060 > 93.133.ano.nym.5060: SIP, length: 1272
	INVITE sip:4952anonym1@93.133.ano.nym;uniq=DAA0D47233091949044DB3A222A8D SIP/2.0
	Max-Forwards: 68
	Via: SIP/2.0/UDP 195.71.31.3:5060;branch=z9hG4bKg3Zqkv7i4xyc82j58r592hnqpdfd61rv4
	To: "4952anonym1 VoIP" <sip:4952anonym1@sip.alice-voip.de>  
	From: "01anonym5589" <sip:01anonym5589@sip.alice-voip.de;user=phone>;tag=h7g4Esbg_1143711707-1548592193649-  
	Call-ID: BW1329536492701191048261448@10.30.224.184
	CSeq: 128241721 INVITE
	Contact: <sip:sgc_c@195.71.31.3;transport=udp>
	Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"  
	Min-Se: 900
	P-Asserted-Identity: "+491anonym5589" <sip:01anonym5589@ims.telefonica.de;user=phone>  
	P-Called-Party-ID: <sip:4952anonym1@sip.alice-voip.de>
	Privacy: none
	Session-Expires: 1800;refresher=uac
	Supported: timer
	Content-Type: application/sdp
	Content-Disposition: session;handling=required
	Content-Length: 409
	Recv-Info: x-broadworks-client-session-info
	Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REFER, NOTIFY, UPDATE
	Accept: application/dtmf-relay
	Accept: application/media_control+xml
	Accept: application/sdp
	Accept: multipart/mixed
	
	v=0
	o=BroadWorks 60562463 1 IN IP4 195.71.31.3
	s=-
	c=IN IP4 62.52.129.138
	t=0 0
	m=audio 36456 RTP/AVP 100 101 8 103
	b=AS:80
	a=rtpmap:[!sip]
13:29:54.213143 AF IPv4 (2), length 1304: (tos 0x68, ttl 249, id 43012, offset 0, flags [+], proto UDP (17), length 1300)
    195.71.31.3.5060 > 93.133.ano.nym.5060: SIP, length: 1272
	INVITE sip:4952anonym1@93.133.ano.nym;uniq=DAA0D47233091949044DB3A222A8D SIP/2.0
	Max-Forwards: 68
	Via: SIP/2.0/UDP 195.71.31.3:5060;branch=z9hG4bKg3Zqkv7i4xyc82j58r592hnqpdfd61rv4
	To: "4952anonym1 VoIP" <sip:4952anonym1@sip.alice-voip.de>  
	From: "01anonym5589" <sip:01anonym5589@sip.alice-voip.de;user=phone>;tag=h7g4Esbg_1143711707-1548592193649-  
	Call-ID: BW1329536492701191048261448@10.30.224.184
	CSeq: 128241721 INVITE
	Contact: <sip:sgc_c@195.71.31.3;transport=udp>
	Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"  
	Min-Se: 900
	P-Asserted-Identity: "+491anonym5589" <sip:01anonym5589@ims.telefonica.de;user=phone>  
	P-Called-Party-ID: <sip:4952anonym1@sip.alice-voip.de>
	Privacy: none
	Session-Expires: 1800;refresher=uac
	Supported: timer
	Content-Type: application/sdp
	Content-Disposition: session;handling=required
	Content-Length: 409
	Recv-Info: x-broadworks-client-session-info
	Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REFER, NOTIFY, UPDATE
	Accept: application/dtmf-relay
	Accept: application/media_control+xml
	Accept: application/sdp
	Accept: multipart/mixed
	
	v=0
	o=BroadWorks 60562463 1 IN IP4 195.71.31.3
	s=-
	c=IN IP4 62.52.129.138
	t=0 0
	m=audio 36456 RTP/AVP 100 101 8 103
	b=AS:80
	a=rtpmap:[!sip]
13:29:55.215161 AF IPv4 (2), length 1304: (tos 0x68, ttl 249, id 43013, offset 0, flags [+], proto UDP (17), length 1300)
    195.71.31.3.5060 > 93.133.ano.nym.5060: SIP, length: 1272
	INVITE sip:4952anonym1@93.133.ano.nym;uniq=DAA0D47233091949044DB3A222A8D SIP/2.0
	Max-Forwards: 68
	Via: SIP/2.0/UDP 195.71.31.3:5060;branch=z9hG4bKg3Zqkv7i4xyc82j58r592hnqpdfd61rv4
	To: "4952anonym1 VoIP" <sip:4952anonym1@sip.alice-voip.de>  
	From: "01anonym5589" <sip:01anonym5589@sip.alice-voip.de;user=phone>;tag=h7g4Esbg_1143711707-1548592193649-  
	Call-ID: BW1329536492701191048261448@10.30.224.184
	CSeq: 128241721 INVITE
	Contact: <sip:sgc_c@195.71.31.3;transport=udp>
	Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"  
	Min-Se: 900
	P-Asserted-Identity: "+491anonym5589" <sip:01anonym5589@ims.telefonica.de;user=phone>  
	P-Called-Party-ID: <sip:4952anonym1@sip.alice-voip.de>
	Privacy: none
	Session-Expires: 1800;refresher=uac
	Supported: timer
	Content-Type: application/sdp
	Content-Disposition: session;handling=required
	Content-Length: 409
	Recv-Info: x-broadworks-client-session-info
	Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REFER, NOTIFY, UPDATE
	Accept: application/dtmf-relay
	Accept: application/media_control+xml
	Accept: application/sdp
	Accept: multipart/mixed
	
	v=0
	o=BroadWorks 60562463 1 IN IP4 195.71.31.3
	s=-
	c=IN IP4 62.52.129.138
	t=0 0
	m=audio 36456 RTP/AVP 100 101 8 103
	b=AS:80
	a=rtpmap:[!sip]
13:29:57.216897 AF IPv4 (2), length 1304: (tos 0x68, ttl 249, id 43014, offset 0, flags [+], proto UDP (17), length 1300)
    195.71.31.3.5060 > 93.133.ano.nym.5060: SIP, length: 1272
	INVITE sip:4952anonym1@93.133.ano.nym;uniq=DAA0D47233091949044DB3A222A8D SIP/2.0
	Max-Forwards: 68
	Via: SIP/2.0/UDP 195.71.31.3:5060;branch=z9hG4bKg3Zqkv7i4xyc82j58r592hnqpdfd61rv4
	To: "4952anonym1 VoIP" <sip:4952anonym1@sip.alice-voip.de>  
	From: "01anonym5589" <sip:01anonym5589@sip.alice-voip.de;user=phone>;tag=h7g4Esbg_1143711707-1548592193649-  
	Call-ID: BW1329536492701191048261448@10.30.224.184
	CSeq: 128241721 INVITE
	Contact: <sip:sgc_c@195.71.31.3;transport=udp>
	Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"  
	Min-Se: 900
	P-Asserted-Identity: "+491anonym5589" <sip:01anonym5589@ims.telefonica.de;user=phone>  
	P-Called-Party-ID: <sip:4952anonym1@sip.alice-voip.de>
	Privacy: none
	Session-Expires: 1800;refresher=uac
	Supported: timer
	Content-Type: application/sdp
	Content-Disposition: session;handling=required
	Content-Length: 409
	Recv-Info: x-broadworks-client-session-info
	Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REFER, NOTIFY, UPDATE
	Accept: application/dtmf-relay
	Accept: application/media_control+xml
	Accept: application/sdp
	Accept: multipart/mixed
	
	v=0
	o=BroadWorks 60562463 1 IN IP4 195.71.31.3
	s=-
	c=IN IP4 62.52.129.138
	t=0 0
	m=audio 36456 RTP/AVP 100 101 8 103
	b=AS:80
	a=rtpmap:[!sip]
13:30:01.218983 AF IPv4 (2), length 1304: (tos 0x68, ttl 249, id 43015, offset 0, flags [+], proto UDP (17), length 1300)
    195.71.31.3.5060 > 93.133.ano.nym.5060: SIP, length: 1272
	INVITE sip:4952anonym1@93.133.ano.nym;uniq=DAA0D47233091949044DB3A222A8D SIP/2.0
	Max-Forwards: 68
	Via: SIP/2.0/UDP 195.71.31.3:5060;branch=z9hG4bKg3Zqkv7i4xyc82j58r592hnqpdfd61rv4
	To: "4952anonym1 VoIP" <sip:4952anonym1@sip.alice-voip.de>  
	From: "01anonym5589" <sip:01anonym5589@sip.alice-voip.de;user=phone>;tag=h7g4Esbg_1143711707-1548592193649-  
	Call-ID: BW1329536492701191048261448@10.30.224.184
	CSeq: 128241721 INVITE
	Contact: <sip:sgc_c@195.71.31.3;transport=udp>
	Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"  
	Min-Se: 900
	P-Asserted-Identity: "+491anonym5589" <sip:01anonym5589@ims.telefonica.de;user=phone>  
	P-Called-Party-ID: <sip:4952anonym1@sip.alice-voip.de>
	Privacy: none
	Session-Expires: 1800;refresher=uac
	Supported: timer
	Content-Type: application/sdp
	Content-Disposition: session;handling=required
	Content-Length: 409
	Recv-Info: x-broadworks-client-session-info
	Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REFER, NOTIFY, UPDATE
	Accept: application/dtmf-relay
	Accept: application/media_control+xml
	Accept: application/sdp
	Accept: multipart/mixed
	
	v=0
	o=BroadWorks 60562463 1 IN IP4 195.71.31.3
	s=-
	c=IN IP4 62.52.129.138
	t=0 0
	m=audio 36456 RTP/AVP 100 101 8 103
	b=AS:80
	a=rtpmap:[!sip]

Wenn ich die Paket Capture auf "normal" stelle kommt der Fehler:
"13:38:56.950120 IP 195.71.31.3.5060 > 93.133.ano.nym.5060: UDP, bad length 1880 > 1272"  


Komisch ist, dass andere Port-Forwards normal funktionieren. Wie z.B. Nextcloud:

nextcloud

Anbei noch die restlichen Screenshots für die Details:
fritzbox 10.4.4.2
rufnummer innerhalb fritzbox detail
interfaces
rufnummer innerhalb fritzbox detail 2
2019-01-27_14-50-42
wan modem

Content-ID: 399697

Url: https://administrator.de/contentid/399697

Ausgedruckt am: 25.11.2024 um 18:11 Uhr

Deepsys
Deepsys 28.01.2019 aktualisiert um 21:19:58 Uhr
Goto Top
Hallo,

es ganz blicke ich bei deinen ganzen Shots nicht durch, erstmal die Frage warum überhaupt die Firewall vor Fritzbox?
Was hängt da noch dran?
Wenn es da nichts anderes gibt, lass die Firewall einfach weg.
Hast du ja selber beschrieben, dann geht es.

Ich bezweifle das es so irgendwie sicherer ist.

Und warum werden alle Pakete auf Port 5060 geblockt?
Das ist einer der SIP-Ports!

https://de.wikipedia.org/wiki/Session_Initiation_Protocol

Danach kommt noch RTP zum Einsatz, und das musst du auch recht weit öffnen.

VG,
deepsys
Deepsys
Deepsys 28.01.2019 um 21:25:59 Uhr
Goto Top
Ah, OK, jetzt verstehe ich es besser.
Den Portblock 5060 hast du auch schon bemerkt,
weißt nur nicht warum der geblockt wird?

Kann das sein?

Dann bitte mal alle Filterregeln, vor allen die "Default Deny Rule".
ChriBo
ChriBo 28.01.2019 um 22:01:26 Uhr
Goto Top
Hi,
änder mal in deinen Einstellungen TCP/UDP für SIP und RTP in UDP.
Sowohl i der Regel als auch in der NAT Einstellung.
Ebenso aktiviere logging in der Regel

CH
Alexander90
Alexander90 28.01.2019 aktualisiert um 22:19:59 Uhr
Goto Top
@ChriBo: Habe ich gerade mal gemacht. Keine Änderung. Es wird geblockt und die Rule wird nicht gezogen.
log block
port forward
wan rule


@Deepsys: Du hast recht es war sehr undurchsichtig. Ich habe es editiert...

Ja genau warum wird 5060 geblockt. Die regeln sind alle vor der Block any Rule und z.B. Nextcloud funktioniert ja auch (siehe oben)...
ticboo
ticboo 28.01.2019 um 22:38:03 Uhr
Goto Top
Laut den Protokol soll der RTP Ports zwischen 16384 - 32767 verwenden.

Grüß
ChriBo
ChriBo 29.01.2019 um 07:46:42 Uhr
Goto Top
Hallo,
das Einzige was mir noch einfällt:
"13:38:56.950120 IP 195.71.31.3.5060 > 93.133.ano.nym.5060: UDP, bad length 1880 > 1272"
und
pfSense läuft auf einer Proxmox vm
Kann es ein "Fehler" in der Konfiguration der virtuellen Netzwerkkarte bzw. dem virtuellen Switch sein ?
Ich kenne mich mit Proxmox nicht aus, kanndir da also nicht weiterhelfen.

CH
Looser27
Looser27 29.01.2019 um 08:49:39 Uhr
Goto Top
Moin,

ich hatte mal ein ähnlich gelagertes Problem mit einer älteren Version von pfSense.
Mit der aktuellen Version habe ich NICHTS mehr eingestellt. Weder Port Forwarding, noch Outbound NAT.
Und die Telefonie läuft trotzdem einwandfrei. Lediglich ausgehend habe ich in der Firewall die Ports TCP/UDP 5060 und UDP 1-65535 freigegeben.
Nichts anderes macht übrigens die Fritzbox. Ausgehend ist bei der alles offen.
BTW....stimmen denn Deine Netzwerkeinstellungen der Fritzbox inkl. korrektem DNS?

Gruß

Looser
Alexander90
Alexander90 30.01.2019 um 08:13:38 Uhr
Goto Top
Jetzt läuft es! Die Einstellung an der es lag: KEIN Harken gesetzt bei "Disable scrub" unter System -> Advanced -> Firewall & NAT

Wahnsinn was mich dieser Harken an Zeit gekostet hat. Unglaublich. Danke euch für die Unterstützung!!!
ChriBo
ChriBo 30.01.2019 um 20:06:01 Uhr
Goto Top
Dumme Frage: Wie bist du darauf gekommen ?

CH
Alexander90
Alexander90 31.01.2019 um 18:43:52 Uhr
Goto Top
Hier ganz unten hatte es jemand gepostet:
https://forum.netgate.com/topic/106986/howto-telekom-voip-einstellungen

Ich hatte dies nur leider erst so gelesen, dass man den harken setzen soll....

Da ich aber dann irgendwann alles doppelt durchgelesen habe, habe ich es richtig gelesen...