OpenVPN 2. Standort kommt nicht ins Hauptnetz

Deine Schilderung ist etwas verwirrend da du einmal die mobilen Clietns beschreibst und einmal den 2.Standort. Also erstmal sortieren damit wir es verstehen:

• Mobile Clients mit OVPN können sich am Server Hauptnetz anmelden und alles pingen ?!
• 2.ter Standort macht ein Site to Site VPN um die netze zu koppeln, richtig ?
• 2ter Standort kann weder das interne OVPN IP Netz erreichen noch das Hauptnetz 192.168..0.0 /24, richtig ?

Dazu 2 Fragen:

• Kannst du anhand der pfSense Logs sicherstellen das sich der 2te Standort erfolgreich verbinden kann, bzw. siehst du eine "Success" Meldung im Log ?

Das ist wichtig um überhaupt erstmal zu klären ob Zertifikate, Passwörter usw. stimmen und der Tunnel überhaupt als solches zustande kommt !!
Dadurch das du die interne IP nicht pingen kannst bestehen da Zweifel....

• Achtung: Es sieht so aus als ob du hier eine Router Kaskade mit der Easybox betreibst ?? Ist dem so ?

Wenn ja musst du hier unbedingt den OVPN Port UDP 1194 auf die am LAN angeschlossene WAN IP 192.168.2.x der pfSense hier per Port Forwarding forwarden ! Machst du das nicht kommt erst gar kein OVPN Traffic durch:
Siehe Tutorial hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Weitere zwingende ToDos in einer solchen Kaskade:

• PfSense WAN Port sollte eine statische IP außerhalb der DHCP Range der Easybox haben ! Das ist zwingend denn solltest du DHCP verwenden und sich die IP durch die DHCP Dynamik einmal ändern an der pfSense, denn geht dein Port Forwarding für den OVPN Traffic auf der Easybox ins Nirwana und dein VPN steht ! Hier also immer statisch arbeiten !
• Im General Setup der pfSense am WAN Port den Haken bei Block RFC 1918 IP networks entfernen !
• Eine Firewall Regel erstellen die von Source Any auf Destination pfSense WAN IP address den Destination Port UDP 1194 und Source Port Any erlaubt !!

Damit erlaubst du generell OVPN Traffic auf die WAN IP der pfSense.
Das alles musst du als erstes sicher verifizieren. Kommt der Tunnel durch ggf. Fehler gar nicht zustande sind die folgenden Schritte natürlich obsolet !
Weiter....

• Ist ersteres sichergestellt, hast du auf beiden Firewalls ein virtuelles OVPN Interface (Tunnelinterface) über die der Traffic zw. den Standorten rennt ! Hier musst du sicherstellen das einen entsprechende Firewall Regel existiert die hier allen Traffic mit Source IP 192.168.0.0 /24 nach Destination IP 172.17.0.0 /24 Protokoll "Any" erlaubt. (Hauptstandort)

Analog am 2ten Standort: Traffic mit Source IP 172.17.0.0 /24 nach Destination IP 192.168.0.0 /24 Protokoll "Any"
Als Tip immer ins Firewall Log sehen ob da was geblockt wird. Ggf. das Log vorher löschen.
Am Hauptstandort klappt es ja schon denn da können die Clients ja arbeiten ?!

• Thema Firewall: Sollte der Tunnel klappen kommst du im Hauptstandort Netz und analog auch am 2ten Standort mit einer fremden Absender IP an. Fast alle Firewalls aller Betriebssysteme blocken das per Default wenn dort Absender IPs auftauchen die nicht aus dem lokalen IP Netz kommen. Beachte das und passe die lokalen Firewalls entsprechend an !

Zum Testen ist es erstmal sinnvoller ein Endgerät in diesen Netzen zu pingen das keine Firewall hat wie z.B. ein Drucker.
Auch hier darauf achten das dieses Gerät ein Default Gateway definiert hat das immer auf den lokalen pfSense LAN Port zeigt !

Wenn du das alles beachtest kommt das auch sofort zum fliegen.

Das ist jetzt etwas verwirrend.... Wie meinst du das ?
Wenn du im Ping Tool der pfSense als Source IP das OVPN Interface nimmst und als Destination die LAN IP des Hauptstellennetzes geht es.
Mit der Außenstellen LAN IP als Source aber nicht ??
Das bitte mal genauer ??
Hast du an der Aussenstelle ein push route 172.17.0.0 /24 in die OVPN Konfig eingetragen ??
Wenn die Außenstellen pfSense eingewählt ist in der Hauptstelle WAS sagt die Routing Tabelle der Hauptstellen pfSense ??
Ist dort das Netz 172.17.0.0 /24 vorhanden ? Das muss zwingend sein !
Klick auf "Diagnostics -> Routes" !
Das ist auch unmöglich, denn die 10.0.8.1 müsste die interne OVPN Server IP sein und das müsstest du auch sehen unter der Routing Tabelle. Als Gateway steht da "link#xyz" !
Da fehlen die Routen vermutlich. Die musst du aber nicht statisch definieren sondern sollten dynamisch bei OVPN propagiert werden.
Ein Route Tabel Posting beider FWs wäre hilfreich mit aktiver OVPN Site to Site Session.

Das sieht sehr gut aus ! Wie du ja selber sehen kannst hat die Nebenstellen pfSense im Tunnel die IP 10.0.8.2 und die Route in das dortige lokale LAN 172.17.0.0 /24 ist angelegt.
In der Hauptstelle also alles gut. Sofern du ICMP (Ping) auf dem lokalen LAN und Tunneladapter in den FW Regeln erlaubt hast solltest du von der Hauptstellen pfSense mit der Absender IP lokal LAN die 10.0.8.2 und auch die 172.17.0.x Adresse der nebenstellen pfSense pingen können.

Vice versa musst du dir auch mal die Routing Tabelle der nebenstellen pfSense ansehen ! Dort sollte ein analoger Eintrag sein:
Zielnetz: 192.168.0.0 /24 Gateway: 10.0.8.1
Auch von da muss dan das remote Tunnel Interface und LAN Interface der Hauptstellen pfSense pingbar sein. Auch nur wenn in den Interface FW Regeln ICMP als Protokoll erlaubt ist !!
OK, sehr wichtige Info !
Dort müssen 2 statische Routen eingetragen werden:
Zielnetz: 172.17.0.0/24, Gateway: 192.168.0.x (die Pfsense im Hauptnetzwerk)
und
Zielnetz: 10.0.8.0/24, Gateway: 192.168.0.x (die Pfsense im Hauptnetzwerk)
ACHTUNG: sofern du am LAN Port eine Firewall Regel hast die inbound NUR das LAN Netzwerk 192.168.0.0 /24 mit Ziel ANY erlaubst, dann MUSST du logischerweise noch eine Firewall Regel hinzufügen die Inbound auch Pakete fürs 172er und 10er Netz erlauben !!!
Klar sonst blockt die FW alles was nicht 192.168.0.0 ist !
Checke also in jedem Falle deine Regeln sowohl am LAN Port als auch am virtuellen Tunnel Port !!
Generell gilt eine FW blockt alles was du nicht explizit erlaubt hast !!
Denk dabei auch an die lokalen Firewalls auf den Endgeräten im LAN. Du kommst jetzt bei der remoten Seite immer mit anderen Absender IPs ! Normal blocken alle Firewalls das was eben nicht lokal ist.
Nimm zum Ping Test dann besser einen Drucker oder irgendein anderes Endgerät was keine lokale Firewall hat um das auszuschliessen.

Im Zweifel siehst du dazu immer in das Firewall Log der pfSense ! Die listet dort akribisch auf WAS sie WO blockt so das du darauf reagieren kannst sollten interne IP des 172er und 10er Netze irgendwo geblockt werden !
Am besten das FW Log vorher löschen und dann einen Connect Versuch machen, dann siehst du das sofort !

Warum auch als Gateway ? Sie ist ja direkt angeschlossen...
Das du die 10.0.8.1 der Standort pfSense nicht pingen kannst liegt vermutlich an einer fehlenden Firewall Regel auf dem Tunnel Interface ?!
Bei einem Testaufbau hier klappt das fehlerlos !
Wie sieht die Routing Table an der Standort pfSense aus ?? Ist dort das Netz 192.168.0.0 /24 vertreten ?
Wenn nicht kannst du es auch erzwingen mit dem Eintrag route 192.168.0.0 255.255.255.0; in der Konfig. Es sollte aber auch so auftauchen !

Das ist klar, denn die IP liegt ja auf der Hauptnetz pfSense selber ! Kannst du die von jeglichem Gerät aus im Hauptnetzz anpingen die den Lancom als Default Gateway eingetragen haben ?
Das ist die Tunnel IP der Nebenstellen pfSense ! Das diese IP in der Routing Tabelle der Hauptstellen pfSense steht zeigt das eine funktionierende OVPN Verbindung besteht, denn sonst würde das nicht dynmaisch eingetragen worden !
Das du sie nicht pingen kannst kann eigentlich nur daran liegen das die FW Regeln auf dem internen Tunnel Interface ICMP (Ping) blocken. Eine andere Erklärung gibt es nicht.