netgear24
Jan 10, 2014, updated at Jan 12, 2014 (UTC)
view7063
view19
0
Goto Top

FreePBX hinter PFSense

GermansolvedQuestionVoice over IPNetworks
Hallo Zusammen

Habe ein kleines Problem. Aber zuerst möchte ich euch einen Groben überblick über mein Netzwerk verschaffen.

Kabelmodem <-> PFSense <-> Switch <-> FreePBX (192.168.179.45)
^-> Alle anderen Rechner

Nun mein Problem

Ich habe auf der Firewall folgende Ports auf die FreePBX Freigegeben.

UDP 5060 - 5062
UDP 5004 - 5004
UDP 10000 - 20000

Trotzdem können sich externe Nebenstellen die über die Feste WAN IP Adresse Anmelden möchten dies nicht tun. Die PBX ist ein Raspberry PI mit FreePBX drauf. Auf dem SNOM 360 Telefon bekomme ich in den Logs folgendes zu sehen.

(Die xxx.xxx.xxx.xxx entspricht meine IP Adresse)

10/1/2014 14:42:23 [ERROR ] PHN: SIP: transport error: 1000792 -> udp:xxx.xxx.xxx.xxx:5060
10/1/2014 14:42:23 [NOTICE] PHN: SIP: Add dirty host: udp:xxx.xxx.xxx.xxx:5060 (0 sec)
10/1/2014 14:42:23 [NOTICE] PHN: SIP: final transport error: 1000792 -> udp:xxx.xxx.xxx.xxx:5060
10/1/2014 14:42:23 [ERROR ] PHN: SIP: transport error 1000792: generating fake 599
10/1/2014 14:42:23 [ERROR ] PHN: SIP: Registrar 23@xxx.xxx.xxx.xxx timed out
10/1/2014 14:47:11 [ERROR ] PHN: SIP: transaction_timeout udp: 1000794 (32000)
10/1/2014 14:47:11 [ERROR ] PHN: SIP: transport error: 1000794 -> udp:xxx.xxx.xxx.xxx:5060
10/1/2014 14:47:11 [NOTICE] PHN: SIP: Add dirty host: udp:xxx.xxx.xxx.xxx:5060 (0 sec)
10/1/2014 14:47:11 [NOTICE] PHN: SIP: final transport error: 1000794 -> udp:xxx.xxx.xxx.xxx:5060
10/1/2014 14:47:11 [ERROR ] PHN: SIP: transport error 1000794: generating fake 599
10/1/2014 14:47:11 [ERROR ] PHN: SIP: Registrar 23@xxx.xxx.xxx.xxx timed out
10/1/2014 14:51:45 [ERROR ] PHN: SIP: transaction_timeout udp: 1000796 (32000)
10/1/2014 14:51:45 [ERROR ] PHN: SIP: transport error: 1000796 -> udp:xxx.xxx.xxx.xxx:5060
10/1/2014 14:51:45 [NOTICE] PHN: SIP: Add dirty host: udp:xxx.xxx.xxx.xxx:5060 (0 sec)
10/1/2014 14:51:45 [NOTICE] PHN: SIP: final transport error: 1000796 -> udp:xxx.xxx.xxx.xxx:5060
10/1/2014 14:51:45 [ERROR ] PHN: SIP: transport error 1000796: generating fake 599
10/1/2014 14:51:45 [ERROR ] PHN: SIP: Registrar 23@xxx.xxx.xxx.xxx timed out
10/1/2014 14:56:48 [ERROR ] PHN: SIP: transaction_timeout udp: 1000798 (32000)
10/1/2014 14:56:48 [ERROR ] PHN: SIP: transport error: 1000798 -> udp:xxx.xxx.xxx.xxx:5060
10/1/2014 14:56:48 [NOTICE] PHN: SIP: Add dirty host: udp:xxx.xxx.xxx.xxx:5060 (0 sec)
10/1/2014 14:56:48 [NOTICE] PHN: SIP: final transport error: 1000798 -> udp:xxx.xxx.xxx.xxx:5060
10/1/2014 14:56:48 [ERROR ] PHN: SIP: transport error 1000798: generating fake 599
10/1/2014 14:56:48 [ERROR ] PHN: SIP: Registrar 23@xxx.xxx.xxx.xxx timed out

Auf der PBX keine Aktivität

Bin für jede Hilfe dankbar.

Grüsse aus der Schweiz
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 226330

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

Printed on: April 18, 2024 at 20:04 o'clock

19 Comments
Latest comment
Goto Top
Member: aqui
aqui Jan 10, 2014 updated at 14:16:45 (UTC)
Goto Top
SIP kann UDP 5060 bis 5064 benutzen das solltest du also ggf. etwas erweitern !
Vermutlich liegt es aber gar nicht an dir sondern an den "Nebenstellen". Arbeiten diese hinter einer NAT Firewall sprich einen simplen NAT Router ?
Der muss nämlich auch entsprechend angepasst werden damit die Clients eine SIP Connection aufbauen können auf deine PBX !
Bezeichnend ist nämlich die Meldung "[ERROR ] PHN: SIP: transaction_timeout udp: 1000794 (32000)" die besagt das die SIP Session austimed.
Das ist immer ein sicheres Indiz das SIP irgendwo gar nicht ankommt !

Installier dir mal mit apt-get install tcpdump tcpdump auf dem RasPi und checke mal ob die SIP Session der "Nebenstellen" dort überhaupt ankommt !!
Irgendwo bleibt das stecken.

Das "Kabelmodem" ist auch wirklich ein Kabelmodem und KEIN Router ?? D.h. die öffentliche Provider IP die du ansprichst ist de facto am WAN Port der pfSense ??
Member: Netgear24
Netgear24 Jan 10, 2014 at 14:42:18 (UTC)
Goto Top
Habe den Portbereich nun auf 5060 - 5064 angepasst. Die Nebenstellen arbeiten hinter einer FritzBox 7390. Auszug mit TCPDump (wiederholt sich immer dassselbe). Wobei mein Computer die 60 und die PBX die 45 hat. Andere SIP Accounts auf den Telefonen funktionieren hervorragend.

15:30:27.501978 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4372848:4373040, ack 64161, win 730, length 192
15:30:27.503027 IP 192.168.179.60.52514 > 192.168.179.45.ssh: Flags [.], ack 4372848, win 253, length 0
15:30:27.503751 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4373040:4373232, ack 64161, win 730, length 192
15:30:27.504161 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4373232:4373392, ack 64161, win 730, length 160
15:30:27.505179 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4373392:4373696, ack 64161, win 730, length 304
15:30:27.505506 IP 192.168.179.60.52514 > 192.168.179.45.ssh: Flags [.], ack 4373232, win 252, length 0
15:30:27.506566 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4373696:4373984, ack 64161, win 730, length 288
15:30:27.506906 IP 192.168.179.60.52514 > 192.168.179.45.ssh: Flags [.], ack 4373696, win 256, length 0
15:30:27.507823 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4373984:4374272, ack 64161, win 730, length 288
15:30:27.508691 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4374272:4374464, ack 64161, win 730, length 192
15:30:27.509524 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4374464:4374656, ack 64161, win 730, length 192
15:30:27.509937 IP 192.168.179.60.52514 > 192.168.179.45.ssh: Flags [.], ack 4374272, win 254, length 0
15:30:27.509942 IP 192.168.179.60.52514 > 192.168.179.45.ssh: Flags [P.], seq 64161:64257, ack 4374272, win 254, length 96
15:30:27.509944 IP 192.168.179.60.52514 > 192.168.179.45.ssh: Flags [P.], seq 64257:64321, ack 4374272, win 254, length 64
15:30:27.511138 IP 192.168.179.60.52514 > 192.168.179.45.ssh: Flags [.], ack 4374656, win 252, length 0
15:30:27.511441 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [.], ack 64321, win 730, length 0
15:30:27.512031 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4374656:4375248, ack 64321, win 730, length 592
15:30:27.513238 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4375248:4375648, ack 64321, win 730, length 400
15:30:27.514077 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4375648:4375840, ack 64321, win 730, length 192
15:30:27.514911 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4375840:4376032, ack 64321, win 730, length 192
15:30:27.515197 IP 192.168.179.60.52514 > 192.168.179.45.ssh: Flags [.], ack 4375648, win 256, length 0
15:30:27.516302 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4376032:4376320, ack 64321, win 730, length 288
15:30:27.516883 IP 192.168.179.60.52514 > 192.168.179.45.ssh: Flags [.], ack 4376032, win 255, length 0
15:30:27.517674 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4376320:4376608, ack 64321, win 730, length 288
15:30:27.518562 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4376608:4376800, ack 64321, win 730, length 192
15:30:27.519396 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4376800:4376992, ack 64321, win 730, length 192
15:30:27.519909 IP 192.168.179.60.52514 > 192.168.179.45.ssh: Flags [.], ack 4376608, win 252, length 0
15:30:27.521077 IP 192.168.179.60.52514 > 192.168.179.45.ssh: Flags [.], ack 4376992, win 251, length 0
15:30:27.521900 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4376992:4377280, ack 64321, win 730, length 288
15:30:27.522450 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4377280:4377440, ack 64321, win 730, length 160
15:30:27.523502 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4377440:4377744, ack 64321, win 730, length 304
15:30:27.524144 IP 192.168.179.60.52514 > 192.168.179.45.ssh: Flags [.], ack 4377440, win 256, length 0
15:30:27.524927 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4377744:4378032, ack 64321, win 730, length 288
15:30:27.525761 IP 192.168.179.45.ssh > 192.168.179.60.52514: Flags [P.], seq 4378032:4378224, ack 64321, win 730, length 192

Das Kabelmodem ist ein Komplettes Modem ohne Routing oder ähnlichen Funktionen. Also Antennenkabel rein, Ethernet raus. Die öffentliche IP Adresse ist somit auf der PFSense. Andere Portweiterleitungen funktionieren Einwandfrei. In den Logs von den Nebenstellen wieder dasselbe Spiel
Member: aqui
aqui Jan 10, 2014 updated at 15:10:27 (UTC)
Goto Top
Wir wollen hier NICHT die mitgesnifferte SSH Session deines Rechners sehen !! Das ist wenig zielführend. Bitte exclude in tcpdump deine src und dst IP Adresse des SSH PCs !!!
Dann können und wollen wir auch deinen tcpdump Trace ansehen !
tcpdump not src <eigene_IP> and not dst <eigene_IP>
Blendet deinen eigenen PC Traffic aus !!
Soviel vorweg: Du kannst oben schon sehen das dort keinerlei SIP Traffic ankommt.
Member: Netgear24
Netgear24 Jan 10, 2014 at 15:11:13 (UTC)
Goto Top
Sorry habe wohl die Falschen Daten rausgeschnitten. Hier Nochmals. SIP Traffic ist nicht vorhanden. Nur netbios und ein paar Broadcasts. Habe während dem Mitschnitt die Telefone Extern nochmals Versucht zu Registrieren.

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:07:27.197915 IP 192.168.179.60.59902 > 224.0.0.252.hostmon: UDP, length 33
16:07:27.232489 IP 192.168.179.60.56082 > 224.0.0.252.hostmon: UDP, length 33
16:07:33.577773 IP 192.168.179.60.17500 > 255.255.255.255.17500: UDP, length 158
16:07:33.578823 IP 192.168.179.60.17500 > 255.255.255.255.17500: UDP, length 158
16:07:33.578827 IP 192.168.179.60.17500 > 192.168.179.255.17500: UDP, length 158
16:07:33.579103 IP 192.168.179.60.17500 > 255.255.255.255.17500: UDP, length 158
16:07:57.241507 IP 192.168.179.60.64649 > 224.0.0.252.hostmon: UDP, length 33
16:07:57.276315 IP 192.168.179.60.61769 > 224.0.0.252.hostmon: UDP, length 33
16:08:00.114792 ARP, Request who-has 192.168.179.206 tell 192.168.179.60, length 46
16:08:00.289715 ARP, Request who-has 192.168.179.60 tell 192.168.179.206, length 46
16:08:01.791352 ARP, Request who-has 192.168.179.45 (b8:27:eb:de:8b:16 (oui Unknown)) tell 192.168.179.60, length 46
16:08:01.791453 ARP, Reply 192.168.179.45 is-at b8:27:eb:de:8b:16 (oui Unknown), length 28
16:08:03.541277 IP 192.168.179.60.17500 > 255.255.255.255.17500: UDP, length 158
16:08:03.542370 IP 192.168.179.60.17500 > 255.255.255.255.17500: UDP, length 158
16:08:03.542392 IP 192.168.179.60.17500 > 192.168.179.255.17500: UDP, length 158
16:08:03.542691 IP 192.168.179.60.17500 > 255.255.255.255.17500: UDP, length 158
16:08:27.283305 IP 192.168.179.60.58875 > 224.0.0.252.hostmon: UDP, length 33
16:08:27.351538 IP 192.168.179.60.64947 > 224.0.0.252.hostmon: UDP, length 33
16:08:32.290915 ARP, Request who-has 192.168.179.60 tell 192.168.179.45, length 28
16:08:32.367978 ARP, Reply 192.168.179.60 is-at 00:27:10:4b:58:50 (oui Unknown), length 46
16:08:33.555217 IP 192.168.179.60.17500 > 255.255.255.255.17500: UDP, length 158
16:08:33.556722 IP 192.168.179.60.17500 > 255.255.255.255.17500: UDP, length 158
16:08:33.556726 IP 192.168.179.60.17500 > 192.168.179.255.17500: UDP, length 158
16:08:33.557015 IP 192.168.179.60.17500 > 255.255.255.255.17500: UDP, length 158
16:08:33.602589 IP 192.168.179.60.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:27:10:4b:58:50 (oui Unknown), length 300
16:08:33.614415 IP 192.168.179.60.netbios-ns > 192.168.179.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
16:08:34.365441 IP 192.168.179.60.netbios-ns > 192.168.179.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
16:08:35.113939 IP 192.168.179.60.netbios-ns > 192.168.179.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
16:08:45.417971 IP 192.168.179.60.netbios-ns > 192.168.179.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

NAT Problem ?
Member: aqui
aqui Jan 10, 2014 updated at 15:29:06 (UTC)
Goto Top
Ja, da kommt gar kein SIP an...das siehst du ja selber. Bischen Multicast und Samba rennt noch bei dir. face-wink

Du kannst mit "and dst port 5060" am tcpdump Kommando noch ganz dediziert nur auf SIP Packets die an UDP 5060 gehen suchen, damit blendest du den ganzen anderen Mist auch noch aus der nicht VoIP related ist !
tcpdump not src <eigene_IP> and not dst <eigene_IP> and dst port 5060
oder
tcpdump not src <eigene_IP> and not dst <eigene_IP> and portrange 5060-5064
was alle SIP Ports inkludiert. Relevant ist aber erstmal nur 5060 da das der Standard Port ist.

Das Funktionieren des o.a. tcpdump Kommandos so erstmal querchecken indem du mit einem funktionierenden Telefon mal die PBX kontaktierst, also irgendwo anrufst, um SIP Traffic im tcpdump zu erzeugen.
Da müsste dann jede Menge SIP Daten reinkommen im tcpdump Trace. Der Schalter -v oder -vv macht den Output dann noch detailierter.
Aber erstmal muss überhaupt dort SIP Daten ankommen von extern. Das passiert de facto nicht.
Zuerst also mal in die pfSense Firewall Log sehen, da ist alles gelistet was geblockt ist oder wird.
Irgendwas funktioniert also mit der Port Weiterleitung nicht und hast du falsch konfiguriert. Unter
https://doc.pfsense.org/index.php/Asterisk_VoIP
findets du einen Tip wie die Firewall NAT Regeln einzustellen sind für SIP und VoIP.
Member: Netgear24
Netgear24 Jan 10, 2014 at 15:51:35 (UTC)
Goto Top
TCPdump von der PBX:

root@incrediblepbx:/# tcpdump not src 192.168.179.60 and not dst 192.168.179.69 and portrange 5060-5064
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:42:20.008503 IP 192.168.179.45.sip > 192.168.179.43.1024: SIP, length: 574
16:42:20.027471 IP 192.168.179.43.1024 > 192.168.179.45.sip: SIP, length: 608
16:42:20.808790 IP sip31.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:42:23.491391 IP sip43.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:42:29.149303 IP 192.168.179.58.sip > 192.168.179.45.sip: SIP, length: 763
16:42:29.152828 IP 192.168.179.45.sip > 192.168.179.58.sip: SIP, length: 502
16:42:29.171046 IP 192.168.179.58.sip > 192.168.179.45.sip: SIP, length: 763
16:42:29.181667 IP 192.168.179.45.sip > 192.168.179.58.sip: SIP, length: 574
16:42:29.183638 IP 192.168.179.45.sip > 192.168.179.58.sip: SIP, length: 532
16:42:29.193032 IP 192.168.179.45.sip > 192.168.179.58.sip: SIP, length: 588
16:42:29.208777 IP 192.168.179.58.sip > 192.168.179.45.sip: SIP, length: 475
16:42:29.221008 IP 192.168.179.58.sip > 192.168.179.45.sip: SIP, length: 458
16:42:35.811990 IP sip31.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:42:38.494784 IP sip43.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:42:50.820030 IP sip31.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:42:53.489988 IP sip43.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:43:01.291673 IP 192.168.179.45.sip > sip43.voipgateway.org.sip: SIP, length: 653
16:43:01.327324 IP sip43.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 474
16:43:01.333105 IP 192.168.179.45.sip > sip43.voipgateway.org.sip: SIP, length: 653
16:43:01.371258 IP sip43.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 373
16:43:05.821401 IP sip31.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:43:05.828818 IP 192.168.179.45.sip > sip31.voipgateway.org.sip: SIP, length: 636
16:43:05.846739 IP sip31.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 465
16:43:05.852452 IP 192.168.179.45.sip > sip31.voipgateway.org.sip: SIP, length: 636
16:43:05.893241 IP sip31.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 485
16:43:08.494707 IP sip43.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:43:08.512070 IP 192.168.179.45.sip > sip43.voipgateway.org.sip: SIP, length: 653
16:43:08.548941 IP sip43.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 474
16:43:08.554975 IP 192.168.179.45.sip > sip43.voipgateway.org.sip: SIP, length: 653
16:43:08.604292 IP sip43.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 492
16:43:19.743236 IP 192.168.179.42.sip > 192.168.179.45.sip: SIP, length: 502
16:43:19.746784 IP 192.168.179.45.sip > 192.168.179.42.sip: SIP, length: 565
16:43:19.811903 IP 192.168.179.42.sip > 192.168.179.45.sip: SIP, length: 664
16:43:19.815241 IP 192.168.179.45.sip > 192.168.179.42.sip: SIP, length: 497
16:43:20.029833 IP 192.168.179.45.sip > 192.168.179.43.1024: SIP, length: 574
16:43:20.049631 IP 192.168.179.43.1024 > 192.168.179.45.sip: SIP, length: 608
16:43:20.894148 IP sip31.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:43:23.618344 IP sip43.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:43:29.211571 IP 192.168.179.45.sip > 192.168.179.58.sip: SIP, length: 574
16:43:29.226633 IP 192.168.179.58.sip > 192.168.179.45.sip: SIP, length: 475
16:43:35.898905 IP sip31.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:43:38.604660 IP sip43.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:43:50.902225 IP sip31.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:43:53.614247 IP sip43.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:44:05.897625 IP sip31.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:44:08.601738 IP sip43.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:44:14.194448 IP 192.168.179.58.sip > 192.168.179.45.sip: SIP, length: 763
16:44:14.197971 IP 192.168.179.45.sip > 192.168.179.58.sip: SIP, length: 502
16:44:14.216074 IP 192.168.179.58.sip > 192.168.179.45.sip: SIP, length: 763
16:44:14.227050 IP 192.168.179.45.sip > 192.168.179.58.sip: SIP, length: 574
16:44:14.233158 IP 192.168.179.45.sip > 192.168.179.58.sip: SIP, length: 532
16:44:14.236417 IP 192.168.179.45.sip > 192.168.179.58.sip: SIP, length: 588
16:44:14.258008 IP 192.168.179.58.sip > 192.168.179.45.sip: SIP, length: 475
16:44:14.266802 IP 192.168.179.58.sip > 192.168.179.45.sip: SIP, length: 458
16:44:20.053465 IP 192.168.179.45.sip > 192.168.179.43.1024: SIP, length: 574
16:44:20.072395 IP 192.168.179.43.1024 > 192.168.179.45.sip: SIP, length: 608
16:44:20.908484 IP sip31.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4
16:44:23.599581 IP sip43.voipgateway.org.sip > 192.168.179.45.sip: SIP, length: 4

Wenn ich in der PFSense nach der Source IP Suche, bekomme ich kein einziges Ergebniss.
Mitglied: 108012
108012 Jan 10, 2014 at 16:19:50 (UTC)
Goto Top
Hallo,

ich schließe mich @aqui an, zu 80% ist das berühmte Kabelmodem ein echter Router der ebenso
wie die pfSense auch NAT & SPI macht und somit hat man dann eine Routerkaskade aufgesetzt die
dann das Vorhaben erst einmal scheitern lässt.

Bei PBX und VOIP Appliances wie auch Asterisk eine ist, empfiehlt es sich, eben diese in einer DMZ
Laufen zu lassen und nur zu dieser DMZ die Ports zu öffnen und das LAN gesondert davon zu betreiben.

Zum einen ist der öffentliche Zugang zum Router respektive dem Netzwerk von restlichen Netzwerk (LAN)
so getrennt und man muss nicht mit einem STUN Server arbeiten!

Hier im Forum hat der Bnutzer @aqui auch eine Anleitung dazu geschrieben wie man auf der pfSense
schnell eine DMZ einrichtet, die muss man dann nur noch abtippen und gegebenenfalls abändern.

Gruß
Dobby
Member: Netgear24
Netgear24 Jan 10, 2014 at 16:29:21 (UTC)
Goto Top
Hmm. Werde die Anleitung mal durchgehen. Das Modem ist ein nur ein Modem. Ich Vertreibe diese Dinger für unseren Kabelnetzbetreiber (werde wohl wissen was ich da Vertreibe). Es ist übrigens ein Arris TM092. Ausser ich Täusche mich :D
Mitglied: 108012
108012 Jan 10, 2014 at 16:36:42 (UTC)
Goto Top
Hallo nochmal,

Hmm. Werde die Anleitung mal durchgehen.
Klick auf seinen Namen und dann auf den Karteireiter "Wissen" dort solltest Du fündig werden!

Das Modem ist ein nur ein Modem. Ich Vertreibe diese Dinger für unseren Kabelnetzbetreiber (werde wohl wissen
was ich da Vertreibe).
Das war nicht böse oder gegen Dich gemeint, aber die Tatsache das eine doppelte NAT Einstellung zum
anderen nun auch nichts durchlässt und Du ja augenscheinlich einen Fehler hast war das nur noch einmal
um Dich dazu zu bewegen, dass Du noch einmal schnell drauf guckst auf das Modem.

Denn der Umkehrschluss wäre, dass wir hier raten können was wir wollen und Du an Ports öffnen kannst
was Du willst und es wird einfach nicht funktionieren.

Gruß
Dobby
heart1
Member: Pjordorf
Pjordorf Jan 11, 2014 at 01:15:17 (UTC)
Goto Top
Hallo,

Zitat von @Netgear24:
Es ist übrigens ein Arris TM092.
Jenes hier http://www.arrisi.com/product_catalog/_docs/_specsheet/TM902_PF_16DEC10 ... ? oder meinst du tatsächlich ein anderes?

Das hat doch schon deine Telefone drin.

Gruß,
Peter
Member: Netgear24
Netgear24 Jan 11, 2014 at 01:41:30 (UTC)
Goto Top
Guten Morgen

Ja genau dieses habe ich im Einsatz bei mir. Jedoch habe ich nur Internet darüber laufen. Telefon haben wir in der Familie seit ca 2 Jahren nicht mehr, haben ja alle Handy Abos. :D
Habe mittlerweile die Vermutung das der Netzbetreiber am anderen Ende die VOIP Telefonie blockt und ich daher keine Verbindung bekomme. Habe am anderen Standort kurzerhand einen anderen VOIP Server in Betrieb genommen und von mir aus probiert. Ohne Ergebniss. Werde es morgen mal mit einem VPN Versuchen.

Gute Nacht allerseits
Mitglied: 108012
108012 Jan 11, 2014 at 02:14:32 (UTC)
Goto Top
Hallo nochmal,

ich habe mir das Modem einmal angesehen und die Telefonie ist ja nun vor der Firewall
(pfSense) sowie die Telefone eigentlich auch also von da her sollte es schon funktionieren.
Aber nur über die beiden Buchsen dort am Modem so wie ich das sehe

So und nun können wir uns weiter heran pirschen:
Internet - Modem - pfSense - FreePBX - SNOM 360 Telefon

Wie schon gesagt das Telefon gehört meiner Meinung nach direkt an das Modem dran.
Die FreePBX Appliance hinter der pfSense wird durch NAT blockiert und man kann nicht
angerufen werden, es sei denn man hat die PBX in der DMZ stehen und hat dort ein paar
Ports geöffnet damit das dann alles richtig funktioniert oder Du nutzt einen STUN Server
wenn Du keine DMZ einrichten möchtest.

Gruß
Dobby
Member: Pjordorf
Pjordorf Jan 11, 2014 updated at 02:24:03 (UTC)
Goto Top
Hallo,

Zitat von @Netgear24:
Ja genau dieses habe ich im Einsatz bei mir.
Entschuldige bitte, aber du hast weder eine Ahnung noch weisst du was du Vertreibst.

Ich Zittiere:
Das Modem ist ein nur ein Modem. Ich Vertreibe diese Dinger für unseren Kabelnetzbetreiber (werde wohl wissen was ich da Vertreibe)
Jedoch habe ich nur Internet darüber laufen. Telefon haben wir in der Familie seit ca 2 Jahren nicht mehr, haben ja alle Handy Abos. :D
Und was meinst du denn wie das Dingens was du da hast dort Telefonie macht? Hast du das bei dir alles Deaktiviert bzw ausgeschaltet (geht das überhaupt bei deinem CPE/Router)

Habe mittlerweile die Vermutung das der Netzbetreiber am anderen Ende die VOIP Telefonie blockt und ich daher keine Verbindung bekomme
Ja, klar, immer diese pösen Netzbetreiber . . . (Du Arbeitest für die!)

Du hast ein Telephony Modem TM902 nach DOCSIS/EuroDOCSIS 3.0 mit 2 Analoge Anschlüße und High Speed Data mit einem GBit Ethernet Anschluß.
The TM902 provides SIP or NCS telephony combined with ultra-high speed data communication through advanced RF channel bonding and Giga Ethernet user data port

Kopfschüttel

Gruß,
Peter
Member: aqui
aqui Jan 11, 2014 updated at 16:04:06 (UTC)
Goto Top
Ein "TM092" gibt es nicht bei Arris !! Beim TM902 ist nicht ganz klar ob es ein Router oder ein NUR Modem ist. Die Aussage "IPv4 und IPv6 fähig" lässt aber den Schluss zu das es ggf. doch ein Router ist ?!

DAS rauszubekommen ist kinderleicht aber leider hat der TO es bis dato nicht geschafft einmal die IP Adresse des pfSense WAN Ports hier zu posten oder mal nachzusehen !!
Wenn das eine private_IP ist kann man wohl davon ausgehen das es ein Router ist.
Ist es eine öffentliche IP ist es vermutlich dann doch ein nur Modem.
Das sollte der TO also hier nochmal posten zur Klärung !!

Die SIP Traces oben zeigen das SIP mit tcpdump richtig ankommt an der PBX.
Relevant ist aber NUR ein Trace des remoten Telefons !! Dort musst du einen Call initiieren und checken ob von dort bzw. mit der dortigen WAN IP des Routers (kann man sehen wenn man dort mal auf http://www.wieistmeineip.de// surft !!) bei der PBX eingeht.
Erst DAS würde zeigen das die SIP Packete vom remoten Satelliten bei der PBX ankommen.
Siehst du keine SIP Packete von dort funktioniert dein Port Forwarding nicht an der pfSense !!
Oder....das Kabelmodem ist kein nur Modem sondern ein Router und dann muss dort logischerweise auch noch ein Port Forwarding der SIP und RTP Ports auf die WAN IP der pfSense gemacht werden !
Also warten wir mal auf die Antwort der 2 Fragen:
  • IP Adresse am WAN Port pfSense
  • SIP Trace vom remoten Telefon
und sind gespannt....

@Pjordorf
Das stimmt das der 2 analoge Telefonieports hat das nützt ihm aber nichts mit einer externen VoIP Anlage die er betreibt Dieses SIP Gateway ist ja quasi ein dummes Mini PBX im Arris.
Andersherum schürt das aber den obigen Verdacht das es doch ein Router ist mit einem SIP Analog Gateway. Und genau DAS würde dann erklären warum das "Modem" dann SIP Pakete nicht weiterleitet, denn es "denkt" die sind für ihn"
Ist das also ein Router MUSS dort zwingend Port Forwarding für SIP rein und wenn möglich sollte man den Telefonie Part deaktivieren im Setup !
heart1
Member: Netgear24
Netgear24 Jan 12, 2014 at 17:10:56 (UTC)
Goto Top
Also warten wir mal auf die Antwort der 2 Fragen:
  • IP Adresse am WAN Port pfSense
Also die IP Adresse ist definitiv eine Öffentliche an der WAN Seite der PFSense. Und zwar eine aus folgendem Range.
87.245.124.0 - 87.245.127.255
* SIP Trace vom remoten Telefon
Vom Externen Telefon kommt nichts an. Also kann ich auch nichts Schreiben. Nur der Normale SIP Traffic von mir Lokal. von Extern nix!! Die Ports sind offen, kann von meinem Kollegen bei einem anderen Netzbetreiber Problemlos Registrieren.
Zitat von @Pjordorf:
> Zitat von @Netgear24:
> Ja genau dieses habe ich im Einsatz bei mir.
Entschuldige bitte, aber du hast weder eine Ahnung noch weisst du was du Vertreibst.
Hmm. Ich möchte da nicht genauer darauf eingehen. =D
Ich Zittiere:
Das Modem ist ein nur ein Modem. Ich Vertreibe diese Dinger für unseren
> Kabelnetzbetreiber (werde wohl wissen was ich da Vertreibe)
> Jedoch habe ich nur Internet darüber laufen. Telefon haben wir in der Familie seit ca 2 Jahren nicht mehr, haben ja alle
Handy Abos. :D
Und was meinst du denn wie das Dingens was du da hast dort Telefonie macht? Hast du das bei dir alles Deaktiviert bzw
ausgeschaltet (geht das überhaupt bei deinem CPE/Router)
Wir bekommen von unserem Netzbetreiber keine Nummer zugewiesen weil wir die nicht Aktiviert haben. So sind automatisch die Telefonports deaktiviert!!
> Habe mittlerweile die Vermutung das der Netzbetreiber am anderen Ende die VOIP Telefonie blockt und ich daher keine
Verbindung bekomme
Ja, klar, immer diese pösen Netzbetreiber . . . (Du Arbeitest für die!)
Ja ich arbeite für einen Netzbetreiber, das Stimmt. Aber es handelt sich um zwei unterschiedliche. Sasag (für die arbeite ich) und Stafag (dort hat der andere Standort den Anschluss). Stafag hat sogar die IP gewechselt als sie rausbekommen hat dass dort ein Server betrieben wurde!!
Du hast ein Telephony Modem TM902 nach DOCSIS/EuroDOCSIS 3.0 mit 2 Analoge Anschlüße und High Speed Data mit einem GBit
Ethernet Anschluß.
The TM902 provides SIP or NCS telephony combined with ultra-high speed data
> communication through advanced RF channel bonding and Giga Ethernet user data port

Werde es daher wohl oder Übel über einen IPSec Tunnel lösen müssen.

Grüsse
Member: Pjordorf
Pjordorf Jan 12, 2014 at 18:50:47 (UTC)
Goto Top
Hallo,

Zitat von @Netgear24:
87.245.124.0 - 87.245.127.255
OK.

Vom Externen Telefon kommt nichts an
Aber du kannst schon am Ethernetport deines Modems (oder wie sollen wir dein Teil nennen?) den Traffic erkennen (Wireshark oder ähnliches?). Oder ist hier der Traffic deines SIP Telefons gemeint?

Wir bekommen von unserem Netzbetreiber keine Nummer zugewiesen weil wir die nicht Aktiviert haben
Aha. Und du hälst es für absolut unwichtig wenn du hier um Hilfe fragst uns diese Information auch Mitzuteilen. Wir hier wissen nicht was du machst, oder tust, oder hast, oder was der geier noch was. Uns ist ebenso unbekannt wie du als Mitarbeiter eines ISP dir irgendwelche Teile anklemmen kannst und dir irgendwie mit irgendwelchen Protokollen ans laufen bekommst. Wir können nur versuchen deine uns Falsch genannten Produkte im Öffentlich zugänglichen Internet nach zu lesen. Das bei dir bestimmte Sachen sind oder eben nicht sind - WIR KÖNNEN ES NICHT WISSEN. Sei also nicht eingeschnappt wenn wir dir Unfähigkeit vorwerfen. Wir kennen weder deinen ISP, deinen Vertrag noch was bei dir aus der Wand kommt. Hilf uns mit (korrekten) Information, dann können wir dir vermutlich auch Helfen.

Habe mittlerweile die Vermutung das der Netzbetreiber am anderen Ende die VOIP Telefonie blockt und ich daher keine Verbindung bekomme
Häng mal ein anderes Modem an deine Leitung um auszuschließen das dein Modem doch mehr tut als du annimmst. Nicht das dein TM902 doch die benötigten Pakete für sich behält.

Stafag hat sogar die IP gewechselt als sie rausbekommen hat dass dort ein Server betrieben wurde
Vermutlich ist dein Anschluss wie fast alle andere auch an der MAC Adresse gekoppelt, und beim Wechsel der MAC am Anschluss (Aus- und wieder Einschalten) wird dir dann einfach eine neue IP verbraten. Etwas anderes als DSL Zwangstrennung um den Serverbetrieb zu erschweren. Deine IP kann wechseln, muss aber nicht. Bei vielen ISP die Ethernet anbieten der Fall das eben nicht nach jeder Trennung eine neue IP verpasst wird.

Werde es daher wohl oder Übel über einen IPSec Tunnel lösen müssen.
Das bleibt dir unbenommen.

Gruß,
Peter
Member: aqui
Solution aqui Jan 12, 2014 updated at 20:04:09 (UTC)
Goto Top
OK wenigstens das Thema Router oder Modem ist damit sicher geklärt.
Vom Externen Telefon kommt nichts an. Also kann ich auch nichts Schreiben. Nur der Normale SIP Traffic von mir Lokal. von Extern nix!! Die Ports sind offen, kann von meinem Kollegen bei einem anderen Netzbetreiber Problemlos Registrieren.
DAS sagt allerdings (fast) alles.
Du hast also einen Fehler in der pfSense NAT und Firewall Konfig gemacht !!
Vermutlich hast du nur einzig die NAT Konfig am WAN Port gemacht aber vergessen auch die Firewall Regel anzupassen !!?
Bedenke das die Firewall am WAN Port ALLES blockt per Default.
SIP und RTP im NAT auf die PBX zu forwarden ist also nur die halbe Miete. Die Firewall am WAN Port musst du fūr diese Ports logischerweise auch öffnen damit überhaupt etwas zum Port Weterleiten dort ankommt !
Sicherheitshalber solltest du mit einem Wireshark oder tcpdump auch nochmal checken im 85.xx Segment das SIP auch durchs Modem kommt.
Da das Modem auch Voice Fähigkeiten hat solltest du das wasserdicht messen das da auch nix hängen bleibt und die SIP Pakete des remoten Telefons wenigstens bis da sprich WAN Port pfSense kommen. (Kann man mit den internen Sniffer Funktionen der pfSense auch sehen)
Der Rest sind dann nur noch ein paar richtige Klicks im pfSense Setup.
Member: Netgear24
Netgear24 Jan 12, 2014 at 20:06:09 (UTC)
Goto Top
Sodala, Danke dir Vielmals. War tatsächlich auf der WAN Seite die Firewall die geblockt hat. SIP und RTP kommen jetzt bis zur PBX durch.

Grüsse
Member: aqui
Solution aqui Jan 14, 2014, updated at Nov 09, 2014 at 16:59:15 (UTC)
Goto Top
Siehste ! Ist immer die gleiche Leier hier face-wink aber glücklicherweise gibts ja den Kabelhai oder tcpdump...
Und ?? Wie ist denn nun der Status ?? Geht alles wie es soll ??
GermansolvedQuestionVoice over IPNetworks
Hotly discussed
AlexWishaHow to set up and configure a Linux GRE tunnelAlexWisha - 3 CommentsDaniEnd of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 CommentjstrickerWIREGUARD VPN ON UDM PRO BEHIND FRITZBOX - HANDSHAKE DID NOT COMPLETEjstricker