commodity
Goto Top

VOIP hinter pfsense ohne(!) Portfreigaben (und auch ohne STUN und SIP-ALG)

Hallo erstmal in die Runde, dies ist mein erster Post hier, den ich zunächst mit einem dicken Dankeschön einleiten möchte. Ich habe hier schon oft (mitlesend) Hilfe oder zumindest einen sinnvollen Ansatz gefunden um ein Problem zu lösen und obgleich hier der eine oder andere wirkliche Experte dabei ist, ist der Ton selbst bei einfacheren Fragestellungen selten genervt (und wenn, dann meist nicht unberechtigt). Ein ganz besonderes Dankeschön möchte ich @aqui aussprechen, denn ihn lese ich hier am häufigsten (und stets bereichernd), denn meine Steckenpferde sind Netzwerke und das was dran hängt, insbesondere VOIP. Allein die Anleitung zur pfsense Anleitung Firewall ist den Forumsnobelpreis wert, finde ich. Ich kein gelernter Administrator, sondern “Quereinsteiger” und mittlerweile wohl zu alt, um noch ein Studium oder eine Ausbildung zu beginnen face-wink Dafür betreue ich auch nur ehrenamtlich kleinste Systeme (<10 Rechner). Was ich brauche, wird gelernt, es gibt ja viele tolle Bücher und wenn was nicht klar wird, dann gibt es Euch. Danke!

Genug der Vorrede, ich habe hier im häuslichen System eine pfsense 2.4.4 im Probebetrieb auf einer virtuellen Maschine, diese soll später auf ein APU-Board umziehen. Das Lernen auf der VM ist super. Man kann ja einerseits in der pfsense jederzeit Konfigurationsschritte rückgängig machen (Diagnostics\Backup & Restore\Config History), andererseits Snapshots der VM machen, wenn bestimmte Stände erreicht sind oder man umfangreicher in eine bestimmte Richtung konfiguriert. So habe ich die pfsense zunächst (anfängertypisch) hinter einer Fritzbox 7490 per exposed host angedockt, damit deren Funktionalität erhalten bleibt und dafür einen Snapshot gemacht, alternativ aber auch eine 7412 zum Modem verwandelt und diesen Ausbau als Snapshot weiter entwickelt (guter Beitrag der c't, kostenfrei recycelt hier: Fritzbox 7412 als Modem. Beides läuft nun, für den endgültigen Modem-Betrieb muss ich aber noch die Faxfunktion umziehen.

Ich habe also aktuell (noch) den Aufbau (für die folgende Fragestellung ist dieser aber irrelevant, die Problematik ergibt sich bei beiden Anbindungsvarianten)

aufbau

Der Asterisk bekam erwartungsgemäß aus dem LAN keinen Ton und konnte auch nicht angerufen werden. Auf Grundlage diverser Anleitungen hier und bei netgate hatte ich dann in der pfsense (Firewall\NAT\Port Forward) Portfreigaben eingerichtet, einmal für Sip-Port, der bei mir (statt 5060) UDP 5081 ist (weil die Fritzbox den 5060 ja okkupiert) und einmal für die RTP-Ports (UDP 10000-20000). Das lief und läuft wunderbar und scheint die am häufigsten empfohlene Konfiguration zu sein.

Damit konnte und wollte ich mich aber nicht zufrieden geben, denn Portfreigaben sind ja immer Preisgabe eines Stückes Sicherheit und der Asterisk hätte dann zumindest in die DMZ umziehen müssen. Ich habe aber nicht eingesehen, dass ich mit einer pfsense für den Asterisk eine geringere Sicherheit in Kauf nehmen soll als mit einer bloßen Fritzbox, hinter der ein Asterisk ohne jede Portfreigabe läuft, wenn sich alle Telefone im (hier häuslichen) LAN befinden. Auch für die Kombi Fritzbox-Asterisk kursieren im Internet jede Menge (falsche) Konfigurationen, die eine Portfreigabe vorsehen, tatsächlich benötigt ein Asterisk im normalen Umfeld keinerlei Portfreigabe, wie Madsen et al in dem ausgezeichneten “Asterisk - The Definitive Guide” auch klargestellt haben.
Also Fritzbox ohne Portfreigabe, pfsense mit Portfreigabe, das konnte/durfte ja wohl nicht sein. Dann las ich von STUN und SIP-ALG, hatte aber den Eindruck, dass das mit Kanonen auf Spatzen geschossen sein könnte. Es war ja klar, dass das ganze irgendwie mit NAT zu tun hat. Also in und zur pfsense geforscht. Im Ergebnis führte mich das hier auf die (hoffentlich) richtige Spur: pfsense mit VOIP-Phones. In dem Beitrag geht es zwar um die Anbindung von SIP-Phones an externe PBX aber das dort beschriebene Umschreiben der Source-Ports klang für mich wie die Einladung zum Missverständnis von Asterisk und Provider. Unter NAT mit PBX ist dann gut erklärt, wie man das Source-Port-Rewriting abstellt, allerdings nur als Maßnahme neben dem Portforwarding. Meiner Meinung nach genügt aber allein das Unterbinden des Source-Port-Rewriting. Dies erfolgt unter Firewall\NAT\ im Untermenü “Outbound”. Dort habe ich zwei Outbound-NAT Regeln angelegt wie folgt, wobei LAN_Address die Netzwerkadresse (hier 192.168.2.0), Asterisk_Main der Port UDP 5081 (Standard wäre 5060) und Asterisk_RTP die Ports UDP 10000-20000 sind:

outbound nat1

Entscheidend ist der Haken bei “Static Port”

static

Wenn ich es richtig verstanden habe, ist der Hintergrund hier (ganz vorzüglich) erklärt: VOIP hinter Router (@LordGurke: Klasse!) Dort erster Post: symmetrisches RTP vs asymmetrisches RTP.

Darauf konnte ich die Portweiterleitungen löschen. Sehe ich es richtig, dass dies die korrekte (also sicherste) Vorgehensweise ist oder habe ich da etwas missverstanden?

Danke an Euch und schönes Wochenende!

Content-Key: 541698

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

Ausgedruckt am: 28.03.2024 um 20:03 Uhr

Mitglied: falscher-sperrstatus
falscher-sperrstatus 31.01.2020 aktualisiert um 18:30:58 Uhr
Goto Top
Du verkennst eines, die Fritzbox macht automatisch die Ports auf. Sie pfsense in der Konfiguration nicht. Das geht als ganz kurz und knapp schlicht nicht.
Mitglied: commodity
commodity 31.01.2020 aktualisiert um 18:43:19 Uhr
Goto Top
Äh, sorry @certifiedit.net

1. beantwortet das meine Frage nicht. Die steht im letzen Absatz. Das was ich technisch beschreibe (und in der Überschrift zusammen fasse ) funktioniert (zumindest seit vier Stunden) vorzüglich. Vielleicht hab ich es nicht deutlich genug formuliert: Es geht um (überflüssige) NAT-Portfreigaben von WAN to LAN.

2. in der beschriebenen Konfiguration ist die pfsense (von innen nach außen) genauso offen, wie die Fritzbox. Denn dort ist im Standard die LAN to any - Rule definiert.
Mitglied: falscher-sperrstatus
falscher-sperrstatus 31.01.2020 aktualisiert um 18:45:27 Uhr
Goto Top
Die Fritzbox öffnet aber dynamisch Ports, die pfsense nicht. Demnach doch das beantwortet die Frage, auch wenn dir das nicht gefällt.

Sicher oder unsicher kommt am meisten darauf an, wen du das alles kontaktieren lässt. Ports hast du in jedem Fall offen.
Mitglied: LordGurke
LordGurke 31.01.2020 aktualisiert um 20:23:48 Uhr
Goto Top
Man braucht die Ports aus Richtung WAN normalerweise nicht explizit öffnen oder forwarden, wenn die Firewall stateful arbeitet (was normalerweise der Fall ist).
Da in jedem Fall für die Registrierung ausgehend SIP-Anfragen von der Telefonanlage nach außen gehen, muss die Firewall ja zwingend die Antworten darauf durchlassen Hier empfiehlt sich aber, möglichst TCP für SIP zu erzwingen, da hierdurch zum einen die TCP-Keepalives den Port offen halten und zum anderen die Firewalls TCP-Verbindungen in der Regel sehr langlebig offen lassen.

Für RTP gilt das gleiche: Solange dein Client symmetrisches RTP verwendet (auch das ist inzwischen Quasi-Standard) wird die Firewall die eingehenden RTP-Pakete als Antwort auf die von dir gesendeten Pakete erkennen und ebenfalls durchlassen.
Mitglied: Spirit-of-Eli
Spirit-of-Eli 31.01.2020 um 20:23:15 Uhr
Goto Top
Warum hast du beim portforwarding auf der wan Seite deine local Clients eingetragen?
Mitglied: commodity
commodity 31.01.2020 aktualisiert um 21:11:13 Uhr
Goto Top
@LordGurke: ja, Danke, das hatte ich auch gedacht. Aber ganz viele Leute hier (und nicht nur hier) schreiben, dass sie bei der pfsense für VOIP Portforwarding einrichten mussten, weil sie sonst keinen Sound hatten bzw. Anrufe nicht durchkamen. Selbst Meister @aqui hat dies, wenn ich ihn richtig verstanden habe, wiederholt angeregt. Und auch netgate selbst (Links im ersten Post) regt ja die Einrichtung von Weiterleitungen an, z.B. hier.

Meine im ersten Post getroffene Feststellung entspricht aber Deiner Auffassung, oder? Es ist, da sind wir völlig d'accord, eben keine Portweiterleitung erforderlich, sondern das Problem ist das standardmäßige Source Port Rewriting der pfsense. Deshalb trotz Registrierung kein Ton in der Standardkonfiguration. Meine Einstellung ändert dies, ohne ein Portforwarding zu machen - oder sehe ich das falsch?

@Spirit-of-Eli: Das ist kein Portforwarding - hoffe ich jedenfalls. Nach meinem Verständnis sind NAT und Portforwarding zwei Paar Schuhe und ich habe lediglich eine Outbound-NAT Rule eingerichtet. Es gibt in meiner Konfiguration auf diese Ports keinerlei Weiterleitung mehr.
Mitglied: Spirit-of-Eli
Spirit-of-Eli 31.01.2020 um 21:13:52 Uhr
Goto Top
Ich weiß gerade nicht genau wie du es im Fall von Doppel NAT einrichten musst da VOIP etwas tricky ist. Allerdings ist für die reine Funktion erstmal nur port 5060 erforderlich sofern nicht tools wie siproxyd eingesetzt werden. (Würde ich aber empfehlen.

Ich habe damals einfach Port 5060 nur von meinem SIP provider aus zugelassen. Mehr ist nicht nötig. Auch muss kein riesen Loch geschlagen werden.

Eigentlich reicht schlicht ein Stun Server vom provider einzutragen.

Über die Doppel NAT Nummer muss ich allerdings nachdenken.
Mitglied: Spirit-of-Eli
Spirit-of-Eli 31.01.2020 um 21:17:16 Uhr
Goto Top
Was funktionieren müsste ist folgendes. Von dem vorliegenden access Router 5060 und rtp ports auf die sense weiter leiten (forwarden).
Auf der Sense 5060 öffnen oder eben den sipproxy nutzen. Wenn das für die Sprache noch nicht reicht muss nur noch der Stun Server definiert werden.
Mitglied: falscher-sperrstatus
falscher-sperrstatus 31.01.2020 um 21:17:24 Uhr
Goto Top
Wo siehst du denn den Unterschied?

In computer networking, port forwarding or port mapping is an application of network address translation (NAT) that redirects a communication request from one address and port number combination to another while the packets are traversing a network gateway, such as a router or firewall. This technique is most commonly used to make services on a host residing on a protected or masqueraded (internal) netwo

Wiki en
Mitglied: commodity
commodity 31.01.2020, aktualisiert am 01.02.2020 um 12:43:13 Uhr
Goto Top
@Spirit-of-Eli: Dankeschön, bitte nicht über Double NAT nachdenken. Double NAT ist nicht das Problem. Wie ich im ersten Post schrieb, besteht das Soundproblem auch bei Nur-Modem-Betrieb (siehe auch die netgate-Links). Die Beschränkung auf den Provider ist ein Ansatz, aber Provider ändern auch mal die Sip-Server, das wäre zu unstabil.

Nochmals: Im Einklang mit @LordGurke bin ich der Auffassung, dass die vielen Empfehlungen, auch von netgate zum Portforwarding in diesem Kontext nicht nötig sind, sondern nur das Source Port Rewriting abgeschaltet werden muss. Mich interessiert nur, ob jemand hier findet, dass das falsch gedacht ist. Es funktioniert jedenfalls... Bitte keine Vorschläge zu anderen Konfigurationen. Die gibt es, aber das ist nicht meine Frage gewesen.
Mitglied: commodity
commodity 31.01.2020 aktualisiert um 21:36:06 Uhr
Goto Top
@certifiedit.net: NAT schreibt die Adressierung um, leitet aber selbst nicht weiter. Das machen die Firewall-Rules.
Guckst Du hier und hier und hübsch erläutert hier. Dort wird kombiniertes NAT und Forwarding dann als DNATbezeichnet. Genau deshalb legt die pfsense ja bei Einrichtung eines Portforwardings auch eine Firewall-Rule dazu an.

Bei meiner Outbound NAT Rule aber eben nicht face-wink
Mitglied: falscher-sperrstatus
falscher-sperrstatus 31.01.2020 aktualisiert um 21:35:31 Uhr
Goto Top
Falsch, die Firewall Regel erlaubt nur den Zugriff von x nach y. Natürlich geht es ohne auch nicht....

Dennoch ist eine Unterform des nattens das Port forwarden
Mitglied: aqui
Lösung aqui 01.02.2020 aktualisiert um 16:11:20 Uhr
Goto Top
wenn ich ihn richtig verstanden habe, wiederholt angeregt.
Nope ! Das habe ich eigentlich nie wirklich ! Ich halte es da genau wie Kollege @LordGurke . Normal muss man niemals irgendwas forwarden wenn man SIP mit TCP verwendet.
SIP ist so oder so niemals das Problem sondern das ist in der Regel immer RTP weil das in den Antworten Random Ports benutzt und das ist schwer in den Griff zu bekommen ohne Scheunentor.
Aber mit symetrischem RTP ist das dann auch kein Thema mehr. Mit moderen Anlagen funktioniert sowas fast out of the Box.
Was die Outbound NAT Regel angeht ist das wie Kollege Spirit oben schon zu recht sagt eigentlich überflüssig. Die FW macht ja per se Outbound NAT. Warum man dann das ganze Netz nochmal doppelt dort eintragen muss erschliesst sich den meisten wohl vermutlich nicht, denn es geht auch de facto ohne.
Mitglied: commodity
commodity 01.02.2020 um 12:39:31 Uhr
Goto Top
Danke @aqui! Dann sind wir im Prinzip alle einig. Keine Portfreigaben für VOIP-Server (hier: Asterisk).

Leider geht es de facto nicht (für alle) ohne, sonst gäbe es doch diese beiden netgate-docs nicht: Link1 Link2
Vielleicht ist das aber ein providerspezifisches Problem, das klingt ja bei netgate so an:

"With a minority of providers, rewriting the source port of RTP can cause one way audio. In that case, setup manual outbound NAT and Static Port on all UDP traffic potentially with the exclusion of UDP 5060."

Wenn es dennoch Unsinn ist, was ich da eingerichtet habe, könnt Ihr mir helfen, den Unsinn zu beseitigen? Welche Info braucht ihr? Und könnt ihr vielleicht diese Fragen beantworten?:

1. Sind bei der Konfiguration wie im ersten Post dargestellt (Einrichtung Outbound NAT mit Static Port ohne weitere Firewall-Rules) nun die Ports (UDP 5081 und 10000-20000) von außen offen oder nicht? Ich meine nein und ein nmap -sUV -T4 meldet auch nur das übliche open|filtered
2. Also konkret: Ist der Eintrag im Outbound NAT irgendwie gefährlich?
3. Wenn er unsinnig ist, wie komme ich zu Ton, ohne ihn und ohne die in Link2 von netgate empfohlenen Portfreigaben?

Hier nochmal die Pics der Firewall-Konfig:
1
1a
2
Mitglied: aqui
aqui 01.02.2020 um 16:13:50 Uhr
Goto Top
nun die Ports (UDP 5081 und 10000-20000) von außen offen oder nicht?
Check online mit: https://www.heise.de/security/dienste/portscan/test/go.shtml?scanart=1
wie komme ich zu Ton, ohne ihn
STUN ?! Aber aus unerfindlichen Gründen willst du das ja nicht. face-wink
Mitglied: LordGurke
LordGurke 01.02.2020 aktualisiert um 16:37:06 Uhr
Goto Top
Du hast vermutlich das Problem, dass deine Asterisk nicht weiß, welche externe IP-Adresse sie hat. Das muss sie aber wissen, da in SIP-INVITES eine Media-IP angegeben werden muss, an die das Audio vom Provider an dich geschickt werden soll.
Weiß die Asterisk diese Info nicht, schreibt sie als Media-IP die Adresse hinein, die sie intern hat und mit der der Provider natürlich wenig anfangen kann.

Du musst also einfach in der Asterisk (Stichwort "res_stun") einfach nur einen STUN-Server eintragen - fertig.
Die Asterisk kontaktiert dann regelmäßig diesen Server und findet darüber heraus, welche externe IP-Adresse sie hat (damit steht dann die korrekte IP-Adresse im SIP-Paket).
Welcher Server das ist, ist letztlich eigentlich egal, aber es bietet sich natürlich an, die STUN-Adresse deines SIP-Providers zu hinterlegen.

Zusätzlich solltest du für SIP sicherstellen, dass Asterisk weiß, dass sie NAT-Safe arbeiten muss. Das heißt, es muss hinterlegt sein, dass sich dein Provider aus Sicht der Asterisk hinter einem NAT befindet.
Wenn du chan_sip benutzt, ist dies mit einem simplen
nat = force_rport
im Kontext deiner Provider-Konfiguration getan. Alternativ kann das auch im "[general]"-Teil stehen, denn auch bei den internen Telefonen schadet es nicht.

Was du in solchen Fällen nicht aktivieren darfst ist "nat = comedia" - denn dann wartet Asterisk einige Sekunden bis sie Audio von der Gegenstelle bekommt, was aber nicht durchkommt, weil ohne ausgehenden RTP-Verkehr die Firewallports nicht durchlässig werden.
Mitglied: commodity
commodity 01.02.2020 um 16:46:28 Uhr
Goto Top
Danke, ja, warum nicht einfach mal Heise... Ist alles zu face-smile

3

Dazu ist zu ergänzen, dass ich die Fritzbox inzwischen rausgenommen habe, also das Netz Modem-Only läuft - vor allem Dank Deiner tollen Anleitung.

STUN hatte ich ja überlegt, aber
a) nicht alle Provider bieten STUN an (o2) z.B. nicht. Easybell, der ein IMHO hervorragenderTelefonieprovider ist, z.B. auch nicht. Und
b) warum auf eine externe Lösung setzen, wenn es mit einer internen funktioniert. Und
c) darf es doch wohl nicht sein, dass eine Fritte netzwerktechnisch etwas kann, mit dem eine pfsense nicht auch out of the box klar kommt face-wink

Oder gibt es einen technischen Grund, STUN oder SIP-ALG dem Abschalten des Source Port Rewriting vorzuziehen?
Also in anderen Worten: Warum würdest Du, als Kenner, dessen technische Meinung ich sehr schätze, STUN statt meiner Lösung einsetzen?
Mitglied: LordGurke
Lösung LordGurke 01.02.2020 um 19:11:00 Uhr
Goto Top
Zitat von @commodity:
STUN hatte ich ja überlegt, aber
a) nicht alle Provider bieten STUN an (o2) z.B. nicht. Easybell, der ein IMHO hervorragenderTelefonieprovider ist, z.B. auch nicht. Und

Man kann wirklich irgendeinen benutzen - z.B. "stun.services.mozilla.com".

b) warum auf eine externe Lösung setzen, wenn es mit einer internen funktioniert.

Ein interner STUN-Server schließt sich doch schon denknotwendig aus face-wink


Oder gibt es einen technischen Grund, STUN oder SIP-ALG dem Abschalten des Source Port Rewriting vorzuziehen?

STUN hat nichts mit ALG zu tun! Es dient lediglich dazu, dass ein Client selbst ermitteln kann, welche IP-Adresse er im Internet hat und ob ein Port-Rewriting stattfindet.
Wenn du die Möglichkeit hast, zuverlässig Source Port Rewriting abzuschalten, wäre das ohnehin schon aus Performance-Gründen vorzuziehen. Und du handelst dir nicht später Probleme ein mit Protokollen, die symmetrische Ports ggf. voraussetzen (manche IPsec-VPN-Implementationen zum Beispiel oder Bittorrent-Clients).

Also in anderen Worten: Warum würdest Du, als Kenner, dessen technische Meinung ich sehr schätze, STUN statt meiner Lösung einsetzen?

STUN behebt zumindest das Problem, dass in deinen SIP-INVITES falsches Media-IPs drinstehen. Das kann ein Provider-Gateway in der Regel zwar geradeziehen, indem er diese Angabe ignoriert und guckt, wo der Traffic wirklich her kommt - aber in Kombination mit Source Port Rewriting ist das extrem instabil.
Ich würde daher also SRP ausschalten und zusätzlich den STUN-Server eintragen face-wink
Mitglied: Spirit-of-Eli
Spirit-of-Eli 01.02.2020 um 19:33:09 Uhr
Goto Top
Nen Stun Server kann man auch selbst betreiben. Ich habe hier coturn am rennen.
Mitglied: commodity
commodity 01.02.2020 um 20:24:10 Uhr
Goto Top
Zitat von @LordGurke:

Du hast vermutlich das Problem, dass deine Asterisk nicht weiß, welche externe IP-Adresse sie hat.

Nein, mein Asterisk weiß bescheid face-wink ist mit externhost="festeIP" eingetragen.

Wenn du chan_sip benutzt, ist dies mit einem simplen
> nat = force_rport
im Kontext deiner Provider-Konfiguration getan.

Was du in solchen Fällen nicht aktivieren darfst ist "nat = comedia"

Bei mir ist nat=force_rport,comedia eingetragen, wie zB hierempfohlen. Vor zehn Jahren war das noch nat=yes. Soll ich Deiner Meinung nach das comedia rausnehmen?

Verstehe ich Eure Ausführungen zu STUN also, dass ihr empfehlt, trotz meiner (bereits voll funktionierenden) Lösung, das Source Port Rewriting für diese Ports abzustellen noch einen STUN Server einzusetzen? Das sollte doch nach Deiner Erklärung @LordGurke, überflüssig sein, denn der Asterisk kennt wie gesagt seine IP.

Meine Frage war einzig und allein ja auch, ob die von mir oben beschriebene Lösung (die ja funktioniert - Telefon inbound und outbound läuft) irgendwie problematisch ist. Dass es auch anders geht, war mir klar. Ich wollte nur eben möglichst mit Bordmitteln auskommen, also keinen STUN ansteuern und kein zusätzliches Package wie SIP-ALG draufpacken und eben auch keine Ports öffnen.

@LordGurke, ich verstehe dies

STUN behebt zumindest das Problem, dass in deinen SIP-INVITES falsches Media-IPs drinstehen.

so, dass das bei einer fest im Asterisk hinterlegten IP überflüssig ist und dies
Ich würde daher also SRP ausschalten und zusätzlich den STUN-Server eintragen
so, dass Du meinen Weg SRP auszuschalten als unproblematisches und korrektes Vorgehen ansiehst.

Zusammen gefasst:
 Für VOIP, das hinter hinter der pfsense läuft sind von WAN kommend keinerlei Ports zu forwarden
 SRP ist auszuschalten, mittels einer Regel im Outbound NAT, wie im ersten Post beschrieben
 STUN ist u.U. (u.a.) einzusetzen, wenn die IP nicht fest vergeben ist.

Richtig? Dann ist das super geklärt. Ich danke Euch. Ich warte noch einen Tag, ob noch jemand was korrigiert oder interessantes ergänzt, dann drücke ich auf gelöst.
Mitglied: LordGurke
Lösung LordGurke 01.02.2020 aktualisiert um 21:02:41 Uhr
Goto Top
OK, das mit der statischen IP war mir durchgegangen. Dann brauchst du STUN tatsächlich nicht.

Zitat von @commodity:
Bei mir ist nat=force_rport,comedia eingetragen, wie zB hierempfohlen. Vor zehn Jahren war das noch nat=yes. Soll ich Deiner Meinung nach das comedia rausnehmen?

"comedia" ist dafür da, dass die Asterisk selbst herausfindet, wie die korrekte Media-IP der Gegenstelle ist und dahin dann RTP zurückadressiert.
Das ist aber nur für an die Asterisk angemeldeten Clients sinnvoll - ist die Asterisk selbst der Client und sitzt hinter NAT ist das eher hinderlich als hilfreich, daher solltest du das besser entfernen (zumindest für den Kontext deines SIP-Providers).
Und für Clients ist es auch nur dann sinnvoll, wenn diese selbst durch ein NAT hindurch zur Asterisk müssen.
Befinden sie sich im lokalen Netz kann man auch das weglassen - wobei ich hier nat=force_rport stehen lassen würde, denn das impliziert, dass die Asterisk niemals versucht DirectMedia oder DirectRTPSetup zu verwenden, was mit NAT nicht kompatibel ist.

"nat=yes" war quasi das Äquivalent für "force_rport" und einer Art sehr vereinfachtem "comedia".
Steht dort aber explizit "nat=comedia" ist das ein aggressiveres Verhalten und in deinem Setup potentiell fehleranfälliger.

@LordGurke, ich verstehe dies
STUN behebt zumindest das Problem, dass in deinen SIP-INVITES falsches Media-IPs drinstehen.
so, dass das bei einer fest im Asterisk hinterlegten IP überflüssig ist und dies

Tatsächlich, dies ist nur notwendig wenn nicht klar ist, welche IP die Asterisk nach extern haben wird.
Bei einer statischen IP und nur einem WAN-Zugang ist das hinterlegen der IP vollkommen ausreichend und STUN wird in dem Fall tatsächlich nicht gebraucht.

so, dass Du meinen Weg SRP auszuschalten als unproblematisches und korrektes Vorgehen ansiehst.

So isses.


Zusammen gefasst:
 Für VOIP, das hinter hinter der pfsense läuft sind von WAN kommend keinerlei Ports zu forwarden
>  SRP ist auszuschalten, mittels einer Regel im Outbound NAT, wie im ersten Post beschrieben
>  STUN ist u.U. (u.a.) einzusetzen, wenn die IP nicht fest vergeben ist.
> 

Würde ich so unterschreiben.

SRP sollte zumindest für VoIP ausgeschaltet sein, da ja die Information der verwendeten Ports in den SIP-INVITES an die Gegenstellen übertragen werden und diese Informationen dann falsch sind. Theoretisch kann das VoIP-Gateway des Providers "geradeziehen" indem es anhand des adressierten Ports auf der eigenen Seite und der Quell-IP Vermutungen anstellt. Das passiert vermutlich auch aktuell - darauf verlassen sollte man sich aber nicht.

Und wie gesagt die Empfehlung, nach Möglichkeit SIP per TCP zu verwenden, sofern der Provider das anbietet. Bei UDP gibt es ja kein definiertes Ende einer Verbindung, daher kann es dir passieren, dass eine Firewall nach wenigen Minuten eine Verbindung als beendet sieht und keine eingehenden Anrufe mehr signalisiert werden können, weil der Port eingehend nicht mehr offen ist.
Bei TCP ist das Timeout schon generell höher, zusätzlich haben TCP-Verbindungen die Möglichkeit ein Ende der Verbindung zu signalisieren sodass Firewalls Verbindungen ohne Aktivität in der Regel deutlich länger bestehen lassen.
Zusätzlich senden die Gegenstellen oftmals TCP-Keepalives um zu sehen, ob die Verbindung noch besteht, was natürlich auch die Firewall registriert.

In Asterisk konfigurierbar (chan_sip):
;; Im Provider-Kontext:

[deinprovider]
transport=tcp

;; Für die Registrierung einfach "tcp://" der eigentlichen Register-Zeile präfigieren:  
register => tcp://........