03.08.2019

6998

Problem mit site 2 site VPN

Hallo zusammen,

ich habe folgendes Problem: Ich möchte 2 Standorte mit site 2 site VPN miteinander verbinden. Am Standort A steht ein pfSense zur Verfügung, wo ein openVPN-Server verfügbar ist. Am Standort B habe ich einen openWRT-Router, wo der openVPN-Client läuft. Das ganze funktioniert schon so weit, dass ich von Standort B auf das komplette Netz von Stanort A zugreifen kann. Was jedoch nicht geht ist, dass die Clients von Standort A auf Standort B zugreifen können. Ich kann nichtmal den openWRT-Router von Standort B pingen

Ich kann vom Standort A nur die vpn-IP vom openWRT pingen, dann stehe ich an.

Was muss ich machen, dass ich den einen Schritt noch weiter komme, damit ich vom VPN-Netz ins LAN vom Standort B komme?

LG, Dextha

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 481363

Url: https://administrator.de/forum/problem-mit-site-2-site-vpn-481363.html

Ausgedruckt am: 22.12.2024 um 06:12 Uhr

30 Kommentare

Neuester Kommentar

Hallo,

Firewallregeln?

Diese hätte ich am openWRT erstellt:
Any traffic -> From any host in VPN -> To any host in lan

Auf der pfSense darf das LAN auch überall hin. Route ist auf der pfSense auch angelegt:
Destination Gateway Flags Use Mtu Netif
192.168.1.0/24 10.1.2.2 UGS 0 1500 ovpns2

Das Netzwerk 192.168.1.0/24 ist das auf Standort B. 10.1.2.2 ist die IP, welcher der openVPN-Client auf Standort B hat.

Musst du auf beiden Seiten.

Ja, das meinte ich eh.... Firewallregeln sind auf beiden Firewalls korrekt angelegt. Für mich stellt sich nur die Frage, warum ich zwar vom Standort A noch die VPN-IP vom Standort B pingen kann, aber dann nicht mehr ins LAN vom Standort B komme....

Weil diese nicht passen, Routing kann es zwar auch sein, aber da ein Ping durchgeht eher nicht.

weiß jemand, ob man am openWRT die Firewall testweise deaktivieren kann? Ich find da nicht wirklich was raus, ob auf dieser was geblockt wird

Ich kann nichtmal den openWRT-Router von Standort B pingen

WAS kannst du da nicht pingen ??

Das LAN Interface ?
Die interne OpenVPN IP Tunneladresse ?

Letzteres solltest du in jedem Falle pingen können !!

Was sagt denn die Routing Tabelle in der pfSense ? Taucht dort das OpenWRT LAN auf und wird in den Tunnel geroutet ?
Was sagt analog dazu die Routing Tabelle (netstat -r) auf der OpenWRT Seite (SSH Zugang, siehe Tutorial !) ?? Hier müssen die gleichen Routen zu sehen sein !
Hast du an der pfSense die entsprechenden Firewall Regeln im virtuellen Tunnel Interface eingetragen. Ggf. erstmal zum Testen eine any any Schrotschussregel ?

Alle diese Angaben fehlen leider in der Beschreibung...

Wie immer findest du Tips zum OpenVPN Troubleshooting unter OpenWRT hier im Tutorial:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Generell funktioniert das fehlerfrei !

Moin,

Was versuchst du denn anzusingen?
Ne Windows-Kiste?
Wenn ja: du kommst für die Client-Firewall aus einem fremden Netz. Wenn du die nicht angepasst hast, bist du dann mit deinem ICMP-Paket eine potentielle Gefahr und wirst geblockt.

Teste mal, in dem du einen Drucker oder so etwas als Ziel anpingst...

Gruß
em-pie

Hi!

Ja, das LAN-Interface vom openWRT kann ich nicht pingen. die IP des openVPN-Tunnes kann ich am openWRT pingen.

Die Routing-Tabelle in der pfSense hat den Eintrag für das Netz am openWRT:
Destination Gateway Flags Use Mtu Netif
192.168.1.0/24 10.1.2.2 UGS 0 1500 ovpns2

192.168.0.1/24 -> Netz am Standort B
10.1.2.2 -> IP des openVPN-Tunnels am openWRT

Am openWRT hab ich den Eintrag in der Routing-Tabelle so aber nicht:

Destination Gateway Genmask Flags MSS Window irtt Iface
default 192.168.8.1 0.0.0.0 UG 0 0 0 eth0.2
10.1.2.0 * 255.255.255.0 U 0 0 0 tun0
10.204.71.0 192.168.1.254 255.255.255.0 UG 0 0 0 br-lan
172.20.1.0 10.1.2.1 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 * 255.255.255.0 U 0 0 0 br-lan
192.168.8.0 * 255.255.255.0 U 0 0 0 eth0.2

172.20.1.0/24 -> Netz am Standort A
192.168.8.0 -> Default Gateway auf Standort B
192.168.1.0/24 -> 1. Netz auf Standort A
10.204.71.0/24 -> 2. Netz auf Standort B

Ja, einen any - any - Regel hab ich testweise auf beiden Seiten erstellet - leider ohne Erfolg.

Was versuchst du denn anzusingen?

Das nützt bei Winblows auch nix mehr...!

Kollege @em-pie hat aber Recht, denn dort lauert noch die lokale Winblows Firewall die generell ICMP Pakete (Ping) blockt !
Das musst du also erstmal erlauben in den Settings:
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...

Das LAN Interface des OpenWRT muss aber so oder so auch ohne Wonblows Firewall IMMER pingbar sein !

die IP des openVPN-Tunnes kann ich am openWRT pingen.

Das ist schon mal gut und besagt das der VPN Tunnel sauber funktioniert.
Der Client propagiert ja auch sein Netz wie man an der Routing Tabelle in der pfSense ja sehen kann ! Das iseht also gut aus...
Leider hast du nichts zu den Firewall Regeln im virtuellen OVPN Tunnel Interface auf der pfSense gesagt

Hast du dort eine Regel für das 192.168.1.0er netz erstellt ? Oder eine ANY ANY Schrotschussregel ?
Ein Screenshot wäre hier hilfreich gewesen...

Am openWRT hab ich den Eintrag in der Routing-Tabelle so aber nicht:

Das stimmt vermutlich NICHT !! Ist das 172.20.1.0er /24 Netz das lokale LAN an der pfSense ??
Wenn ja dann stimmt doch der Routing Tabellen Eintrag:
172.20.1.0 10.1.2.1 255.255.255.0 UG 0 0 0 tun0
Wenn 10.1.2.0 /24 das OVPN interne IP Netz ist, dann ist die .1 immer der OVPN Server selber. Die Route besagt also das das 172.20.1.0er Netz über das Gateway 10.1.2.1 am Tunnel Interface erreichbar ist, was ja dann richtig ist.
Ist dem so, ist also routingtechnisch alles ok.
Ein traceroute 172.20.1.1 zum pfSense LAN Interface zeigt dir das dann auch sofort ! Traceroute zeigt dir alle Routing Hops an und ist ein sinnvolles Troubleshooting Tool auf beiden Seiten.

Der Fehler kann dann einzig und allein nur an der OpenWRT Firewall liegen, das die Pakete mit 192.168.1.0er IP Zieladressen blockiert.
Kannst du vom OpenWRT SSH Kommandoprompt Endgeräte im lokalen pfSense LAN (geraten 172.20.1.0 /24) anpingen ?? Das würde die Theorie des Firewall Problems im OpenWRT bestätigen.
Im Open VPN Tutorial gibts vom User @Spirit ein paar Anmerkungen dazu:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router

Vom openWRT kann ich alle Rechner im 172.20.1.0er Netz pingen -> nur vom 172.20.1.0er-Netz kommt nichts zum 192.168.1.0 (auch nicht zu anderen Rechnern in dem Netz). Also eine Einbahn....

Auf der pfSense habe ich mal Schrotschussregel erstellt:

Mit tracert hätt ich mir das auch schon angeschaut.

... da komm ich nicht weit.

Hier noch die Regel am openWRT:

Wobei ich da nur das Interface angeben kann, welches in der Gui keine IP hat, sondern nur als tun0 definiert ist.

Also eine Einbahn....

Und damit klar das rein nur noch die OpenWRT Firewall der böse Buhmann ist !

Mit tracert hätt ich mir das auch schon angeschaut.

Auch mal von der pfSense aus dem Diagnostics menü indem du die Source IP vorgibst ?
Sinnvoll wäre das mal von der OpenVPN Source IP zu machen.

Gui keine IP hat, sondern nur als tun0 definiert ist.

Das ist das OpenVPN Tunnel Interface. Das sollte aber schon eine IP haben wie üblich unter OpenVPN. Möglich aber das die nicht angezeigt wird....
Ist das alles was man bei OpenWRT dort definieren kann was oben zu sehen ist ??

Über ssh kann ich die IP des VPN-Tunnels schon sehen, nur in der GUI nicht.

Ich habe jetzt noch zusätzlich folgende custom-Firewall-Regeln eingebaut in openWRT:

iptables -I INPUT -i tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -j ACCEPT
iptables -I OUTPUT -o tun0 -j ACCEPT
iptables -I FORWARD -o tun0 -j ACCEPT

Damit kann ich von 172.20.1.0/24er Netz auch auf die GUI vom openWRT-Router zugreifen, aber nur über die vpn-IP

Auf die IP des LAN-Interface kann ich ums verrecken nicht zugreifen. Ich dreh schon langsam durch....

Ich hoffe ihr habt noch ein paar gute Tipps für mich!

Ist es ggf. möglich das du NAT (Masquerading) auf dem Tunnel Interface aktiv hast ??
Das darf natürlich nicht sein, denn sonst hast du eine Routing Einbahnstraße !!
Auch das würde erklären warum es in eine Richtung geht aber in die andere nicht !!
NAT Masquerading muss bei OpenWRT auf alle Fälle deaktiviert sein auf dem Tunnel Interface !
Checke auch nochmal die korrekte Konfig (Client Konfig) das dort das iroute Kommando enthalten ist für das lokale LAN:
https://community.openvpn.net/openvpn/wiki/RoutedLans

Hier gibts noch Tips zur Firewall:
https://openwrt.org/docs/guide-user/services/vpn/openvpn/basic
https://www.it-management-kirchberger.at/manuals-tutorials/netzwerk/open ...

Hallo!

Vielen Danke für deine Info! NAT war aktiv - hab ich jetzt deaktiviert, jedoch ist das Problem unverändert.

Wegen iroute: Ich war der Meinung, dass diese Funktion nur für mehrere Clients benötigt wird, wenn diese auch untereinander kommunizieren sollen... Ich würde es aber trotzdem gern versuchen, weiß aber nicht, wie ich das in pfSense einbauen soll.... Die Einstellungen dafür gehören ja am Server gesetzt oder?

LG, Dex

... das ist jetzt eine sehr openWRT-spezifische Frage: Aber wenn ich ein site2site-VPN habe und die Firewall-Regeln auf tun0 auhänge -> wie ist das dann? tun0 ist ja eigentlich nur das VPN-Netz und nicht das Netz auf der anderen Seite des Tunnels gegenüber oder?

Wie erstell ich dann die openWRT-Firewallregel, dass das Netz am anderen Standort auf ein LAN des openWRTs zugreifen kann?

Das Tunnel Interface ist das Interface was den internen Traffic behadelt. Stelle dir das Tunnel Interface vor wie eine interne Standleitung zwischen deinen internen IP Netzen. Das inkludiert auch das interne OpenVPN Netz.
Hier darf natürlich niemals NAT gemacht werden, denn dann kannst du zwischen deinen internen Netzen nicht mehr transparent routen. Routing wäre dann eine Einbahnstrasse die nur vom Client in Richtung Server geht aber nie andersrum weil das die NAT Firewall verhindert.
Deshalb muss NAT intern auf dem Tunnel Interface immer aus. Im Normalfall ist das auch immer so.
Ggf. solltest du die Server Konfig nochmal mit dem iroute Kommando erweitern.
Lies mal hier was da steht zum Thema "LAN eines Clients einbeziehen"
https://wiki.ubuntuusers.de/OpenVPN/
Ansonsten muss ich mal meinen ollen TP-Link 841 mit OpenWRT rauskramen und das nachstellen...

Ich habe jetzt via ssh die Einstellungen auf der sfSense gemacht und am Client (openWRT) den ccd-Folder mit einem entsprechenden client-File (iroute 192.168.1.0 255.255.255.0) erstellt. Leider wieder ohne besserung

Ich wäre dir sehr dankbar, wenn du das bei dir mal versuchen kannst, nachzustellen. Viel Dank!!!!

LG, Dex

In eine Richtung klappt der Zugriff ja, richtig ?
Kannst du mal auf dem Zielrechner den du remote anpingst einen Wireshark Sniffer mitlaufen lassen und dir die ICMP (Ping) Absenderpakete mal ansehen ?
Mit welcher Absender IP kommen die am Ziel an ??
Nur um nochmal ganz sicherzustellen das da im Tunnel wirklich das Masquerading deaktiviert ist !
Wenn du einen SSH Zugang auf den OpenWRT hast kannst du zusätzlich mal ein sudo iptables -S dort eingeben und mal checken welche Rules da aktiv sind.
Ich krame mal den 841n raus

Hier mal die iptables -S Ausgabe:

root@OpenWrt:~# iptables -S
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N forwarding_lan_rule
-N forwarding_rule
-N forwarding_vpn_rule
-N forwarding_wan_rule
-N input_lan_rule
-N input_rule
-N input_vpn_rule
-N input_wan_rule
-N output_lan_rule
-N output_rule
-N output_vpn_rule
-N output_wan_rule
-N reject
-N zone_lan_dest_ACCEPT
-N zone_lan_forward
-N zone_lan_input
-N zone_lan_output
-N zone_lan_src_ACCEPT
-N zone_vpn_forward
-N zone_vpn_input
-N zone_vpn_output
-N zone_wan_dest_ACCEPT
-N zone_wan_dest_REJECT
-N zone_wan_forward
-N zone_wan_input
-N zone_wan_output
-N zone_wan_src_REJECT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -i lo -m comment --comment "!fw3" -j ACCEPT  
-A INPUT -m comment --comment "!fw3: Custom input rule chain" -j input_rule  
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT  
-A INPUT -p icmp -m icmp --icmp-type 8 -m comment --comment "!fw3: Allow-Ping-VPN" -j ACCEPT  
-A INPUT -i br-lan -m comment --comment "!fw3" -j zone_lan_input  
-A INPUT -i tun0 -m comment --comment "!fw3" -j zone_wan_input  
-A INPUT -i eth0.2 -m comment --comment "!fw3" -j zone_wan_input  
-A FORWARD -o tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -m comment --comment "!fw3: Custom forwarding rule chain" -j forwarding_rule  
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT  
-A FORWARD -i br-lan -m comment --comment "!fw3" -j zone_lan_forward  
-A FORWARD -i tun0 -m comment --comment "!fw3" -j zone_wan_forward  
-A FORWARD -i eth0.2 -m comment --comment "!fw3" -j zone_wan_forward  
-A FORWARD -m comment --comment "!fw3" -j reject  
-A OUTPUT -o tun0 -j ACCEPT
-A OUTPUT -o lo -m comment --comment "!fw3" -j ACCEPT  
-A OUTPUT -m comment --comment "!fw3: Custom output rule chain" -j output_rule  
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT  
-A OUTPUT -o br-lan -m comment --comment "!fw3" -j zone_lan_output  
-A OUTPUT -o tun0 -m comment --comment "!fw3" -j zone_wan_output  
-A OUTPUT -o eth0.2 -m comment --comment "!fw3" -j zone_wan_output  
-A reject -p tcp -m comment --comment "!fw3" -j REJECT --reject-with tcp-reset  
-A reject -m comment --comment "!fw3" -j REJECT --reject-with icmp-port-unreachable  
-A zone_lan_dest_ACCEPT -o br-lan -m comment --comment "!fw3" -j ACCEPT  
-A zone_lan_forward -m comment --comment "!fw3: Custom lan forwarding rule chain" -j forwarding_lan_rule  
-A zone_lan_forward -m comment --comment "!fw3: Zone lan to wan forwarding policy" -j zone_wan_dest_ACCEPT  
-A zone_lan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT  
-A zone_lan_forward -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT  
-A zone_lan_input -m comment --comment "!fw3: Custom lan input rule chain" -j input_lan_rule  
-A zone_lan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT  
-A zone_lan_input -m comment --comment "!fw3" -j zone_lan_src_ACCEPT  
-A zone_lan_output -m comment --comment "!fw3: Custom lan output rule chain" -j output_lan_rule  
-A zone_lan_output -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT  
-A zone_lan_src_ACCEPT -i br-lan -m conntrack --ctstate NEW,UNTRACKED -m comment --comment "!fw3" -j ACCEPT  
-A zone_wan_dest_ACCEPT -o tun0 -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP  
-A zone_wan_dest_ACCEPT -o tun0 -m comment --comment "!fw3" -j ACCEPT  
-A zone_wan_dest_ACCEPT -o eth0.2 -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP  
-A zone_wan_dest_ACCEPT -o eth0.2 -m comment --comment "!fw3" -j ACCEPT  
-A zone_wan_dest_REJECT -o tun0 -m comment --comment "!fw3" -j reject  
-A zone_wan_dest_REJECT -o eth0.2 -m comment --comment "!fw3" -j reject  
-A zone_wan_forward -m comment --comment "!fw3: Custom wan forwarding rule chain" -j forwarding_wan_rule  
-A zone_wan_forward -p esp -m comment --comment "!fw3: Allow-IPSec-ESP" -j zone_lan_dest_ACCEPT  
-A zone_wan_forward -p udp -m udp --dport 500 -m comment --comment "!fw3: Allow-ISAKMP" -j zone_lan_dest_ACCEPT  
-A zone_wan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT  
-A zone_wan_forward -m comment --comment "!fw3" -j zone_wan_dest_REJECT  
-A zone_wan_input -m comment --comment "!fw3: Custom wan input rule chain" -j input_wan_rule  
-A zone_wan_input -p udp -m udp --dport 68 -m comment --comment "!fw3: Allow-DHCP-Renew" -j ACCEPT  
-A zone_wan_input -p icmp -m icmp --icmp-type 8 -m comment --comment "!fw3: Allow-Ping" -j ACCEPT  
-A zone_wan_input -p igmp -m comment --comment "!fw3: Allow-IGMP" -j ACCEPT  
-A zone_wan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT  
-A zone_wan_input -m comment --comment "!fw3" -j zone_wan_src_REJECT  
-A zone_wan_output -m comment --comment "!fw3: Custom wan output rule chain" -j output_wan_rule  
-A zone_wan_output -m comment --comment "!fw3" -j zone_wan_dest_ACCEPT  
-A zone_wan_src_REJECT -i tun0 -m comment --comment "!fw3" -j reject  
-A zone_wan_src_REJECT -i eth0.2 -m comment --comment "!fw3" -j reject  

Wireshark:
Ich konnte gerade nur vom openWRT (192.168.1.199) durch den Tunnel auf den PC (172.20.1.12) im pfSense-Netz pingen, weil der Client im openWRT-Netz aktuell nicht läuft. Reicht das schon? Sonst kann ich gern morgen nochmal von einen Ping vom Client durch Tunnel zu Client machen.

Das reicht. Ist die .1.199 die LAN IP Adresse des OpenWRT ??
Wenn ja zeigt das eindeutig das das Masquerading im Tunnel deaktiviert ist.
Hattest du jetzt im WS nach Requests gefiltert ?? Oder warum wird der ICMP Reply des PC mit der 172.20.1.12 nicht angezeigt ?

Mist eben mal den 841n mit OpenWRT angeschlossen... Der hat zuwenig Flash frei um das OpenVPN Package zu installieren.

Da muss ich erstmal operieren:
https://www.heise.de/select/ct/2019/14/1561986310067151
Ich warte noch auf das RAM aus Chinesien...

Kennst du (oder jemand anderes hier) ein anderes Modell was in der Preisrange liegt und OpenWRT mit OpenVPN kann, also entsprechend Flash hat ?? Die ollen Linksys WRT54er die hier rumliegen haben noch weniger...
Ansonsten kannich nur noch einen GL.inet Router anbieten. Da rennt auch OpenWRT drauf ist aber ja nicht exakt das gleiche aber einen Versuch sicher wert.

Ja genau, 192.168.1.199 ist die IP des openWRT.
Im wireshark hab ich auf ICMP gefiltert, deswegen sind nur diese Einträge drin.

Oh, das ist schade, dass das mit deinem 841n nicht geht

Ich habe dort einen TP-LINK Archer C7 in Verwendung - der funktioniert (bis auf mein Problem) vervorragend.

LG, Dex

Im Wireshark hab ich auf ICMP gefiltert, deswegen sind nur diese Einträge drin.

Das kann eigentlich nicht sein, denn wenn man lediglich auf "ICMP" filtert zeigt das alles an was zum ICMP gehört und das umfasst natürlich dann Echo Requests und auch Echo Replies. Folglich müsste man also auch die Antwort (Echo Reply) des angepingten Wireshark Rechners sehen ?!
Es sei denn du hast auch auf die IP oder Mac des Rechners gefiltert ?!

Hab noch einen GL.inet_Router gefunden im Fundus, der hat OpenWRT und auch OpenVPN drauf...

Und...eben das Szenario mal nachgestellt. Lässt sich reproduzieren mit OpenWRT !

Loggt man sich auf dem OVPN Server mit einem Windows- oder RasPi Client ein kann man das OVPN Tunnel Interface und das LAN Interface pingen und das beidseitige Routing klappt fehlerfrei.
Klar, denn diese Clients machen eben kein NAT im Tunnel !
Beim OpenWRT Client mit identischer client.conf Datei geht beides nicht. WTF...

Man kann auch ganz klar sehen das der OpenWRT Router hier zwangsweise NAT macht im Tunnel.

22:19.073556 IP 10.8.8.2 > 192.168.199.210: ICMP echo request, id 1, seq 35, length 40
22:19.073751 IP 192.168.199.210 > 10.8.8.2: ICMP echo reply, id 1, seq 35, length 40
22:20.091227 IP 10.8.8.2 > 192.168.199.210: ICMP echo request, id 1, seq 36, length 40
22:20.091427 IP 192.168.199.210 > 10.8.8.2: ICMP echo reply, id 1, seq 36, length 40 

10.8.8.0 ist hier das interne OVPN IP Netz. .1 der Server und .2 der OpenWRT Router.
.199.0 /24 ist das lokale LAN und die .210 ein Host dort.
Das lokale LAN am OpenWRT Router ist 192.168.8.0 /24 mit einem Host .150. Wie man sieht taucht dessen IP aber gar nicht auf sondern nur die geNATete IP mit dem OpenWRT Tunnel Interface.

Diese Richtung klappt also, klar denn das ist NAT outbound.
Andere Richtung kann dann aber nie klappen, denn das bleibt trotz richtigem Routing dann an der NAT Firewall des OpenWRT Tunnel Interfaces hängen.

OpenWRTist also rein nur für einen simplen Client Zugriff vordefiniert nicht aber für ein beidseitiges LAN zu LAN.
Fragt sich jetzt wie man das Masquerading im Tunnel deaktiviert bekommt beim OpenWRT ?
Die iptables sagen so erstmal nix, aber das aits auch klar, das ist irgendwie in den Zonen definiert.
Nun gehts ans Forschen wie man das entfernt...

Hallo!

Vielen Dank für deine Bemühungen!

Ich habe zwischenzeitlich auch weiter getestet und konnte auch was interessantes feststellen: Ich habe einen 3. Standort hinzu gezogen, auf dem Sophos läuft. Auf diesen habe ich eine open-vpn site to site - Serververbindung eingestellt. Mit dem openWRT kann ich mit site 2 site auf die Sophos hin verbinden und siehe da -> es funktioniert in beide Richtungen!!!! Ich bin jetzt gerade dabei die openvpn-Configs der Sophos und der pfSense zu vergleichen, da ich ja Firewall-Seitig auf der pfSense keine Blocks erkennen kann.

LG, Dex

Es liegt aber ganz sicher nicht am OpenVPN Server, sprich also der zentralen Firewall. Es ist ja offensichtlich das das OpenWRT im Tunnel Interface NATet und damit ist immer eine Routing Verbindung eine Einbahnstrasse da man ja von außen dann nicht das NAT Interface überwinden kann ohne gültigen Eintrag in der NAT Translation Table.
Ich habe jetzt gesehen das die Firewall Konfig und speziell die Zonen Konfig irgendwo unter /etc/firewall steht.
Da forsche ich heute nochmal etwas...

Das hab mich so in den Griff bekommen:

iptables -I INPUT -i tun+ -j ACCEPT
iptables -I FORWARD -i tun+ -j ACCEPT
iptables -I OUTPUT -o tun+ -j ACCEPT
iptables -I FORWARD -o tun+ -j ACCEPT

Ich glaub ich stehe kurz vor der Lösung. Ich bin mir ziemlich sicher, dass es, wie hier schon bermutet, an iroute liegt....

LG, DEx

Hatte ich noch vergessen oben....
Die OVPN Server Konfig sieht so aus (Auszug):
server 10.8.8.0 255.255.255.0
topology subnet
push "topology subnet"
push "route 192.168.199.128 255.255.255.128"
route 192.168.8.0 255.255.255.0
client-config-dir /etc/openvpn

Im Client Konfig Directory /etc/openvpn ist dann eine Datei "client1" (Das ist der Common Name des OpenWRT OVPN Clients) die dann noch Client spezifische Routing Kommandos addiert wenn der Client mit dem Comman Name "client1" sich einwählt:
iroute 192.168.8.0 255.255.255.0
ifconfig-push 10.8.8.2 255.255.255.0

Das Kommando route 192.168.8.0 255.255.255.0 im Server Hauptteil sorgt dafür das das Client Netz auch in der Kernel Routing Tabelle des OVPN Servers steht.
Im Client spezifischen Teil sorgt iroute 192.168.8.0 255.255.255.0 dafür das OpenVPN diese Route für den Client bei seiner Einwahl implementiert und ifconfig-push 10.8.8.2 255.255.255.0 das dieser Client immer eine feste IP 10.8.8.2 zugewiesen bekommt im internen OVPN IP Netz. Wäre das dynamisch kann die Route bei einer Neueinwahl verloren gehen.

Ohh man.... Manchmal hat man auch als Netzwerker Tomaten auf den Augen ! Passiert im Eifer des Gefechts ja mal.
Aber heute ist ja zum Glück Freitag...!

Die Lösung liegt eigentlich auf der Hand und ist kinderleicht ! (Wenn man denn mal in Ruhe nachdenkt...

)

Bei OpenWRT ins Firewall Setup gehen, dort die Interfaces ansehen und...
Haken bei Masquerading am OVPN Tunnel Interface entfernen !!

Save & Apply klicken... Und "Tadaaa" kein NAT mehr im Tunnel und schon klappt auch der Ping und Zugriff in die andere Richtung sofort !!

Ethernet-Adapter LAN-Verbindung:

   Verbindungsspezifisches DNS-Suffix: lan
   IPv6-Adresse. . . . . . . . . . . : fdbf:d64d:5b35:10::21d
   Verbindungslokale IPv6-Adresse  . : fe80::f488:debb:2cdf:f237%19
   IPv4-Adresse  . . . . . . . . . . : 192.168.8.173
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 192.168.8.1

C:\Windows\User>ping 192.168.199.100

Ping wird ausgeführt für 192.168.199.100 mit 32 Bytes Daten:
Antwort von 192.168.199.100: Bytes=32 Zeit=3ms TTL=126
Antwort von 192.168.199.100: Bytes=32 Zeit=3ms TTL=126
Antwort von 192.168.199.100: Bytes=32 Zeit=4ms TTL=126

Ping-Statistik für 192.168.199.100:
    Pakete: Gesendet = 3, Empfangen = 3, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 3ms, Maximum = 4ms, Mittelwert = 3ms 

(.199.100 ist ein Web_Server im lokalen LAN der pfSense. Die .8.1 ist der OpenWRT Router und die .8.173 der Laptop im lokalen OpenWRT LAN.)
Es kann ja alles so einfach sein...!

Case closed.