Cisco IP Phone über OpenVPN verbinden

@aqui: Reicht es nicht auch aus, wenn man den TFTP-Server mitgibt? Diesen kann man ja per DHCP-Option 150 und per statischer IP-Konfiguration hinterlegen. Zumindest kenn ich es so vom CUCME. TFTP Broadcasts für die Telefone kenne ich jetzt so nicht.

Uuuhhh, da hast du dann aber schon einen grundsätzlichen Fehler das dein OpenVPN gar nicht zum Fliegen kommt und es keine Connectivity zwischen den beiden lokalen LANs gibt. Wenns daran schon scheitert wird auch der Rest nix das ist klar.
Das ist also die erste Anlaufstelle zum Troubleshooting !
Das Tutorial hilft dabei: OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Bedenke das du die o.a. Konfig etwas anpassen musst, denn das Szenario Dort ist kein Site-to-Site VPN sondern ein Client VPN es zeigt aber ddas grundlegende Setup der pfSense.
Details dann im OpenVPN Tutorial: Merkzettel: VPN Installation mit OpenVPN
Ein Ping von Endgeräten in den jeweiligen lokalen LANs untereinander mindestens aber der loaklen Firewall LAN IPs MUSS gewährleistet sein damit ein sauberes Routing zw. beiden Netzen funktioniert. Das ist die Basis aller IP Kommunikation.
Achtung: Wenn du vom Diagnostics Menü der Firewall pingst bedenke das du ein entsprechendes Absender Interface setzt !! Das sollte natürlich immer das lokale LAN Interface sein !
Ja, natürlich hast du Recht hier. Habe ich im Eifer des Gefechts oben übersehen !! Shame on me...
Wenn man dem Telefon über den DHCP Server mit der DHCP-Option 150 und auch der Option 66 das mitgibt bootet der auch von Remote ! Sorry, das hatte ich übersehen !
Wichtig ist dann aber das das VPN sauber rennt.

Grade mal getestet über ein IPsec VPN und klappt fehlerfrei. Allerdings sollte man dem DHCP Server, wie oben schon gesagt, auch noch die Option 66 mitgeben.
So sähe die DHCP Server Konfig auf einem Cisco IOS Router oder Switch dazu aus:
!
ip dhcp pool cisco7970
host 192.168.100.154 255.255.255.0
client-identifier 0100.25a9.1219.45
default-router 192.168.100.254
dns-server 192.168.100.254
option 66 ip 192.168.1.253
client-name c7970g
option 150 ip 192.168.1.253
domain-name zuhause.home.arpa
option 42 ip 131.188.3.221
!
(.1.253 ist der TFTP Server der aus dem .100.0er Netz natürlich pingbar sein muss !)
Das sollte mit anderen DHCP Serven dann identisch sein !

Nein, dagegen spricht nichts. Es ist vollkommen egal in welchem Netzwerk die Telefone nach dem Laden ihrer Konfig Datei arbeiten. Sie brauchen auch keinen TFTP Server denn sie booten immer die letzte Konfig Datei die sie geladen haben sofern kein TFTP Server vorhanden ist.
Wenn sie aus ihrem Betriebsnetz IP routingtechnisch den SIP Server erreichen können ist alles OK. Du kannst die Telefone ja auch problemlos mit dem SIPgate Server (Tutorial Beispiel) verbinden der ja auch in einem völlig fremden IP Netz liegt und dazu noch im Internet. Das ist ja gerade der tiefere Sinn von VoIP das man das Telefon egal wohin mitnehmen kann und immer lokal telefonieren kann. Du kannst dir also einen kleinen Raspberry Pi Taschenrouter mit OVPN basteln oder einen fertigen GL.inet OpenVPN Router in die Tasche stecken und egal wo du bist ins Netzwerk stecken und dein telefon dranstecken. Router baut VPN zum SIP Server auf...Telefon kann telefonieren. Einfach und simpel.
(Das GL.iNet Beispiel oben zeigt übrigens wie das Site-to-Site Setup auf der pfSense auszusehen hat.)
Mmmhhh, das zeigt das du einen Fehler in der statischen IP Adressierung am PC hast.
Das was du vorhast ist genau der richtige Weg die SIP Connectivity aus dem anderen Netz zu testen mit einem PC und einem Softphone wie Phoner oder Phoner lite da drauf:
https://lite.phoner.de/index_de.htm
https://phoner.de/index.htm
Dabei ist es völlig egal ober der PC in den NIC Settings eine dynamische DHCP Adresse oder eine statische sprich manuelle bekommt.
Bei der manuellen Vergabe ist es nur wichtig das der PC auch das korrekte Gateway und den korrekten DNS Server eingetragen bekommt den er auch hatte mit der DHCP Adressvergabe.
Weiterhin wichtig ist das sich die statische, manuelle IP Adresse des PCs außerhalb der DHCP Adresspools befindet ansonsten kommt es zu solchem Verhalten wie oben.
Es muss also am PC völlig egal sein ob statisch oder DHCP, die Connectivity ins remote VPN Netz MUSS immer gegeben sein.
Erst wenn das der Fall ist startest du deine Softphone Anwendung und testest eine SIP Connection auf den remoten SIP Server (FritzBox). Klappt das und kannst du fehlerlos damit telefonieren wird das auch mit den Ciscos Phones der Fall sein.
Beachte bei einem lokalen SIP Server das du das NAT im Telefon Setup deaktivierst mit <natEnabled>false</natEnabled>
Funktioniert das Telefon im lokalen Netzwerk kannst du es egal in welchem Netzwerk betreiben solange der SIP Server routingtechnisch erreichbar ist. Dem Telefon ist das ja egal....
IP technisch bekommt es aus dem Netzwerk in dem sich das Telefon befindet ja eine IP und eine Gateway IP. Damit kann es, egal in welchem IP Netz es ist, ja den Router und über das VPN das Zielnetz erreichen. In seiner SIP Konfig steht ja das SIP Ziel was das Telefon dann kontaktet und sich dort registriert.
Das kannst du am LAN Port der pfSense auch wunderbar checken mit der Packte Capture Funktion im Diagnostics Menü wenn du dort mal nach Port 5060 snifferst !
Ein "Bug" in dem Sinne ist das nicht es ist vermutlich ein Konfig Fehler deinerseits.
Wie bereits oben gesagt. Mit 3 mal 7981er Telefonen an zwei per IPsec IKEv2 gekoppelten pfSense und einer FritzBox als SIP Server rennt das fehlerlos. Ob OpenVPN oder IPsec ist dabei völlig egal.

Das ist eine gute Frage, die man aber nur beantworten kann wenn man die genaue Topologie deines Netzwerkes kennt.
Der Haben mit der Anmeldung über das Internet auf der FritzBox besagt einzig nur das diese dann eingehende SIP Verbindung auch vom Internet Port akzeptiert was sie ohne den Haken nicht macht. Dann akzeptiert sie eingehden SIP Connections rein nur vom LAN Interface weil sie davon ausgeht das das alles lokale VoIP (SIP) Endgeräte sind. Einfache Logik....
Nun aber komtm die Topologie mit dem OpenVPN ins Spiel.
Es ist jetzt essentiell wichtig zu wissen ob du die Firewalls in einem sog. "one armed" Szenario betreibst oder in einer Router_Kaskade mit der FritzBox ?!!
Bei einer Router Kaskade muss der SIP Traffic über das NAT Interface der Firewall um so die davor kaskadierte FB erreichen zu können. Man muss also deshalb das dortige Regelwerk auf dem Radar haben. Eine klassische VPN Verbindung, egal welches VPN Protokoll, geht ja immer davon aus das sich erreichbare Endgeräte im lokalen LAN befinden und nicht außerhalb der NAT Firewall. In sofern ist ein Kaskaden Design mit DAVOR liegendem SIP Server immer speziell.
Anders sähe es bei einem one_armed_Design aus, denn dort ist NAT außer Funktion.
Das VPN Design deines Setups ist also nicht trivial.

Egal was es bei dir ist solltest du in jedem Falle über die FritzBox Packet Cature Funktion einmal die SIP Frames der Telefone am LAN Port mitschneiden wie es HIER beschrieben ist und dir genau ansehen WAS und ob überhaupt dort der SIP Traffic der Telefone ankommt.
Generell weisst du ja auch das ein Kaskaden Design generell eine schlechte Lösung ist. Besse rist immer statt einer Router Kaskade ein dediziertes NUR Modem wie z.B. ein Vigor 165/167 oder ein Zyxel VMG3006 an der Firewall zu betreiben und die FritzBox nur als reine VoIP Anlage mit dem LAN Port ins lokale Netz zu hängen. Das löst dann schon designtechnisch alle Probleme.
So oder so bekommt man es mit entsprechendem Setup aber auch in einem Kaskaden Design problemlos zum laufen.

Was du aber immer absolut sicherstellen musst ist das sich die Telefone lokal IMMER fehlerfrei an der FritzBox anmelden. Das ist ja kinderleicht zu erreichen und sollte man immer VORHER verifizieren das SIP Connection und auch ein- und ausgehende Telefonate sauber funktionieren.
Wenn das der Fall ist weiss man IMMER ganz sicher das die SIP Verbindung auf die FritzBox sauber funktioniert. Ab dann ist es dann egal in welchem IP Netz die telefone arbeiten solange sie Routing technisch die FritzBox am LAN Port als SIP Server erreichen können.
Fazit:
Immer erst im LOKALEN die SIP Connectivity der Telefone auf die Ziel FB checken und dann erst weitermachen.

Eigentlich ist sie das. Du musst sie im Setup nur als einfaches IP Endgerät setzen und dann einfach nur mit einem der LAN Ports ins lokale LAN klemmen. Dann arbeitet sie als ganz einfache Telefonanlage.
Dieser_Artikel beschreibt genau so ein Szenario mit dem bordeigenen VPN. Generell ist das also ein simples VoIP Standard Design was ja in aktuellen Home Office Zeiten ja auch zig tausendfach genutzt wird von Home Office Arbeitern die einfach ihr VoIP Telefon auch von zuhause nutzen. Sei es mit einem Softphone oder einem Hardware Telefone.
Generell ist dein Setup also ein Klassiker und dabei ist es völlig unerheblich welches VPN Protokoll du einsetzt solange natürlich die Firewall Regelwerke an den Interfaces stimmen.
Wie man den Dynamic DNS Client an der pfSense einstellt ist eigentlich recht gut dokumentiert:
https://docs.netgate.com/pfsense/en/latest/services/dyndns/client.html
Du musst nicht zwingend einen kostenpflichtigen Dienst verwenden sondern kannst auch die kostenlosen Angebote nutzen wie z.B. die von https://www.dnshome.de/ oder https://desec.io/ und anderen.