Routing Openvpn über LTE und Fritzboxen
-
NAT und Port Regeln sind angelegt?
Was für ein OpenVPN ist es, tap oder tun?Und die meisten Antworten kommen hier in der Woche, wenn die ITler sich auf der Arbeit langweilen. Nicht wenn wir zuhause mit der Familie am rumtoben sind ;)
-
NAT und Port Regeln sind angelegt?
nein, sorry. Nur die vom Wizard gesetzten fw-rules auf 1194 UDP. Welche müssten das noch sein?
Was für ein OpenVPN ist es, tap oder tun?
tun
Und die meisten Antworten kommen hier in der Woche, wenn die ITler sich auf der Arbeit langweilen. Nicht wenn wir zuhause mit der Familie am rumtoben sind ;)
Da hast Du recht. ;)
-
Hi Peter,
Wir steigen momentan von ipfire auf pfsense (aktuelle Version) um.
…schön, dann wirst Du Dich ja erst mal etwas einarbeiten müssen und das ist nicht in 5 Minuten gemacht.
In der Zentrale ist openvpn am Kabeldeutschland-Anschluss als RAS SSL/TLS hinter einer Fritzbox cable über den Wizard eingerichtet, Remote wird von einem anderen Standort über LTE hinter einer Fritzbox 6842 und auch aktuellem pfsense als VPN-client darauf zugegriffen (LAN-LAN-Kopplung dürfte wohl wegen LTE auscheiden,
Die Zentrale hat eine feste IP oder Zumindest DynDNS, davon gehe ich aus und das reicht auch für eine LAN-to-LAN Kopplung!
Der Tunnel wird auch aufgebaut, allerdings ist bislang nur ein ping direkt über die shell aus der LTE-angebundenen pfsense auf die Zentrale möglich. Aus dem internen LAN zur Zentrale sind weder ping möglich noch fließen sonst Daten, aus der Zentrale ist gar kein Zugriff auf die Zweigstelle möglich, auch nicht direkt aus der pfsense.
Grundsätzlich brauchst Du, nur auf der Serverseitigen Fritte ein Portforwarding auf den Tunnelport / UDP.
Alle anderen Konfigurationsfehler, die Du gemacht hast, solltest Du mal hier nachlesen….
http://www.administrator.de/wissen/openvpn-server-installieren-dd-wrt-router-pfsense-firewall-123285.html
Wenn Du dann immer noch Fragen hast, solltest Du etwas mehr zu Deiner Config, Routingprotokolle, etc. posten.
Dein Szenario ist auf alle Fälle kein Problem, wenn´s richtig konfiguriert ist.. ;)
Gruß orcape -
…schön, dann wirst Du Dich ja erst mal etwas einarbeiten müssen und das ist nicht in 5 Minuten gemacht.
ok, hatte ich nicht erwähnt. Ich war bereits genau nach der von Dir genannten Anleitung http://www.administrator.de/wissen/openvpn-server-installieren-dd-wrt-router-pfsense-firewall-123285.html vorgegangen.
Hatte auch ein klein wenig länger als 5 Minuten gedauert ;D
Die Zentrale hat eine feste IP oder Zumindest DynDNS, davon gehe ich aus und das reicht auch für eine LAN-to-LAN Kopplung!
Dyndns auf beiden Seiten.
Grundsätzlich brauchst Du, nur auf der Serverseitigen Fritte ein Portforwarding auf den Tunnelport / UDP.
Das hatte ich doch eigentlich schon, indem ich die pfsense in die DMZ gepackt hatte, oder? Habe aber trotzdem nochmals auf beiden Fritten ein UDP-forward auf 1194 der pfsense gesetzt, nun gut.
Wenn Du dann immer noch Fragen hast, solltest Du etwas mehr zu Deiner Config, Routingprotokolle, etc. posten.
Was genau brauch ihr?
Dein Szenario ist auf alle Fälle kein Problem, wenn´s richtig konfiguriert ist.. ;)
Das hört sich doch gut an. Als wir die ipfires vor ein Paar Jahren aufgesetzt hatten, gab es schon Hürden (mithilfe des tollen ipfire-Forums) auf LTE-Seite zu umschiffen (obwohl das damals wohl u.a. auch an den LTE-Anfangsproblemen der Provider lag).
-
Zentrale-subnet: 172.23.1.0/24
Einwahl-client-subnet: 172.23.200.0/24
ovpn-subnet: 10.0.8.0/24Hier mal das ovpn-log von der Zentrale:
Mar 2 17:14:21 openvpn[33444]: Initialization Sequence Completed Mar 2 17:14:21 openvpn[33444]: IFCONFIG POOL: base=10.0.8.4 size=62, ipv6=0 Mar 2 17:14:21 openvpn[33444]: MULTI: multi_init called, r=256 v=256 Mar 2 17:14:21 openvpn[33444]: UDPv4 link remote: [undef] Mar 2 17:14:21 openvpn[33444]: UDPv4 link local (bound): [AF_INET]192.168.1.5:1194 Mar 2 17:14:21 openvpn[33444]: /sbin/route add -net 10.0.8.0 10.0.8.2 255.255.255.0 Mar 2 17:14:20 openvpn[33444]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1541 10.0.8.1 10.0.8.2 init Mar 2 17:14:20 openvpn[33444]: /sbin/ifconfig ovpns1 10.0.8.1 10.0.8.2 mtu 1500 netmask 255.255.255.255 up Mar 2 17:14:20 openvpn[33444]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0 Mar 2 17:14:20 openvpn[33444]: TUN/TAP device /dev/tun1 opened Mar 2 17:14:20 openvpn[33444]: TUN/TAP device ovpns1 exists previously, keep at program end Mar 2 17:14:20 openvpn[33444]: ROUTE_GATEWAY 192.168.1.1 Mar 2 17:14:20 openvpn[33444]: Socket Buffers: R=[42080->65536] S=[57344->65536] Mar 2 17:14:20 openvpn[33444]: Diffie-Hellman initialized with 1024 bit key Mar 2 17:14:20 openvpn[33444]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Mar 2 17:14:20 openvpn[33296]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/server1.sock Mar 2 17:14:20 openvpn[33296]: library versions: OpenSSL 1.0.1k-freebsd 8 Jan 2015, LZO 2.08 Mar 2 17:14:20 openvpn[33296]: OpenVPN 2.3.6 i386-portbld-freebsd10.1 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Dec 1 2014 Mar 2 17:14:19 openvpn[76875]: SIGTERM[hard,] received, process exiting Mar 2 17:14:19 openvpn[76875]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1541 10.0.8.1 10.0.8.2 init Mar 2 17:14:19 openvpn[76875]: Closing TUN/TAP interface Mar 2 17:14:19 openvpn[76875]: /sbin/route delete -net 10.0.8.0 10.0.8.2 255.255.255.0 Mar 2 17:14:19 openvpn[76875]: event_wait : Interrupted system call (code=4) Mar 2 17:14:13 openvpn[76875]: MANAGEMENT: Client disconnected Mar 2 17:14:13 openvpn[76875]: MANAGEMENT: CMD 'quit' Mar 2 17:14:12 openvpn[76875]: MANAGEMENT: CMD 'status 2' Mar 2 17:14:12 openvpn[76875]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock Mar 2 17:14:04 openvpn[76875]: openvpn/x.x.x.x:23750 SENT CONTROL [openvpn]: 'PUSH_REPLY,route 172.23.1.0 255.255.255.0,route 172.23.200.0 255.255.255.0,route 172.23.1.0 255.255.255.0,route 10.0.8.1,topology net30,ping 10,ping-restart 60,ifconfig 10.0.8.6 10.0.8.5' (status=1) Mar 2 17:14:04 openvpn[76875]: openvpn/x.x.x.x:23750 send_push_reply(): safe_cap=940Und vom entfernten client:
Mar 2 17:14:05 openvpn[61051]: Initialization Sequence Completed Mar 2 17:14:05 openvpn[61051]: /sbin/route add -net 10.0.8.1 10.0.8.5 255.255.255.255 Mar 2 17:14:05 openvpn[61051]: ERROR: FreeBSD route add command failed: external program exited with error status: 1 Mar 2 17:14:05 openvpn[61051]: /sbin/route add -net 172.23.1.0 10.0.8.5 255.255.255.0 Mar 2 17:14:05 openvpn[61051]: ERROR: FreeBSD route add command failed: external program exited with error status: 1 Mar 2 17:14:05 openvpn[61051]: /sbin/route add -net 172.23.200.0 10.0.8.5 255.255.255.0 Mar 2 17:14:05 openvpn[61051]: /sbin/route add -net 172.23.1.0 10.0.8.5 255.255.255.0 Mar 2 17:14:05 openvpn[61051]: /usr/local/sbin/ovpn-linkup ovpnc1 1500 1541 10.0.8.6 10.0.8.5 init Mar 2 17:14:05 openvpn[61051]: /sbin/ifconfig ovpnc1 10.0.8.6 10.0.8.5 mtu 1500 netmask 255.255.255.255 up Mar 2 17:14:05 openvpn[61051]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0 Mar 2 17:14:05 openvpn[61051]: TUN/TAP device /dev/tun1 opened Mar 2 17:14:05 openvpn[61051]: TUN/TAP device ovpnc1 exists previously, keep at program end Mar 2 17:14:05 openvpn[61051]: ROUTE_GATEWAY 192.168.10.1 Mar 2 17:14:04 openvpn[61051]: /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1541 10.0.8.6 10.0.8.5 init Mar 2 17:14:04 openvpn[61051]: Closing TUN/TAP interface Mar 2 17:14:04 openvpn[61051]: /sbin/route delete -net 172.23.1.0 10.0.8.5 255.255.255.0 Mar 2 17:14:04 openvpn[61051]: /sbin/route delete -net 10.0.8.1 10.0.8.5 255.255.255.255 Mar 2 17:14:04 openvpn[61051]: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device. Mar 2 17:14:04 openvpn[61051]: Preserving previous TUN/TAP instance: ovpnc1 Mar 2 17:14:04 openvpn[61051]: OPTIONS IMPORT: route options modified Mar 2 17:14:04 openvpn[61051]: OPTIONS IMPORT: --ifconfig/up options modified Mar 2 17:14:04 openvpn[61051]: OPTIONS IMPORT: timers and/or timeouts modified Mar 2 17:14:04 openvpn[61051]: PUSH: Received control message: 'PUSH_REPLY,route 172.23.1.0 255.255.255.0,route 172.23.200.0 255.255.255.0,route 172.23.1.0 255.255.255.0,route 10.0.8.1,topology net30,ping 10,ping-restart 60,ifconfig 10.0.8.6 10.0.8.5' Mar 2 17:14:04 openvpn[61051]: SENT CONTROL [internal-ca]: 'PUSH_REQUEST' (status=1) Mar 2 17:14:02 openvpn[61051]: [internal-ca] Peer Connection Initiated with [AF_INET]x.x.x.x:1194 Mar 2 17:14:02 openvpn[61051]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA Mar 2 17:14:02 openvpn[61051]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Mar 2 17:14:02 openvpn[61051]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Mar 2 17:14:02 openvpn[61051]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Mar 2 17:14:02 openvpn[61051]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Mar 2 17:14:01 openvpn[61051]: VERIFY OK: depth=0, C=DE, ST=x, L=x, O=x, emailAddress=info@x.com, CN=internal-ca Mar 2 17:14:01 openvpn[61051]: VERIFY OK: depth=1, C=DE, ST=x, L=x, O=x, emailAddress=info@x.com, CN=internal-ca Mar 2 17:14:00 openvpn[61051]: TLS: Initial packet from [AF_INET]x.x.x.x:1194, sid=53c880bf cac9663b Mar 2 17:14:00 openvpn[61051]: UDPv4 link remote: [AF_INET]x.x.x.x:1194 Mar 2 17:14:00 openvpn[61051]: UDPv4 link local (bound): [AF_INET]192.168.10.3 -
Hi Peter,
Zertifikate etc. passt alles…
Wenn der Tunnel steht, (Bsp.: Netz 10.10.2.0/24) sollte die IP des Servers 10.10.2.1, des Clients 10.10.2.2 sein.
Ist das nicht der Fall und hat der Client z.B. die 10.10.2.6 hast Du einen config Fehler (Multiclienttunnel, also mehrere Einzelclients). Dann bekommst Du Probleme mit dem Zugriff auf´s remote Netz.
Es ist eigentlich ganz simpel...
Server...
- auf dem WAN-Port der pfsense Regel erstellen
( IPv4 TCP/UDP source/ any Port/ any Destination/ WAN-address Port 1194 Gateway/ any )
- auf dem OpenVPN-Port
( erstellst Du erst mal eine any-to-any Rule Port/ any die Du später mit Tunnel-IP LAN, DMZ etc. modifizierst )
Client seitig läuft bei mir auf 3 Tunneln nur DD-WRT, dürfte auf das gleich rauskommen...iptables -I INPUT -p udp --dport 1194 -j ACCEPT iptables -I INPUT -i tun1 -j ACCEPT iptables -I FORWARD -i br0 -o tun1 -j ACCEPT iptables -I FORWARD -i tun1 -o br0 -j ACCEPT…tun1 ist klar und br0 ist das LAN des Client-Routers.
Was die Servereinstellungen angeht dürfte auch klar sein...
peer-to-peer
Interface WAN
Port 1194
tun
udp
Zertifikatseinstellungen
Netze..unter advanced....
push "route Server-LAN Subnetzmaske";Bei Client Specific Override….
General information
- ca und Client-Name
- Tunnelnetz
Client setting
Advanced
iroute remotes Netz Subnetzmaske;
Wenn´s Probleme gibt, per ssh auf Server bzw. Client einloggen…
netstat -rngibt das Routingprotokoll aus.
In /var/etc/openvpn liegen die Configs und /var/etc/openvpn-csc ist die ccd also die Client-spezifischen Angaben.
Viel Erfolg…. ;)Gruß Peter
PS.: sehe gerade, ich glaube Dir fehlen die Client spezifischen Einstellungen. Sonst sieht das erst mal nicht schlecht aus.:)
-
Wenn der Tunnel steht, (Bsp.: Netz 10.10.2.0/24) sollte die IP des Servers 10.10.2.1, des Clients 10.10.2.2 sein.
Ist das nicht der Fall und hat der Client z.B. die 10.10.2.6 hast Du einen config Fehler (Multiclienttunnel, also mehrere Einzelclients). Dann bekommst Du Probleme mit dem Zugriff auf´s remote Netz.Danke erst mal für Deine Hilfe.
Also: alles von Dir angegebene hatte ich (glaube ich), die Sache mit dem Multiclienttunnel verstehe ich aber nicht.
-
Also: alles von Dir angegebene hatte ich (glaube ich), die Sache mit dem Multiclienttunnel verstehe ich aber nicht.
Der Eintrag…
client-to-client (hat nichts mit den Clients in Server+Client-LAN zu tun)
…in der Server.conf dient dem Herstellen eines Multiclienttunnels.
Eine Server-Instanz hat mehrere Clients, die sich auch untereinander Verbinden können.
Standort A Server, Standorte B und C Clients. Standort B kann mit C reden etc.
Normaler Tunnel - Server .1 Client .2
Multiclienttunnel - Server .1 .2 Client .5.6 hängt mit den virtuellen Schnittstellen zusammen und wird erweitert
wenn die Clients noch mehr werden.
Frage mich bitte nicht wieso das so ist, habe ich auch so meine negativen Erfahrungen machen müssen.
Man muss nicht immer alles verstehen, funktionieren muss es.:)
Gruß Peter -
Der Eintrag…
client-to-client (hat nichts mit den Clients in Server+Client-LAN zu tun)
…in der Server.conf dient dem Herstellen eines Multiclienttunnels.
Ich stehe wieder ein bisschen auf dem Schlauch. Welchen "Eintrag" meinst Du? In der server1.conf findet sich so ein Eintrag nicht.
-
Ich stehe wieder ein bisschen auf dem Schlauch. Welchen "Eintrag" meinst Du? In der server1.conf findet sich so ein Eintrag nicht.
…den Eintrag benötigst Du nur, wenn Du an einem OpenVPN-Server mehrere OpenVPN-Clients betreibst und wenn diese -Clients miteinander kommunizieren sollen.
Das betrifft nicht Dein Szenario. Du verbindest nur 2 Netze über den Tunnel.
Da Du damit aber...
zum Bsp.: Client 3 vom Netz 192.168.23.0/24
mit Client 2 vom Netz 172.19.48.0/24
..verbinden kannst, wird....
client-to-client
…häufig falsch interpretiert und findet dann in einer Server.conf Verwendung, wo das gar nicht angebracht ist.
Also bei Dir, alles Tacco, Deine Config braucht kein client-to-client.
War wohl alles bissl viel auf ein mal…. ;D
Gruß Peter -
netstat -rn sagt:
Routing tables Internet: Destination Gateway Flags Netif Expire default 192.168.1.1 UGS em1 10.0.8.0/24 10.0.8.2 UGS ovpns1 10.0.8.1 link#8 UHS lo0 10.0.8.2 link#8 UH ovpns1 127.0.0.1 link#6 UH lo0 172.23.1.0/24 link#2 U em0 172.23.1.1 link#2 UHS lo0 172.23.200.0/24 10.0.8.2 UGS ovpns1 192.168.1.0/24 link#3 U em1 192.168.1.1 00:11:0a:53:3f:9b UHS em1 192.168.1.2 link#3 UHS lo0 Internet6: Destination Gateway Flags Netif Expire ::1 link#6 UH lo0 fe80::%em0/64 link#2 U em0 fe80::211:aff:fe53:3f9a%em0 link#2 UHS lo0 fe80::%em1/64 link#3 U em1 fe80::211:aff:fe53:3f9b%em1 link#3 UHS lo0 fe80::%lo0/64 link#6 U lo0 fe80::1%lo0 link#6 UHS lo0 fe80::%ovpns1/64 link#8 U ovpns1 fe80::230:5ff:fe20:9516%ovpns1 link#8 UHS lo0 ff01::%em0/32 fe80::211:aff:fe53:3f9a%em0 U em0 ff01::%em1/32 fe80::211:aff:fe53:3f9b%em1 U em1 ff01::%lo0/32 ::1 U lo0 ff01::%ovpns1/32 fe80::230:5ff:fe20:9516%ovpns1 U ovpns1 ff02::%em0/32 fe80::211:aff:fe53:3f9a%em0 U em0 ff02::%em1/32 fe80::211:aff:fe53:3f9b%em1 U em1 ff02::%lo0/32 ::1 U lo0 ff02::%ovpns1/32 fe80::230:5ff:fe20:9516%ovpns1 U ovpns1Hilft das?
-
Da passt was nicht wirklich…
Die Routen auf dem Server sind OK so.....
10.0.8.1 Server, 10.0.8.2 Client
Beim Clientlog taucht...usr/local/sbin/ovpn-linkup ovpnc1 1500 1541 10.0.8.6 10.0.8.5 initAbgesehen davon das eine MTU Größe von 1500 mal zu Problemen führen kann…
...poste mal bitte die Ausgabe von...netstat -rn…auf dem Client.
-
Ok, mache ich gerne nachher, wenn ich dort bin. Melde mich dann abends wieder. Danke.
-
hier vom client:
Routing tables Internet: Destination Gateway Flags Netif Expire default 192.168.10.1 UGS re0 10.0.8.1/32 10.0.8.5 UGS ovpnc1 10.0.8.5 link#7 UH ovpnc1 10.0.8.6 link#7 UHS lo0 127.0.0.1 link#5 UH lo0 172.23.1.0/24 10.0.8.5 UGS ovpnc1 172.23.200.0/24 link#1 U em0 172.23.200.1 link#1 UHS lo0 192.168.10.0/24 link#2 U re0 192.168.10.1 00:24:1d:2e:cc:08 UHS re0 192.168.10.3 link#2 UHS lo0 Internet6: Destination Gateway Flags Netif Expire ::1 link#5 UH lo0 fe80::%em0/64 link#1 U em0 fe80::1:1%em0 link#1 UHS lo0 fe80::%re0/64 link#2 U re0 fe80::224:1dff:fe2e:cc08%re0 link#2 UHS lo0 fe80::%lo0/64 link#5 U lo0 fe80::1%lo0 link#5 UHS lo0 fe80::6a05:caff:fe04:57d3%ovpnc1 link#7 UHS lo0 ff01::%em0/32 fe80::1:1%em0 U em0 ff01::%re0/32 fe80::224:1dff:fe2e:cc08%re0 U re0 ff01::%lo0/32 ::1 U lo0 ff01::%ovpnc1/32 fe80::6a05:caff:fe04:57d3%ovpnc1 U ovpnc1 ff02::%em0/32 fe80::1:1%em0 U em0 ff02::%re0/32 fe80::224:1dff:fe2e:cc08%re0 U re0 ff02::%lo0/32 ::1 U lo0 ff02::%ovpnc1/32 fe80::6a05:caff:fe04:57d3%ovpnc1 U ovpnc1 -
Hi,
so was in der Art hatte ich schon vermutet. :(
Du willst eine Point-to-Point Verbindung aufbauen, Server und ein remoter Standort, richtig ?
Dein Tunnel steht vermutlich, Du kommst aber nicht vom Server-LAN auf Client-LAN, richtig ?
Wie sieht Deine OVPN-Server-Seite in Bezug auf die Client-Spezific-Overrides aus ?
Poste mal noch die…- /var/etc/opnvpn/server1.conf
- /var/etc/opnvpn/client1.conf
- /var/etc/opnvpn-csc vom Server
Gruß Peter
-
Du willst eine Point-to-Point Verbindung aufbauen, Server und ein remoter Standort, richtig ?
Dein Tunnel steht vermutlich, Du kommst aber nicht vom Server-LAN auf Client-LAN, richtig ?Zwei mal ja.
/var/etc/opnvpn/server1.conf
dev ovpns1 verb 2 dev-type tun tun-ipv6 dev-node /dev/tun1 writepid /var/run/openvpn_server1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher BF-CBC auth SHA1 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 192.168.1.2 tls-server server 10.0.8.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc ifconfig 10.0.8.1 10.0.8.2 tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'internal-ca' 1" lport 1194 management /var/etc/openvpn/server1.sock unix max-clients 1 push "route 172.23.1.0 255.255.255.0" route 172.23.200.0 255.255.255.0 ca /var/etc/openvpn/server1.ca cert /var/etc/openvpn/server1.cert key /var/etc/openvpn/server1.key dh /etc/dh-parameters.1024- /var/etc/opnvpn/client1.conf
Die existiert nicht im Verzeichnis auf dem Server.
- /var/etc/opnvpn-csc
ifconfig-push 10.0.8.2 10.0.8.1 iroute 172.23.200.0 255.255.255.0 -
/var/etc/opnvpn/server1.conf
…sieht OK aus.
/var/etc/opnvpn-csc
…sieht OK aus.
/var/etc/opnvpn/client1.conf
Die existiert nicht im Verzeichnis auf dem Server.…kann ja nicht, da musst Du schon auf dem Client gucken.. ;D
-
…kann ja nicht, da musst Du schon auf dem Client gucken.. ;D
Ups, die Transferleistung hatte ich vorhin auf die schnelle nicht erbracht ::) An die Datei komme ich aber erst wieder heute Abend.
Hast Du (auch ohne Kenntnis der client-Datei) eine Vermutung, wo das Problem sonst liegen könnte?
-
Hast Du (auch ohne Kenntnis der client-Datei) eine Vermutung, wo das Problem sonst liegen könnte?
Zum einen brauchst Du für Remote auch Firewall Regeln, die dir erlauben vom Tunnel auf das remote Netz zu kommen und für den WAN-Port eine für den Tunnelport.
Bei meiner Config, clientseitig (DD-WRT Router), hatte ich Dir diese schon gepostet.
Dann hast Du einen Tunnel laufen, der mit den remoten IP´s 10.0.8.6 10.0.8.5 ausgestattet ist.
Normalerweise sollte das bei einem Point-to-Point am Client nur die 10.0.8.2 sein. !!!
Ich hatte das Problem auch schon und habe dann keinen direkten Zugriff auf´s remote Netz bekommen, zumindest keinen direkten.
Das heißt, wenn Du per ssh in der Lage bist, Dich auf die IP 10.0.8.6 zu verbinden.
Damit wärst Du auf der remoten pfSense und solltest Dich von da aus auch auf die remote LAN-IP 172.23.200.1 (wenn das die Router-IP des remoten LAN ist) bzw. auf einem Client (FW aus) des remoten LAN einloggen können.
Wenn das so funktioniert, steht der Tunnel, ist aber ein Multiclienttunnel. (siehe einen der vorherigen Post von mir)
So kommst Du nicht direkt auf´s remote LAN, also muss da noch irgendwas an Deiner config nicht stimmen.
Ich tippe aber mal trotzdem auf den Server bzw. Client-Spezific-Overrides im GUI.
Bring trotzdem mal die Client-conf….
Gruß Peter -
hier die client1.conf:
dev ovpnc1 verb 2 dev-type tun tun-ipv6 dev-node /dev/tun1 writepid /var/run/openvpn_client1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher BF-CBC auth SHA1 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 192.168.10.3 tls-client client lport 0 management /var/etc/openvpn/client1.sock unix remote xxx.dyndns.org 1194 ifconfig 10.0.8.2 10.0.8.1 route 172.23.1.0 255.255.255.0 ca /var/etc/openvpn/client1.ca cert /var/etc/openvpn/client1.cert key /var/etc/openvpn/client1.key resolv-retry infinite