67
DD-WRT Router als VPN-Server hinter FritzBox - Konfigurationsproblem
Hallo zusammen, ich würde gerne einen Open VPN-Server über einen Buffalo Router mit DD-WRT betreiben.
Der Router steht hinter einer FritzBox 7490. Auf der FritzBox ist ein Port-Forward auf 1194 eingerichtet.
FritzBox hat eine DNS-Server-Adresse.
Die Easy-RSA-Konfiguration hab ich für beide Seiten (Client und Server) schon durchgeführt.
Server-Zertifikate sind im VPN-Router auch eingetragen
Client hat als remote die DNS Server-Adresse der FritzBox eingetragen
Leider funktioniert bzw. stimmt meine VPN-Konfiguration wahrscheinlich im Router nur noch nicht so ganz, das der Server nicht starten will.
Screenshot
Tendiere, dass die Push-Settings nicht ganz passen. Was müsste ich da eure Meinung eintragen, wenn der VPN-Server hinter einer FritzBox sitzt.
Bzw. was müsste noch an der FritzBox gecheckt werden, was ich noch nicht erwähnt hab?
Der Router steht hinter einer FritzBox 7490. Auf der FritzBox ist ein Port-Forward auf 1194 eingerichtet.
FritzBox hat eine DNS-Server-Adresse.
Die Easy-RSA-Konfiguration hab ich für beide Seiten (Client und Server) schon durchgeführt.
Server-Zertifikate sind im VPN-Router auch eingetragen
Client hat als remote die DNS Server-Adresse der FritzBox eingetragen
Leider funktioniert bzw. stimmt meine VPN-Konfiguration wahrscheinlich im Router nur noch nicht so ganz, das der Server nicht starten will.
Screenshot
Tendiere, dass die Push-Settings nicht ganz passen. Was müsste ich da eure Meinung eintragen, wenn der VPN-Server hinter einer FritzBox sitzt.
Bzw. was müsste noch an der FritzBox gecheckt werden, was ich noch nicht erwähnt hab?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 322887
Url: https://administrator.de/forum/dd-wrt-router-als-vpn-server-hinter-fritzbox-konfigurationsproblem-322887.html
Ausgedruckt am: 23.12.2024 um 10:12 Uhr
67 Kommentare
Neuester Kommentar
Ahoi ...
Wie meinen?
VG
Ashnod
Naja... der VPN Client hat in der Konfig die DNS-Server-Adresse der FritzBox eingetragen. Weil die Fritzbox ist ja der direkte Router zum WAN und den VPN-Router kennt der Client ja nicht.
Hallo,
hast Du bei der AVM FB auch das VPN deaktiviert?
Sonst denkt die AVM FB jedes mal dass das VPN für sie ist und nimmt es selber an!
Gruß
Dobby
hast Du bei der AVM FB auch das VPN deaktiviert?
Sonst denkt die AVM FB jedes mal dass das VPN für sie ist und nimmt es selber an!
Gruß
Dobby
Wenn ich da keine VPN-Verbindung eintrage, ist es doch gleichgestellt wie deaktiviert oder?
Wenn ich da keine VPN-Verbindung eintrage, ist es doch gleichgestellt wie deaktiviert oder?
Nein denn dann denkt die AVM FB immer wieder dass die VPN Verbindung für sie selber istund versucht sie anzunehmen und von daher kommt wohl auch nichts am VPN Server an!
Gruß
Dobby
Hi,
und wieso lässt Du das Feld für das "server.crt" frei?
Zumindest ist das so im Bild ersichtlich.
Gruß orcape
und wieso lässt Du das Feld für das "server.crt" frei?
Zumindest ist das so im Bild ersichtlich.
Gruß orcape
@108012,
Seit wann macht die Fritte per default denn OpenVPN? Ein Portforwarding auf den OpenVPN-Port sollte ausreichen. Hier scheint wohl etwas mehr nicht zu stimmen, denn die TLS-Auth wurde auch "eingespart".
Gruß orcape
Seit wann macht die Fritte per default denn OpenVPN? Ein Portforwarding auf den OpenVPN-Port sollte ausreichen. Hier scheint wohl etwas mehr nicht zu stimmen, denn die TLS-Auth wurde auch "eingespart".
Gruß orcape
Da ich ja kein IPSec tunnel, müsste das doch wie du schreibst, direkt mit einem Port-Forward 1194 zum Buffalo funktionieren.
Vielleicht hilft es noch weiter:
Wenn ich den Client starte und eine Verbindung aufbauen möchte, steht Management Waiting.... in der untersten Zeile.
Vielleicht hilft es noch weiter:
Wenn ich den Client starte und eine Verbindung aufbauen möchte, steht Management Waiting.... in der untersten Zeile.
Wenn denn ja das Port Forwarding UDP 1194 im Buffalo Router auf den DD-WRT konfigurieren !
Der DD-WRT agiert hier ja als OVPN Server wenn man den TO richtig versteht.
Das hiesige Tutorial erklärt es en Detail wie es geht:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Bzw. hier genau WIE der Router in einer Routerkaskade betrieben wird mit Port Forwarding:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Damit sollte es sofort zum Fliegen kommen....
Der DD-WRT agiert hier ja als OVPN Server wenn man den TO richtig versteht.
Das hiesige Tutorial erklärt es en Detail wie es geht:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Bzw. hier genau WIE der Router in einer Routerkaskade betrieben wird mit Port Forwarding:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Damit sollte es sofort zum Fliegen kommen....
Hallo nochmal,
Gruß
Dobby
Da ich ja kein IPSec tunnel,........
Ok den habe ich eben überlesen!Gruß
Dobby
@aqui Möchte mal wirklich ein herzliches Dankeschön an dich aussprechen.
Bis jetzt warst du in meinen Problem-Threads immer zur Stelle und konntest mir auch bei diesem Problem mit deinem ausführlichen - und denke ich zeitaufwändigen - Guide wieder mal weiterhelfen.
Client verbindet sich mit Server.
Jetzt hätte ich noch eine Erweiterung an diese Sache.
Das Setup soll nachher hinter einem Hybrid-Router der Telekom laufen. Das heißt:
Hybrid-Router verbindet Business-Netz und dahinter soll ein VPN-Client (Buffalo Router). Zuhause soll dann ein weiterer Buffalo Router, der den VPN-Server einnimmt.
Ein Kollege meinte vor kurzem, diese umgestellte, untypische Variante würde das VPN-Problem der Telekom Hybrid-Router umgehen. (wird ja leider keine WAN-Adresse den Kunden bekanntgegeben. Zumindest nicht ohne Kostenaufwand.)
Ich mach somit ein 1194 forwarding im Hybrid und pack meine sicheren Client-Schlüssel in den Client-Router. Der Rest wäre ja somit erledigt oder hab ich was vergessen?
Was meint ihr, klappt das? Bzw. was wäre noch zu beachten?
Bis jetzt warst du in meinen Problem-Threads immer zur Stelle und konntest mir auch bei diesem Problem mit deinem ausführlichen - und denke ich zeitaufwändigen - Guide wieder mal weiterhelfen.
Client verbindet sich mit Server.
Jetzt hätte ich noch eine Erweiterung an diese Sache.
Das Setup soll nachher hinter einem Hybrid-Router der Telekom laufen. Das heißt:
Hybrid-Router verbindet Business-Netz und dahinter soll ein VPN-Client (Buffalo Router). Zuhause soll dann ein weiterer Buffalo Router, der den VPN-Server einnimmt.
Ein Kollege meinte vor kurzem, diese umgestellte, untypische Variante würde das VPN-Problem der Telekom Hybrid-Router umgehen. (wird ja leider keine WAN-Adresse den Kunden bekanntgegeben. Zumindest nicht ohne Kostenaufwand.)
Ich mach somit ein 1194 forwarding im Hybrid und pack meine sicheren Client-Schlüssel in den Client-Router. Der Rest wäre ja somit erledigt oder hab ich was vergessen?
Was meint ihr, klappt das? Bzw. was wäre noch zu beachten?
Ja, das klappt so und du hast nichts vergessen.
Ich mach somit ein 1194 forwarding im Hybrid und pack meine sicheren Client-Schlüssel in den Client-Router.
Für den OpenVPN-Client brauchst Du noch nicht mal ein Portforwarding 1194. Das wäre nur beim OpenVPN-Server notwendig. Der OpenVPN-Client findet an Hand seiner "client.cfg" per fester IP oder DynDNS sein Ziel im Internet.Gruß orcape
Ich muss mich nochmals melden. Irgendwie haut das mit der Konfig noch nicht soo ganz hin.
Nochmals zum Verständnis: ich teste aktuell noch mit Windows Client und weiterhin mit dem DD-WRT Router als VPN-Server hinter der FritzBox.
Verbindung zum VPN-Server kann ausgehandelt werden. Aber alles danach funktioniert nicht so ganz.
Würde gerne den ganzen Traffic durch den Tunnel schicken. Also mit einem "redirect gateway". Bin mir aber nicht so ganz sicher was ich wirklich in die Konfigs schreiben muss, dass es klappt.
Hier mal die Client-Config:
client
dev def1
proto udp
remote dns-server name 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca pfad/ca.crt
cert pfadclient1.crt
key pfad/client1.key
ns-cert-type server
comp-lzo
verb 3
Server Config:
port 1194
proto udp
dev def1
ca pfad/ca.crt
cert pfad/cert.pem
key pfadkey.pem
dh pfad/dh.pem
server IP-Adresse des VPN-Netzes 255.255.255.0
push "redirect-gateway def1"
push "dhcp-option DNS 208.67.222.222"
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
management localhost 14
Server Firewall:
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.11.0/24 -j SNAT --to 192.168.178.4
iptables -I FORWARD 1 --source 192.168.11.0/24 -j ACCEPT
iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT
iptables -I INPUT 3 -i tun0 -j ACCEPT
iptables -I FORWARD 3 -i tun0 -o tun0 -j ACCEPT
Hab jetzt gelesen dass man in der FritzBox neben dem PortForward auch ne Route an das VPN-Netz und das Netz hinter dem VPN-Server zu machen.
Jedoch glaub ich, dass es aktuell nur noch Einstellungssache am VPN-Server ist.
Nochmals zum Verständnis: ich teste aktuell noch mit Windows Client und weiterhin mit dem DD-WRT Router als VPN-Server hinter der FritzBox.
Verbindung zum VPN-Server kann ausgehandelt werden. Aber alles danach funktioniert nicht so ganz.
Würde gerne den ganzen Traffic durch den Tunnel schicken. Also mit einem "redirect gateway". Bin mir aber nicht so ganz sicher was ich wirklich in die Konfigs schreiben muss, dass es klappt.
Hier mal die Client-Config:
client
dev def1
proto udp
remote dns-server name 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca pfad/ca.crt
cert pfadclient1.crt
key pfad/client1.key
ns-cert-type server
comp-lzo
verb 3
Server Config:
port 1194
proto udp
dev def1
ca pfad/ca.crt
cert pfad/cert.pem
key pfadkey.pem
dh pfad/dh.pem
server IP-Adresse des VPN-Netzes 255.255.255.0
push "redirect-gateway def1"
push "dhcp-option DNS 208.67.222.222"
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3
management localhost 14
Server Firewall:
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.11.0/24 -j SNAT --to 192.168.178.4
iptables -I FORWARD 1 --source 192.168.11.0/24 -j ACCEPT
iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT
iptables -I INPUT 3 -i tun0 -j ACCEPT
iptables -I FORWARD 3 -i tun0 -o tun0 -j ACCEPT
Hab jetzt gelesen dass man in der FritzBox neben dem PortForward auch ne Route an das VPN-Netz und das Netz hinter dem VPN-Server zu machen.
Jedoch glaub ich, dass es aktuell nur noch Einstellungssache am VPN-Server ist.
Hi,
in die server.conf sollte noch ein push "route 192.168.11.0 255.255.255.0", damit der Client weiss, wo er Dein LAN zu suchen hat.
Gruß orcape
in die server.conf sollte noch ein push "route 192.168.11.0 255.255.255.0", damit der Client weiss, wo er Dein LAN zu suchen hat.
Gruß orcape
Danke für den Tipp, das war es.
Hab den Client nun hinter dem Hybrid (Office) und zuhause den (Server) hinter der Fritze am laufen.
Handshake funktioniert auch.
Nur komm ich via VPN noch nichts vor den Hybrid. Alles dahinter lässt sich über den DDWRT-Router (VPN-Client) anpingen.
WAN ist leider unmöglich.
An was kann das noch liegen?
Firewall-Settings am Client oder Server?
Wenn ihr noch Infos, Screenshots bräuchtet, sagt einfach bescheid. Wäre echt super, wenn ich das Ding zum laufen bekomme.
Hab den Client nun hinter dem Hybrid (Office) und zuhause den (Server) hinter der Fritze am laufen.
Handshake funktioniert auch.
Nur komm ich via VPN noch nichts vor den Hybrid. Alles dahinter lässt sich über den DDWRT-Router (VPN-Client) anpingen.
WAN ist leider unmöglich.
An was kann das noch liegen?
Firewall-Settings am Client oder Server?
Wenn ihr noch Infos, Screenshots bräuchtet, sagt einfach bescheid. Wäre echt super, wenn ich das Ding zum laufen bekomme.
Hi,
Sonst wird der Tunnel als "Fremdnetz" geblockt.
Interface WAN - Source LAN (Netz hinter dem OpenVPN-Server) - NAT-Adress WAN(Hybrid)
Gruß orcape
WAN ist leider unmöglich.
Dazu benötigst Du, wenn das machbar ist, eine NAT-Regel auf dem Hybrid.Sonst wird der Tunnel als "Fremdnetz" geblockt.
Interface WAN - Source LAN (Netz hinter dem OpenVPN-Server) - NAT-Adress WAN(Hybrid)
Gruß orcape
Beziehst du dich jetzt auf den Server oder den Client?
Weil hinter dem Hybrid steht der Client.
Da die tolle Hybrid-Büchse so gut wie keine Möglichkeiten zum Konfigurieren zulässt, sind mir da was NAT-Rules angeht, auch die Hände gebunden.
Einzige was geht, is Port Forwarding auf VPN-Port. Bei einem Client aber theoretisch nicht notwendig.
Sollte eben nachher ja so sein, dass der Client anstatt dem Server im Office fungiert und man vom Server aus bzw. Home auf das Firmennetzwerk (Office) zugreifen kann.
Weil hinter dem Hybrid steht der Client.
Da die tolle Hybrid-Büchse so gut wie keine Möglichkeiten zum Konfigurieren zulässt, sind mir da was NAT-Rules angeht, auch die Hände gebunden.
Einzige was geht, is Port Forwarding auf VPN-Port. Bei einem Client aber theoretisch nicht notwendig.
Sollte eben nachher ja so sein, dass der Client anstatt dem Server im Office fungiert und man vom Server aus bzw. Home auf das Firmennetzwerk (Office) zugreifen kann.
Da die tolle Hybrid-Büchse so gut wie keine Möglichkeiten zum Konfigurieren zulässt, sind mir da was NAT-Rules angeht, auch die Hände gebunden.
Warum beschaffst du dir dann nicht einen sinnvollen Dual WAN Balancing Router oder ne pfSense, damit hättest du diese Grundproblematik gar nicht erst.https://www.heise.de/ct/ausgabe/2016-24-pfSense-als-Load-Balancer-345834 ...
Naja.... ich hab ja weiter oben gefragt:
Ein Kollege meinte vor kurzem, diese umgestellte, untypische Variante würde das VPN-Problem der Telekom Hybrid-Router umgehen. (wird ja leider keine WAN-Adresse den Kunden bekanntgegeben. Zumindest nicht ohne Kostenaufwand.)
Ich mach somit ein 1194 forwarding im Hybrid und pack meine sicheren Client-Schlüssel in den Client-Router. Der Rest wäre ja somit erledigt oder hab ich was vergessen?
Und da hieß es, das geht?
Ist denn da eine Möglichkeit noch da, mit dem DDWRT-Router hinter dem Hybrid ne Verbindung aufzubauen?
Du meinst mit einer pfSense:
Speedport-Hybrid --> pfSense (VPN-Client) --> Switch Whatever --> Hosts
Ein Kollege meinte vor kurzem, diese umgestellte, untypische Variante würde das VPN-Problem der Telekom Hybrid-Router umgehen. (wird ja leider keine WAN-Adresse den Kunden bekanntgegeben. Zumindest nicht ohne Kostenaufwand.)
Ich mach somit ein 1194 forwarding im Hybrid und pack meine sicheren Client-Schlüssel in den Client-Router. Der Rest wäre ja somit erledigt oder hab ich was vergessen?
Und da hieß es, das geht?
Ist denn da eine Möglichkeit noch da, mit dem DDWRT-Router hinter dem Hybrid ne Verbindung aufzubauen?
Du meinst mit einer pfSense:
Speedport-Hybrid --> pfSense (VPN-Client) --> Switch Whatever --> Hosts
Hi nintox,
Nimm ein ALIX-Board, wenn das Deinen Ansprüchen genügt, (preiswerter wie APU) "schraube" da eine pfSense drauf und folge @aqui 's Tutorial hier im Forum.
Auf der pfSense terminierst Du den OpenVPN-Client und erstellst die NAT-Regel und schon greifst Du auf den Speedport zu.
Gruß orcape
Beziehst du dich jetzt auf den Server oder den Client?
Du hattest vom Hybrid gesprochen und das ist doch Client, oder etwa nicht?Nimm ein ALIX-Board, wenn das Deinen Ansprüchen genügt, (preiswerter wie APU) "schraube" da eine pfSense drauf und folge @aqui 's Tutorial hier im Forum.
Speedport-Hybrid --> pfSense (VPN-Client) --> Switch Whatever --> Hosts
Genau so.Auf der pfSense terminierst Du den OpenVPN-Client und erstellst die NAT-Regel und schon greifst Du auf den Speedport zu.
Gruß orcape
Danke für die Alternative.
So ganz steig ich aber immer noch nicht durch...
Was ist der Unterschied zwischen einem VPN-Client auf dem DD-WRT und einem VPN-Client auf einer pfSense. Außer das es eine Firewall ist und direkt im Netzwerk hängt und kein eigenes dahinter macht.
Anders gefragt, wäre es möglich den DDWRT Router als LAN-Switch laufen zu lassen. Somit wäre er eben nur ein VPN-Client hinter dem Hybrid.
Ich versuch eben aktuell noch irgendwie mit der Hardware die ich schon habe, das hinzubekommen. Kann man ja bestimmt verstehen.
So ganz steig ich aber immer noch nicht durch...
Was ist der Unterschied zwischen einem VPN-Client auf dem DD-WRT und einem VPN-Client auf einer pfSense. Außer das es eine Firewall ist und direkt im Netzwerk hängt und kein eigenes dahinter macht.
Anders gefragt, wäre es möglich den DDWRT Router als LAN-Switch laufen zu lassen. Somit wäre er eben nur ein VPN-Client hinter dem Hybrid.
Ich versuch eben aktuell noch irgendwie mit der Hardware die ich schon habe, das hinzubekommen. Kann man ja bestimmt verstehen.
Was ist der Unterschied zwischen einem VPN-Client auf dem DD-WRT und einem VPN-Client auf einer pfSense.
Man sollte auf dem DD-WRT eigentlich auch eine NAT-Regel erstellen können, unter Administration. Ansonsten hat die pfSense wesentlich mehr Funktionen.Wenn sich @aqui nicht noch einmal meldet, schick Ihm eine PN, der hat da mehr Ahnung, wie und ob das auf DD-WRT zu realisieren ist.
Gruss orcape
Ich danke dir schon mal. Mach ich!
Was ist der Unterschied zwischen einem VPN-Client auf dem DD-WRT und einem VPN-Client auf einer pfSense.
Da ist natürlich kein Unterschied ist ja technisch vollkommen das gleiche.Der Vorschlag bezpg sich auf den Ersatz des Hybrid Routers, also das man das die pfSense direkt machen lässt. Ein Port direkt ans DSL und den anderen ans LTE.
Letztlich ist das ja ein simples Standard Szenario. der TO schreibt ja jetzt:
er baut auch eine Verbindung zum Server auf (Handshake), aber überträgt keine Daten
D.h. um nochmal die Fakten zu beschreiben:Der kaskadierte DD-WRT Router ist VPN Client und NICHT VPN Server ?! Ist das so richtig ?
D.h. ER baut die OVPN Verbindung zu irgendeinem Server remote auf. Stimmt das so ?
Dann ist die Sache ja noch viel einfacher und sollte in jedem Falle klappen.
Du sagst der DD-WRT als Client baut die Verbindung auf.
- Kannst du das mit einem Log Auszug belegen ??
- Hast du das Tutorial dazu gelesen: OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router und den Client mal so manuell gestartet ?? Was sagt dann der CLI Output ?? Bekommst du da auch ein Initialization Sequence Completed
- Du solltest bitte hier nochmal genau diese Outputs des Clients hier posten. Ebenso wichtig ist ein ifconfig bei aktivem Client um zu sehen das das virtuelle Tunnel Interface zum Server wirklich aktiv ist.
- Ein Ping auf die virtuelle Server IP, also die, die du in der Server Konfig Datei mit server 172.16.2.0 255.255.255.0 definiert hast ! Hier im Beispiel hat der Server die 172.16.2.1. Dieser Ping MUSS immer möglich sein !
All diese Outputs und Infos hat der TO bis hierher noch NICHT geliefert. Wir müssten sie für eine zielgerichtete Hilfe aber wissen !!
Danke, dass du dich dem nochmals annimmst.
Der kaskadierte DD-WRT Router ist VPN Client und NICHT VPN Server ?! Ist das so richtig ?
Richtig, ist ein VPN-Client hinter dem Hybrid-Router am Firmenstandort.
D.h. ER baut die OVPN Verbindung zu irgendeinem Server remote auf. Stimmt das so ?
Genau, korrekt.
Du sagst der DD-WRT als Client baut die Verbindung auf.
Kannst du das mit einem Log Auszug belegen ??
Kann ich machen, müsste heute Abend nochmals vor Ort und die Daten kurz auslesen. Poste sie dann direkt hier rein.
Hast du das Tutorial dazu gelesen: OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Routerund den Client mal so manuell gestartet ?? Was sagt dann der CLI Output ??
Manuell hab ich den Client jetzt noch nicht gestartet, weil er im DD-WRT Webpanel jedes mal auch richtig gestartet hat und auf dem Server auch als Client aufschlägt.
Bekommst du da auch ein Initialization Sequence Completed?
Ja, bekomme ich.
Du solltest bitte hier nochmal genau diese Outputs des Clients hier posten. Ebenso wichtig ist ein ifconfig bei aktivem Client um zu sehen das das virtuelle Tunnel Interface zum Server wirklich aktiv ist.
Mach ich.
Ein Ping auf die virtuelle Server IP, also die, die du in der Server Konfig Datei mit server 172.16.2.0 255.255.255.0 definiert hast ! Hier im Beispiel hat der Server die 172.16.2.1. Dieser Ping MUSS immer möglich sein !
Ping auf Server im Tunnel-Netz geht leider nicht. Aktuell nur Ping bis Hybrid-Router möglich.
Wenn das klappt dann steht auch der Tunnel und der Rest ist dann ein sehr einfaches Routing Problem was mit einer simplen statischen Route zu lösen ist.
Statische Routen kann ich im Hybrid leider schwer setzen. Außer eben über ein Port Forward zu einem Ziel-Client (In dem Fall der VPN-Client)
Der kaskadierte DD-WRT Router ist VPN Client und NICHT VPN Server ?! Ist das so richtig ?
Richtig, ist ein VPN-Client hinter dem Hybrid-Router am Firmenstandort.
D.h. ER baut die OVPN Verbindung zu irgendeinem Server remote auf. Stimmt das so ?
Genau, korrekt.
Du sagst der DD-WRT als Client baut die Verbindung auf.
Kannst du das mit einem Log Auszug belegen ??
Kann ich machen, müsste heute Abend nochmals vor Ort und die Daten kurz auslesen. Poste sie dann direkt hier rein.
Hast du das Tutorial dazu gelesen: OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Routerund den Client mal so manuell gestartet ?? Was sagt dann der CLI Output ??
Manuell hab ich den Client jetzt noch nicht gestartet, weil er im DD-WRT Webpanel jedes mal auch richtig gestartet hat und auf dem Server auch als Client aufschlägt.
Bekommst du da auch ein Initialization Sequence Completed?
Ja, bekomme ich.
Du solltest bitte hier nochmal genau diese Outputs des Clients hier posten. Ebenso wichtig ist ein ifconfig bei aktivem Client um zu sehen das das virtuelle Tunnel Interface zum Server wirklich aktiv ist.
Mach ich.
Ein Ping auf die virtuelle Server IP, also die, die du in der Server Konfig Datei mit server 172.16.2.0 255.255.255.0 definiert hast ! Hier im Beispiel hat der Server die 172.16.2.1. Dieser Ping MUSS immer möglich sein !
Ping auf Server im Tunnel-Netz geht leider nicht. Aktuell nur Ping bis Hybrid-Router möglich.
Wenn das klappt dann steht auch der Tunnel und der Rest ist dann ein sehr einfaches Routing Problem was mit einer simplen statischen Route zu lösen ist.
Statische Routen kann ich im Hybrid leider schwer setzen. Außer eben über ein Port Forward zu einem Ziel-Client (In dem Fall der VPN-Client)
weil er im DD-WRT Webpanel jedes mal auch richtig gestartet hat und auf dem Server auch als Client aufschlägt.
OK, es würde auch das Server Log reichen was eindutig dann anzeigen sollte das der Tunnel aktiv ist ohne Fehler.Wenn direkt vom VPN Client kein Ping auf die interen OVPN Server IP möglich ist dann ist :
- entweder der Tunnel nicht aufgebaut
- oder irgendwo noch ne Firewall aktiv
Hier wäre jetzt ein ifconfig Output bei aktivem VPN mal sehr hilfreich um zu sehen ob das virtuelle Tunnel Interface aufgebaut ist und es vom OVPN Server eine korrekte IP Adresse bekommen hat.
Dann mal außer ifconfig mal ein netstat -r ziehen um die Routing Tabelle zu sehen.
Sollte das alles passen MUSS ein direkter Ping vom CLI des DD-WRT auf die Server VPN IP klappen.
Ob du statische Routen brauchst oder nicht hängt einzig und allein davon ab WIE deine Infrastruktur aussieht.
Betreibst du das DD-WRT VPN in einer Kaskade mit dem Hybridrouter ist das kein Thema.
Betreibst du es aber "one armed" also nur einbeinig angeschlossen sind statische Routen zwingend.
Das muss dann nicht unbedinbt auf dem Hybrid Router sein. Wenn er es nicht supportet, dann musst du es auf deinem Client direkt machen.
Bei einem Winblows Client geht das dann so:
route add <vpn_zielnetz> mask <maske_ziel> <gateway_ip_dd-wrt> -p
Dann routet der Client gleich diese Pakete direkt an das VPN Client Gateway statt an den Hybrid Router.
Bei Winblows zeigt dann ein route print die lokale Routing Tabelle an.
if_config:
netstat -r :
Mitschnitt aus dem Syslog über SSH:
ba0 Link encap:Ethernet HWaddr CC:E1:D5:DF:08:E4
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:4
br0 Link encap:Ethernet HWaddr CC:E1:D5:DF:08:E0
inet addr:192.168.11.1 Bcast:192.168.11.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6908 errors:0 dropped:442 overruns:0 frame:0
TX packets:8953 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1193963 (1.1 MiB) TX bytes:9274245 (8.8 MiB)
br0:0 Link encap:Ethernet HWaddr CC:E1:D5:DF:08:E0
inet addr:169.254.255.1 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth0 Link encap:Ethernet HWaddr CC:E1:D5:DF:08:E0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:85862 errors:0 dropped:0 overruns:0 frame:0
TX packets:54583 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:18375888 (17.5 MiB) TX bytes:52598230 (50.1 MiB)
Interrupt:5
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MULTICAST MTU:65536 Metric:1
RX packets:1536 errors:0 dropped:0 overruns:0 frame:0
TX packets:1536 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:203165 (198.4 KiB) TX bytes:203165 (198.4 KiB)
ra0 Link encap:Ethernet HWaddr CC:E1:D5:DF:08:E0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:6
tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.3.6 P-t-P:172.16.3.5 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1400 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:1176 (1.1 KiB)
vlan1 Link encap:Ethernet HWaddr CC:E1:D5:DF:08:E0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6929 errors:0 dropped:7 overruns:0 frame:0
TX packets:8949 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1196314 (1.1 MiB) TX bytes:9272170 (8.8 MiB)
vlan2 Link encap:Ethernet HWaddr CC:E1:D5:DF:08:E1
inet addr:192.168.2.50 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:78784 errors:0 dropped:20478 overruns:0 frame:0
TX packets:35211 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:15628054 (14.9 MiB) TX bytes:42518473 (40.5 MiB)netstat -r :
Destination Gateway Genmask Flags MSS Window irtt Iface
default 172.16.3.5 128.0.0.0 UG 0 0 0 tun1
default speedport.ip 0.0.0.0 UG 0 0 0 vlan2
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
128.0.0.0 172.16.3.5 128.0.0.0 UG 0 0 0 tun1
169.254.0.0 * 255.255.0.0 U 0 0 0 br0
172.16.3.0 172.16.3.5 255.255.255.0 UG 0 0 0 tun1
172.16.3.1 172.16.3.5 255.255.255.255 UGH 0 0 0 tun1
172.16.3.5 * 255.255.255.255 UH 0 0 0 tun1
178.5.204.106 speedport.ip 255.255.255.255 UGH 0 0 0 vlan2
192.168.2.0 * 255.255.255.0 U 0 0 0 vlan2
192.168.11.0 * 255.255.255.0 U 0 0 0 br0
192.168.12.0 172.16.3.5 255.255.255.0 UG 0 0 0 tun1Mitschnitt aus dem Syslog über SSH:
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3805]: /sbin/route del -net 128.0.0.0 netmask 128.0.0.0
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3805]: Closing TUN/TAP interface
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3805]: /sbin/ifconfig tun1 0.0.0.0
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3805]: SIGTERM[hard,] received, process exiting
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3040]: OpenVPN 2.3.12 mipsel-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Nov 14 2016
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3040]: library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.09
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3041]: MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:16
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.warn openvpn[3041]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: file '/tmp/openvpncl/client.key' is group or others accessible
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Socket Buffers: R=[172032->172032] S=[172032->172032]
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3041]: UDPv4 link local: [undef]
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3041]: UDPv4 link remote: [AF_INET]178.5.204.106:1194
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3041]: TLS: Initial packet from [AF_INET]178.5.204.106:1194, sid=eb0d0aeb 12c126d8
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3041]: VERIFY OK: depth=1, C=DE, ST=BAWUE, L=REMSHALDEN, O=FRANK, OU=ADMIN_CA, CN=changeme, name=changeme, emailAddress=info@frank-motorgeraete.de
Jan 27 17:54:33 Frank Motorgeraete 2 daemon.notice openvpn[3041]: VERIFY OK: depth=0, C=DE, ST=BAWUE, L=REMSHALDEN, O=FRANK, OU=ADMIN, CN=server, name=changeme, emailAddress=info@frank-motorgerate.de
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1442', remote='link-mtu 1441'
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: this cipher's block size is less than 128 bit (64 bit). Consider using a --cipher with a larger block size.
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: this cipher's block size is less than 128 bit (64 bit). Consider using a --cipher with a larger block size.
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Jan 27 17:54:34 Frank Motorgeraete 2 daemon.notice openvpn[3041]: [server] Peer Connection Initiated with [AF_INET]178.5.204.106:1194
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,route 192.168.12.0 255.255.255.0,route 172.16.3.0 255.255.255.0,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 172.16.3.1,topology net30,ifconfig 1
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: OPTIONS IMPORT: --ifconfig/up options modified
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: NOTE: --mute triggered...
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: 2 variation(s) on previous 3 message(s) suppressed by --mute
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: TUN/TAP device tun1 opened
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: TUN/TAP TX queue length set to 100
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: /sbin/ifconfig tun1 172.16.3.6 pointopoint 172.16.3.5 mtu 1400
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: /sbin/route add -net 178.5.204.106 netmask 255.255.255.255 gw 192.168.2.1
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 172.16.3.5
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 172.16.3.5
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: /sbin/route add -net 192.168.12.0 netmask 255.255.255.0 gw 172.16.3.5
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: /sbin/route add -net 172.16.3.0 netmask 255.255.255.0 gw 172.16.3.5
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: /sbin/route add -net 172.16.3.1 netmask 255.255.255.255 gw 172.16.3.5
Jan 27 17:54:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Initialization Sequence Completed
Jan 27 17:55:20 Frank Motorgeraete 2 authpriv.notice dropbear[3070]: Password auth succeeded for 'root' from 192.168.2.106:53715
Jan 27 17:56:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: [server] Inactivity timeout (--ping-restart), restarting
Jan 27 17:56:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: SIGUSR1[soft,ping-restart] received, process restarting
Jan 27 17:56:36 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Restart pause, 2 second(s)
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.warn openvpn[3041]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Socket Buffers: R=[172032->172032] S=[172032->172032]
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.notice openvpn[3041]: UDPv4 link local: [undef]
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.notice openvpn[3041]: UDPv4 link remote: [AF_INET]178.5.204.106:1194
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.notice openvpn[3041]: TLS: Initial packet from [AF_INET]178.5.204.106:1194, sid=f3dc945e 7ee55dbf
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.notice openvpn[3041]: VERIFY OK: depth=1, C=DE, ST=BAWUE, L=REMSHALDEN, O=FRANK, OU=ADMIN_CA, CN=changeme, name=changeme, emailAddress=info@frank-motorgeraete.de
Jan 27 17:56:39 Frank Motorgeraete 2 daemon.notice openvpn[3041]: VERIFY OK: depth=0, C=DE, ST=BAWUE, L=REMSHALDEN, O=FRANK, OU=ADMIN, CN=server, name=changeme, emailAddress=info@frank-motorgerate.de
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1442', remote='link-mtu 1441'
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: this cipher's block size is less than 128 bit (64 bit). Consider using a --cipher with a larger block size.
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.warn openvpn[3041]: WARNING: this cipher's block size is less than 128 bit (64 bit). Consider using a --cipher with a larger block size.
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Jan 27 17:56:41 Frank Motorgeraete 2 daemon.notice openvpn[3041]: [server] Peer Connection Initiated with [AF_INET]178.5.204.106:1194
Jan 27 17:56:44 Frank Motorgeraete 2 daemon.notice openvpn[3041]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Jan 27 17:56:44 Frank Motorgeraete 2 daemon.notice openvpn[3041]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,route 192.168.12.0 255.255.255.0,route 172.16.3.0 255.255.255.0,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 172.16.3.1,topology net30,ifconfig 1
Jan 27 17:56:44 Frank Motorgeraete 2 daemon.notice openvpn[3041]: OPTIONS IMPORT: --ifconfig/up options modified
Jan 27 17:56:44 Frank Motorgeraete 2 daemon.notice openvpn[3041]: NOTE: --mute triggered...
Jan 27 17:56:44 Frank Motorgeraete 2 daemon.notice openvpn[3041]: 2 variation(s) on previous 3 message(s) suppressed by --mute
Jan 27 17:56:44 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Preserving previous TUN/TAP instance: tun1
Jan 27 17:56:44 Frank Motorgeraete 2 daemon.notice openvpn[3041]: Initialization Sequence Completed
Hi Nintox,
was Dir wohl fehlt ist ein File auf dem Server, welches sich CCD (Client-Config-Directory) nennt.
In diese Datei muss ein iroute Eintrag, als Hinweis auf Dein remotes Netz, in folgender Form (Bsp.-IP) ...
.
In die Server.conf gehört dann der entsprechende Hinweis auf diese Datei...
Existiert diese Datei nicht, macht OpenVPN hier wohl einen Multiclienttunnel mit 2 Client Ip 's...
...hier bei Dir 172.16.3.5 und .6.
Eigentlich sollte die Ifconfig-Ausgabe des Tunnels in etwa so aussehen.
Die Tunnelendpunkte sind dann Server 172.16.3.1 und Client 172.16.3.2
dann sollten eigentlich auch die Tunnelprobleme Geschichte sein.
Gruss orcape
was Dir wohl fehlt ist ein File auf dem Server, welches sich CCD (Client-Config-Directory) nennt.
In diese Datei muss ein iroute Eintrag, als Hinweis auf Dein remotes Netz, in folgender Form (Bsp.-IP) ...
iroute 192.168.55.0 255.255.255.0;In die Server.conf gehört dann der entsprechende Hinweis auf diese Datei...
client-config-dir /Pfad zur CCDtun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.3.6 P-t-P:172.16.3.5 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1400 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:1176 (1.1 KiB)Eigentlich sollte die Ifconfig-Ausgabe des Tunnels in etwa so aussehen.
tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.3.2 P-t-P:172.16.3.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1342 Metric:1
RX packets:1567 errors:0 dropped:0 overruns:0 frame:0
TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:62060 (60.6 KiB) TX bytes:5570 (5.4 KiB)dann sollten eigentlich auch die Tunnelprobleme Geschichte sein.
Gruss orcape
Danke für den Tipp. Wie lege ich denn am besten die Datei an.
Hab mal im offiziellen DD-WRT Forum gesucht, da wird eine Möglichkeit mit Startup-Script genannt und gezeigt:
Beispiel-Code:
OVPN_CCD_DIR="/tmp/openvpn/ccd"
mkdir -p $OVPN_CCD_DIR
echo 'push "route 192.168.1.0 255.255.255.0"' > $OVPN_CCD_DIR/JOHN
Aber würde sehr gerne die Datei via SSH erstellen und beschreiben. Mir fehlt zurzeit nur der nötige Syntax für DD-WRT
Die Remote-Adresse, die da unter iroute eingetragen werden muss wäre das Netz des Client-Routers?
Hab mal im offiziellen DD-WRT Forum gesucht, da wird eine Möglichkeit mit Startup-Script genannt und gezeigt:
Beispiel-Code:
OVPN_CCD_DIR="/tmp/openvpn/ccd"
mkdir -p $OVPN_CCD_DIR
echo 'push "route 192.168.1.0 255.255.255.0"' > $OVPN_CCD_DIR/JOHN
Aber würde sehr gerne die Datei via SSH erstellen und beschreiben. Mir fehlt zurzeit nur der nötige Syntax für DD-WRT
Die Remote-Adresse, die da unter iroute eingetragen werden muss wäre das Netz des Client-Routers?
Danke für den Tipp. Wie lege ich denn am besten die Datei an.
Bei DD-WRT sind die Daten von OpenVPN unter /tmp gespeichert. Bei Neustart also wieder weg. Du solltest Sie also nicht per ssh als Datei unter /tmp abspeichern, sondern im GUI eintragen. Leider habe ich keinen OpenVPN-Server unter DD-WRT am laufen, so das ich Dir hier auch nicht weiter helfen kann.Mit einem Startscript sollte das aber funktionieren.
Die Remote-Adresse, die da unter iroute eingetragen werden muss wäre das Netz des Client-Routers?
Richtig, dessen LAN.Gruss orcape
Dacht ich mir schon fast, das /tmp nachher wieder weg is.
Hab mal auf dem Server von Daemon zu Server umgestellt und da gibt auch ne Config Box mit der CCD.
Jedoch startet nach eintragung der Settings der Server nicht mehr. Bei Daemon gehts einwandfrei.
Hab mal auf dem Server von Daemon zu Server umgestellt und da gibt auch ne Config Box mit der CCD.
Jedoch startet nach eintragung der Settings der Server nicht mehr. Bei Daemon gehts einwandfrei.
Jedoch startet nach eintragung der Settings der Server nicht mehr.
Wie sieht da Dein Eintrag aus ?Wenn das nicht funktioniert, wirst Du wohl ein Script auf dem GUI hinterlegen müssen. Oder den Versuch machen, das File in einem anderen Ordner zu legen und den Pfad entsprechend anpassen. Keine Ahnung ob das machbar ist.
Kurzes Update: Hab mich nun doch für die pfSense Variante entschieden und mir ein APU-Board gekauft.
Alles soweit installiert und würde es nun so ins Netz einbinden:
Speedport Hybrid <--> WAN Port-- pfSense Firewall mit OVPN-Client -- LAN Port <--> Switch <--> Hosts
Macht es Sinn, die pfSense hinter dem Hybrid zu bridgen, dass man weiterhin nur ein Netz hat.
Wäre demjenigen, für den ich die ganze Sache einrichte am liebsten.
Oder sollten es schon 2 Netze werden. z.B 192.168.2.0 als WAN und LAN (hinter der pfSense) 192.168.1.0 ?
Alles soweit installiert und würde es nun so ins Netz einbinden:
Speedport Hybrid <--> WAN Port-- pfSense Firewall mit OVPN-Client -- LAN Port <--> Switch <--> Hosts
Macht es Sinn, die pfSense hinter dem Hybrid zu bridgen, dass man weiterhin nur ein Netz hat.
Wäre demjenigen, für den ich die ganze Sache einrichte am liebsten.
Oder sollten es schon 2 Netze werden. z.B 192.168.2.0 als WAN und LAN (hinter der pfSense) 192.168.1.0 ?
und mir ein APU-Board gekauft.
Eine weise Entscheidung und würde es nun so ins Netz einbinden:
Alles richtig !Macht es Sinn, die pfSense hinter dem Hybrid zu bridgen,
Nein ! Das würde die Firewall dann sinnlos machen.Oder sollten es schon 2 Netze werden.
Ja.Du musst die Tatsache des Transfernetzes dem Besitzer ja gar nicht groß erklären. Ist ja eh ein Punkt zu Punkt Netz mit einer Strippe.
Der brauch nur sein 192.168.1.0 Netz kennen und gut iss.
Vergiss in den pfSense Setup nicht den Haken zu entfernen bei "Block RFC1918 private networks" am WAN Port.
Bei OVPN musst du zudem ein Port Forwarding auf dem Speedport einrichten von UDP 1194 auf die WAN IP Adresse der pfSense so das der Speedport eingehende OVPN Requests auf die FW forwardet.
Alternativ kann man die pfSense WAN IP auch im SP als Exposed Host setzen.
Achte deshalb darauf das das dann eine statische IP ist und keine dynamische per DHCP. Denn sollte die sich mal ändern ists aus mit dem VPN.
@aqui
Gruss orcape
Bei OVPN musst du zudem ein Port Forwarding auf dem Speedport einrichten von UDP 1194 auf die WAN IP Adresse der pfSense so das der Speedport eingehende OVPN Requests auf die FW forwardet.
Ist beim OpenVPN-Client auf der pfSense nicht notwendig. Nur wenn er auf der pfSense einen OpenVPN-Server betreibt. Gruss orcape
OK, das stimmt, da hast du natürlich Recht das das nur für die Server Seite gilt. Sorry für die Verwirrung.
So ...OpenVPN war aus Zeitgründen wieder bisschen auf Eis gelegt. Aber das klingt ja nach deiner Aussage auch schon sehr gut.
Block RFC1918 ist natürlich entfernt. Und VPN Verbindung (Handshake) funktioniert auch. Client schlägt beim Server auf.
Ping ist aber trotz dessen noch nicht möglich.
Auch wenn das hier nicht die schönsten Verschlüsselungen sind hier mal die Logs des Clients:
(Die Verschlüsselung bekommt ein Update mit AES256, sobald alles rennt.)
Apr 1 08:48:47 openvpn 77603 MANAGEMENT: Client disconnected
Apr 1 08:48:47 openvpn 77603 MANAGEMENT: CMD 'status 2'
Apr 1 08:48:47 openvpn 77603 MANAGEMENT: CMD 'state 1'
Apr 1 08:48:47 openvpn 77603 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Apr 1 08:41:15 openvpn 77603 MANAGEMENT: Client disconnected
Apr 1 08:41:15 openvpn 77603 MANAGEMENT: CMD 'status 2'
Apr 1 08:41:15 openvpn 77603 MANAGEMENT: CMD 'state 1'
Apr 1 08:41:15 openvpn 77603 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Apr 1 08:40:52 openvpn 77603 Initialization Sequence Completed
Apr 1 08:40:52 openvpn 77603 /sbin/route add -net 172.16.2.1 172.16.2.5 255.255.255.255
Apr 1 08:40:52 openvpn 77603 /sbin/route add -net 192.168.178.0 172.16.2.5 255.255.255.0
Apr 1 08:40:52 openvpn 77603 /sbin/route add -net 128.0.0.0 172.16.2.5 128.0.0.0
Apr 1 08:40:52 openvpn 77603 /sbin/route add -net 0.0.0.0 172.16.2.5 128.0.0.0
Apr 1 08:40:52 openvpn 77603 /sbin/route add -net 146.60.176.124 192.168.1.1 255.255.255.255
Apr 1 08:40:52 openvpn 77603 /usr/local/sbin/ovpn-linkup ovpnc1 1500 1545 172.16.2.6 172.16.2.5 init
Apr 1 08:40:52 openvpn 77603 /sbin/ifconfig ovpnc1 172.16.2.6 172.16.2.5 mtu 1500 netmask 255.255.255.255 up
Apr 1 08:40:52 openvpn 77603 do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
Apr 1 08:40:52 openvpn 77603 TUN/TAP device /dev/tun1 opened
Apr 1 08:40:52 openvpn 77603 TUN/TAP device ovpnc1 exists previously, keep at program end
Apr 1 08:40:52 openvpn 77603 ROUTE_GATEWAY 192.168.1.1
Apr 1 08:40:52 openvpn 77603 OPTIONS IMPORT: adjusting link_mtu to 1545
Apr 1 08:40:52 openvpn 77603 OPTIONS IMPORT: peer-id set
Apr 1 08:40:52 openvpn 77603 OPTIONS IMPORT: route options modified
Apr 1 08:40:52 openvpn 77603 OPTIONS IMPORT: --ifconfig/up options modified
Apr 1 08:40:52 openvpn 77603 OPTIONS IMPORT: timers and/or timeouts modified
Apr 1 08:40:52 openvpn 77603 Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:2: dhcp-options (2.3.14)
Apr 1 08:40:52 openvpn 77603 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-options DNS 8.8.4.4,route 172.16.2.1,topology net30,ping 10,ping-restart 120,ifconfig 172.16.2.6 172.16.2.5,peer-id 1'
Apr 1 08:40:52 openvpn 77603 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Apr 1 08:40:49 openvpn 77603 [server] Peer Connection Initiated with [AF_INET]146.60.176.124:1194
Apr 1 08:40:49 openvpn 77603 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Apr 1 08:40:49 openvpn 77603 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Apr 1 08:40:49 openvpn 77603 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Apr 1 08:40:49 openvpn 77603 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Apr 1 08:40:49 openvpn 77603 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Apr 1 08:40:49 openvpn 77603 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Apr 1 08:40:49 openvpn 77603 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Apr 1 08:40:49 openvpn 77603 VERIFY OK: depth=0, C=DE, ST=BAWUE, L=, O=, OU=ADMIN, CN=server, name=changeme, emailAddress= (GEKÜRZT!)
Apr 1 08:40:49 openvpn 77603 VERIFY OK: depth=1, C=DE, ST=BAWUE, L=, O=, OU=ADMIN_, CN=changeme, name=changeme, emailAddress= (GEKÜRZT!)
Apr 1 08:40:49 openvpn 77603 TLS: Initial packet from [AF_INET]146.60.176.124:1194, sid=099cb01f 9a7ad5fc
Apr 1 08:40:49 openvpn 77603 UDPv4 link remote: [AF_INET]146.60.176.124:1194
Apr 1 08:40:49 openvpn 77603 UDPv4 link local: [undef]
Apr 1 08:40:49 openvpn 77603 Socket Buffers: R=[42080->42080] S=[57344->57344]
Apr 1 08:40:49 openvpn 77603 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 1 08:40:49 openvpn 77603 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Apr 1 08:40:49 openvpn 77603 WARNING: using --pull/--client and --ifconfig together is probably not what you want
Apr 1 08:40:49 openvpn 77603 MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
Apr 1 08:40:49 openvpn 77568 library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.09
Apr 1 08:40:49 openvpn 77568 OpenVPN 2.3.14 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Feb 15 2017
Apr 1 08:40:49 openvpn 91998 SIGTERM[hard,] received, process exiting
Apr 1 08:40:48 openvpn 91998 /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1544 172.16.2.6 172.16.2.5 init
Hier noch 2 Bilder der Firewall Settings:
Block RFC1918 ist natürlich entfernt. Und VPN Verbindung (Handshake) funktioniert auch. Client schlägt beim Server auf.
Ping ist aber trotz dessen noch nicht möglich.
Auch wenn das hier nicht die schönsten Verschlüsselungen sind hier mal die Logs des Clients:
(Die Verschlüsselung bekommt ein Update mit AES256, sobald alles rennt.)
Apr 1 08:48:47 openvpn 77603 MANAGEMENT: Client disconnected
Apr 1 08:48:47 openvpn 77603 MANAGEMENT: CMD 'status 2'
Apr 1 08:48:47 openvpn 77603 MANAGEMENT: CMD 'state 1'
Apr 1 08:48:47 openvpn 77603 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Apr 1 08:41:15 openvpn 77603 MANAGEMENT: Client disconnected
Apr 1 08:41:15 openvpn 77603 MANAGEMENT: CMD 'status 2'
Apr 1 08:41:15 openvpn 77603 MANAGEMENT: CMD 'state 1'
Apr 1 08:41:15 openvpn 77603 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Apr 1 08:40:52 openvpn 77603 Initialization Sequence Completed
Apr 1 08:40:52 openvpn 77603 /sbin/route add -net 172.16.2.1 172.16.2.5 255.255.255.255
Apr 1 08:40:52 openvpn 77603 /sbin/route add -net 192.168.178.0 172.16.2.5 255.255.255.0
Apr 1 08:40:52 openvpn 77603 /sbin/route add -net 128.0.0.0 172.16.2.5 128.0.0.0
Apr 1 08:40:52 openvpn 77603 /sbin/route add -net 0.0.0.0 172.16.2.5 128.0.0.0
Apr 1 08:40:52 openvpn 77603 /sbin/route add -net 146.60.176.124 192.168.1.1 255.255.255.255
Apr 1 08:40:52 openvpn 77603 /usr/local/sbin/ovpn-linkup ovpnc1 1500 1545 172.16.2.6 172.16.2.5 init
Apr 1 08:40:52 openvpn 77603 /sbin/ifconfig ovpnc1 172.16.2.6 172.16.2.5 mtu 1500 netmask 255.255.255.255 up
Apr 1 08:40:52 openvpn 77603 do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
Apr 1 08:40:52 openvpn 77603 TUN/TAP device /dev/tun1 opened
Apr 1 08:40:52 openvpn 77603 TUN/TAP device ovpnc1 exists previously, keep at program end
Apr 1 08:40:52 openvpn 77603 ROUTE_GATEWAY 192.168.1.1
Apr 1 08:40:52 openvpn 77603 OPTIONS IMPORT: adjusting link_mtu to 1545
Apr 1 08:40:52 openvpn 77603 OPTIONS IMPORT: peer-id set
Apr 1 08:40:52 openvpn 77603 OPTIONS IMPORT: route options modified
Apr 1 08:40:52 openvpn 77603 OPTIONS IMPORT: --ifconfig/up options modified
Apr 1 08:40:52 openvpn 77603 OPTIONS IMPORT: timers and/or timeouts modified
Apr 1 08:40:52 openvpn 77603 Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:2: dhcp-options (2.3.14)
Apr 1 08:40:52 openvpn 77603 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-options DNS 8.8.4.4,route 172.16.2.1,topology net30,ping 10,ping-restart 120,ifconfig 172.16.2.6 172.16.2.5,peer-id 1'
Apr 1 08:40:52 openvpn 77603 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Apr 1 08:40:49 openvpn 77603 [server] Peer Connection Initiated with [AF_INET]146.60.176.124:1194
Apr 1 08:40:49 openvpn 77603 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
Apr 1 08:40:49 openvpn 77603 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Apr 1 08:40:49 openvpn 77603 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Apr 1 08:40:49 openvpn 77603 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Apr 1 08:40:49 openvpn 77603 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Apr 1 08:40:49 openvpn 77603 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Apr 1 08:40:49 openvpn 77603 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Apr 1 08:40:49 openvpn 77603 VERIFY OK: depth=0, C=DE, ST=BAWUE, L=, O=, OU=ADMIN, CN=server, name=changeme, emailAddress= (GEKÜRZT!)
Apr 1 08:40:49 openvpn 77603 VERIFY OK: depth=1, C=DE, ST=BAWUE, L=, O=, OU=ADMIN_, CN=changeme, name=changeme, emailAddress= (GEKÜRZT!)
Apr 1 08:40:49 openvpn 77603 TLS: Initial packet from [AF_INET]146.60.176.124:1194, sid=099cb01f 9a7ad5fc
Apr 1 08:40:49 openvpn 77603 UDPv4 link remote: [AF_INET]146.60.176.124:1194
Apr 1 08:40:49 openvpn 77603 UDPv4 link local: [undef]
Apr 1 08:40:49 openvpn 77603 Socket Buffers: R=[42080->42080] S=[57344->57344]
Apr 1 08:40:49 openvpn 77603 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 1 08:40:49 openvpn 77603 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Apr 1 08:40:49 openvpn 77603 WARNING: using --pull/--client and --ifconfig together is probably not what you want
Apr 1 08:40:49 openvpn 77603 MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
Apr 1 08:40:49 openvpn 77568 library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.09
Apr 1 08:40:49 openvpn 77568 OpenVPN 2.3.14 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Feb 15 2017
Apr 1 08:40:49 openvpn 91998 SIGTERM[hard,] received, process exiting
Apr 1 08:40:48 openvpn 91998 /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1544 172.16.2.6 172.16.2.5 init
Hier noch 2 Bilder der Firewall Settings:
Ping ist aber trotz dessen noch nicht möglich.
Das ist auch vollkommen klar, denn es kommt KEIN OpenVPN Tunnel zustande!: openvpn 77603 WARNING: No server certificate verification method has been enabled.
Und dann stoppt der Tunnel:
received, process exiting.... ovpn-linkdown ovpnc1
Ohne VPN Tunnel natürlich auch kein Ping...logisch !
Das hättest du ja anhand der Log Einträge doch auch selber sehen können. Man sollte halt mal lesen was da steht...
Kann das sein das du das Kommando ns-cert-type server in deiner Konfig Datei vergessen hast ?? Darauf basiert die o.a.Log Fehlermeldung.
https://openvpn.net/index.php/open-source/documentation/howto.html#mitm
Wenn ja füge die hinzu das sollte das Problem fixen und den Ping zum Fliegen bringen.
Zitat von @aqui:
Kann das sein das du das Kommando ns-cert-type server in deiner Konfig Datei vergessen hast ?? Darauf basiert die o.a.Log Fehlermeldung.
https://openvpn.net/index.php/open-source/documentation/howto.html#mitm
Wenn ja füge die hinzu das sollte das Problem fixen und den Ping zum Fliegen bringen.
Kann das sein das du das Kommando ns-cert-type server in deiner Konfig Datei vergessen hast ?? Darauf basiert die o.a.Log Fehlermeldung.
https://openvpn.net/index.php/open-source/documentation/howto.html#mitm
Wenn ja füge die hinzu das sollte das Problem fixen und den Ping zum Fliegen bringen.
Ähhm ... du hast recht. Ist in der pfSense ja mit einer CheckBox (Client-seitig) zu setzen.
Zumindest kommt nun keine solche Meldung mehr.
Aber Ping fliegt trotzdem noch nicht.
Was sagst du zur Firewall? Geht das so?
Servernetz: 192.168.178.0 255.255.255.0
Clientnetz: 192.168.2.0 255.255.255.0 --> WAN Netz zwischen Firewall und Hybrid 192.168.1.1 255.255.255.0 --> WAN Adresse Telekom
Sieht für mich zurzeit immer mehr nach einem Routing-Problem aus.
Aber Ping fliegt trotzdem noch nicht.
Bitte nochmal Log posten hier vom Verbindungsaufbau ! Vertrauen ist gut Kontrolle ist besser Du musst ganz sicher sein das der VPN Tunnel steht.
- Kannst du das interne VPN Tunnel Interface pingen ? (ICMP Regel dafür nicht vergessen !)
- Kannst du das lokale LAN Interface der FW pingen )
- Hast du im virtuellen VPN Interface der Firewall eine entsprechende Regel erstellt die den Zugriff aus dem internen OVPN Tunnelnetz erlaubt ?? Ggf. auch mal Screenshot posten hier zur Kontrolle.
Routingproblem in Homerouter-Kaskade mit Raspi
Was sagst du zur Firewall? Geht das so?
IP technisch ja, hast ja 2 unterschiedliche IP Netze (das 3te interne bei OVPN mal wieder vergessen 
) also VPN seitig ist das OK.Sieht für mich zurzeit immer mehr nach einem Routing-Problem aus.
Das wäre möglich... Leider fehlt dazu mal eine grobe Netzwerkskizze wie die IP Segmente verschaltet sind. Dann könnte man das ganz genau sagen.OVPN in einer Routerkaskade ist hier beschrieben:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Also ggf. mal Skizze posten hier und wie dein Routing aussieht.
Poste mal die Routingtabellen von Server und Client. Deine IP-Belegung OpenVPN-Server/Client mit 172.16.2.1/ 172.16.2.5 bzw. 172.16.2.6 sieht mir sehr danach aus, wie wenn keine Clientspezifische Datei im Server existiert bzw. ein Multiclienttunnel aufgebaut wird. Dann wird Dir zwar ein Tunnel gebaut, bekommst aber kein ping drüber.
172.16.2.1 Server
172.16.2.2 Client ....wäre Ok.
172.16.2.1 Server
172.16.2.2 Client ....wäre Ok.
Hab hier mal die Routing Tables bei aktiver Open-VPN-Connection.
Was IP-Belegung angeht, was meinst du da genau?
Also die andere Seite kann ich auch direkt im VPN-Netz (172.16.2.0) nicht pingen. Nur lokale IP bis zum GW-Router des Clients (192.168.1.1)
Was IP-Belegung angeht, was meinst du da genau?
Also die andere Seite kann ich auch direkt im VPN-Netz (172.16.2.0) nicht pingen. Nur lokale IP bis zum GW-Router des Clients (192.168.1.1)
Wegen der fehlenden Netzwerkskizze ist das jetzt ein kleines Ratespiel
Also beim obigen schwarzen Klotz, was vermutlich der Buffalo ist fehlen de facto Routen. Das lokale Netwerk des Routers unten (weiße Tabelle) lautet ja 192.168.1.0 /24 wenn man das richtig sieht.
Dieses IP Netz wird NICHT an den Router (schwarze Tabelle) propagiert.
Der "weiße Router" sieht auch nur das WAN Netzwerk .178.0 aber nicht das lokale LAN .12.0 am "schwarzen Router"
Das kannst du ja auch direkt selber sehen wenn du dir die beiden Routing Tabellen ansiehst !!!
Es fehlt immer das jeweils remote lokale LAN.
Ein sicheres Zeichen dafür das deine beiden Konfig Datein noch fehlerhaft sind und dort Routing Kommandos fehlen um diese Routen zu propagieren innerhalb des VPN Netzes.
Passiert das nicht gehen diese IP Netze immer in Richtung Provider und damit dann ins Nirwana.
Genau das was du also siehst mit deinen fehlschlagenden Pings.
Um sinnvoll weiterzukommen solltest du also mal deine beiden Konfig Dateien posten hier von beiden Routern. Und...ggf. eine grobe Skizze wie das Netzwerk jetzt verschaltet ist.
Also beim obigen schwarzen Klotz, was vermutlich der Buffalo ist fehlen de facto Routen. Das lokale Netwerk des Routers unten (weiße Tabelle) lautet ja 192.168.1.0 /24 wenn man das richtig sieht.
Dieses IP Netz wird NICHT an den Router (schwarze Tabelle) propagiert.
Der "weiße Router" sieht auch nur das WAN Netzwerk .178.0 aber nicht das lokale LAN .12.0 am "schwarzen Router"
Das kannst du ja auch direkt selber sehen wenn du dir die beiden Routing Tabellen ansiehst !!!
Es fehlt immer das jeweils remote lokale LAN.
Ein sicheres Zeichen dafür das deine beiden Konfig Datein noch fehlerhaft sind und dort Routing Kommandos fehlen um diese Routen zu propagieren innerhalb des VPN Netzes.
Passiert das nicht gehen diese IP Netze immer in Richtung Provider und damit dann ins Nirwana.
Genau das was du also siehst mit deinen fehlschlagenden Pings.
Um sinnvoll weiterzukommen solltest du also mal deine beiden Konfig Dateien posten hier von beiden Routern. Und...ggf. eine grobe Skizze wie das Netzwerk jetzt verschaltet ist.
Dein Problem liegt nach wie vor bei diesem, von mir bereits geposteten Problem....
Dein Tunnel ist ein Multiclienttunnel, deshalb die nicht funktionierende Verbindung.
Lies Dir das noch mal Durch....
Bei Dir Server-IP...
172.16.3.1 / 172.16.3.2
Client-IP...
172.16.3.6 / 172.16.3.5
Dabei sollten Sich nur die IP 's 172.16.3.1 und 172.16.3.6 pingen lassen.
Ich habe da ohne CCD aber auch schon einige Probleme gehabt eine Verbindung zu bekommen.
Normal wäre....
Server-IP
172.16.3.1
Client-IP
172.16.3.2
Ansonsten kann ich @aqui nur recht geben...
tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
02.
inet addr:172.16.3.6 P-t-P:172.16.3.5 Mask:255.255.255.255 Lies Dir das noch mal Durch....
Mitglied: orcape
28.01.2017 um 09:12 Uhr
28.01.2017 um 09:12 Uhr
Bei Dir Server-IP...
172.16.3.1 / 172.16.3.2
Client-IP...
172.16.3.6 / 172.16.3.5
Dabei sollten Sich nur die IP 's 172.16.3.1 und 172.16.3.6 pingen lassen.
Ich habe da ohne CCD aber auch schon einige Probleme gehabt eine Verbindung zu bekommen.
Normal wäre....
Server-IP
172.16.3.1
Client-IP
172.16.3.2
Ansonsten kann ich @aqui nur recht geben...
Um sinnvoll weiterzukommen solltest du also mal deine beiden Konfig Dateien posten hier von beiden Routern.
Client Config:
Server Config:
port 1194
proto udp
dev tun0
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
dh /tmp/openvpn/dh.pem
server 172.16.2.0 255.255.255.0
push "route 192.168.12.0 255.255.255.0"
push "dhcp-options DNS 192.168.12.1"
keepalive 10 120
comp-lzo
persist-key
persist-tun
script-security 3
verb 3
management localhost 14
mute-replay-warnings
Aufbau Netz:
Server Config:
port 1194
proto udp
dev tun0
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
dh /tmp/openvpn/dh.pem
server 172.16.2.0 255.255.255.0
push "route 192.168.12.0 255.255.255.0"
push "dhcp-options DNS 192.168.12.1"
keepalive 10 120
comp-lzo
persist-key
persist-tun
script-security 3
verb 3
management localhost 14
mute-replay-warnings
Aufbau Netz:
1. Du hast weder das Tunnelnetzwerk (172.16.2.0 255.255.255.0) noch Dein remotes Netzwerk (sprich LAN hinter dem Server) in der Client.conf eingetragen.
2. Costum Optionen (Client)
2. Costum Optionen (Client)
ns-cert-type server;
tun-mtu 1400; (beim Server ebenfalls, sonst hast Du Probleme bei der Stabilität der Paketübertragung)
tun-mtu 1400; (beim Server ebenfalls, sonst hast Du Probleme bei der Stabilität der Paketübertragung)
Okey, ja die hatte ich drin. Habs aber wieder raus, weil ein OVPN Client Guide direkt im pfSense Forum aussagt, dass man das blanked lassen soll.
Vermutlich aber falsch.
Ich versuchs mal.
Vermutlich aber falsch.
Ich versuchs mal.
UPDATE:
Habs nun geändert und den Ping direkt auf der pfSense als auch auf dem Host dahinter getestet.
Host erreicht noch nichts. Auch via Paket Capture bekommen die Pings zum VPN Server bzw. das Netz dahinter kein Replay.
Jedoch bekomm ich mit Pings direkt auf der pfSense sowohl von Server-Netz als auch vom Lan-Netz dahinter antworten.
Irgendwie kennt der Host die Route noch nicht, kann das sein?
Firewalls (Windows als auch Software) wurde auf dem Host auch schon für den Test deaktiviert.
Habs nun geändert und den Ping direkt auf der pfSense als auch auf dem Host dahinter getestet.
Host erreicht noch nichts. Auch via Paket Capture bekommen die Pings zum VPN Server bzw. das Netz dahinter kein Replay.
Jedoch bekomm ich mit Pings direkt auf der pfSense sowohl von Server-Netz als auch vom Lan-Netz dahinter antworten.
Irgendwie kennt der Host die Route noch nicht, kann das sein?
Firewalls (Windows als auch Software) wurde auf dem Host auch schon für den Test deaktiviert.
Hast Du denn auf der pfSense für ping eine Firewallregel erstellt? ICMP - source (host-IP) erlauben.
Kannst Du alles in den pfSense Logs nachschauen ob da was geblockt wird.
Status-Systemlogs-Firewall
Kannst Du alles in den pfSense Logs nachschauen ob da was geblockt wird.
Status-Systemlogs-Firewall
Jedoch bekomm ich mit Pings direkt auf der pfSense sowohl von Server-Netz als auch vom Lan-Netz dahinter antworten.
Damit meinst du wenn du via VPN die lokalen pfSense IP Adressen des LAN Ports und des Server Netz Ports anpingst dann bekommst du eine Antwort ??Wenn dem so ist dann funktioniert dein VPN fehlerlos.
Wenn Hosts sowohl im LAN Netz als auch im Server Netz auf Pings nicht antworten, dann ist das zu 98% deren lokale Firewall die das verhindert.
Pings (ICMP Protokoll) werden per Default geblockt in der Winblows Firewall:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Und da du einen fremde IP Absenderadresse hast werden diese Pakete auch geblockt, denn die lokale Win Firewall lässt nur IPs aus dem eigenen LAN passieren auf die internen Dienste.
Hier musst du also die Firewall anpassen.
Nicht ganz.
Ich hab die pfSense ja auf Client-Seite und den DDWRT Router auf Server-Seite. Von der pfSense kann ich einen erfolgreichen Ping auf den DDWRT Router (VPN Netz ) als auch das Netz dahinter (192.168.12.0) absetzen.
Aber wenn ich die Firewall (Windows) und Firewall Software deaktiviere muss doch ein Ping von einem Host hinter der pfSense genauso funktionieren wie direkt auf der Sense. Von Host auf pfSense bekomme ich ja auch ein Ping. Logisch, ist ja sein Gateway.
Ich hab die pfSense ja auf Client-Seite und den DDWRT Router auf Server-Seite. Von der pfSense kann ich einen erfolgreichen Ping auf den DDWRT Router (VPN Netz ) als auch das Netz dahinter (192.168.12.0) absetzen.
Aber wenn ich die Firewall (Windows) und Firewall Software deaktiviere muss doch ein Ping von einem Host hinter der pfSense genauso funktionieren wie direkt auf der Sense. Von Host auf pfSense bekomme ich ja auch ein Ping. Logisch, ist ja sein Gateway.
Ist denn ein Ping erlaubt ?
Hast Du denn auf der pfSense für ping eine Firewallregel erstellt? ICMP - source (host-IP) erlauben.
Ja, gerade eben nochmals mit einer extra Rule für den Test-Host hinter der PFSense getestet.
Kein Ping möglich. Das es auf der pfSense geht, sieht man im Screenshot.
Kein Ping möglich. Das es auf der pfSense geht, sieht man im Screenshot.
Dann log Dich per ssh auf der pfSense ein.
Gib "netstat -r" ein und poste mal bitte die Ausgabe.
Gib "netstat -r" ein und poste mal bitte die Ausgabe.
Den SSH Login muss er aber erst im Advanced Setup aktivieren
Es geht parallel auch über den Terminal Anschluss und Menüpunkt 8 (Shell)
Die Frage auch WO diese "Extra Rule" definiert wurde ?? Wenn dann muss es eine Regel am virtuellen VPN Adapter sein der FW. Der Screenshot also vom OVPN Interface wäre weit sinnvoller gewesen als ein gescheiterter Ping oder der überflüssige Shot vom LAN Interface mit der any zu any Scheunentorregel.
Das OVPN Interface ist relevant...sonst nix.
Vermutlich fehlen dort alle Regeln....?!
Es geht parallel auch über den Terminal Anschluss und Menüpunkt 8 (Shell)
Die Frage auch WO diese "Extra Rule" definiert wurde ?? Wenn dann muss es eine Regel am virtuellen VPN Adapter sein der FW. Der Screenshot also vom OVPN Interface wäre weit sinnvoller gewesen als ein gescheiterter Ping oder der überflüssige Shot vom LAN Interface mit der any zu any Scheunentorregel.
Das OVPN Interface ist relevant...sonst nix.
Vermutlich fehlen dort alle Regeln....?!
@orcape:
netstat -r
@aqui: SSH hab ich schon aktiviert gehabt, aber danke für den Hinweis
Natürlich wurde die Rule auf dem OVPN Interface festgelegt. Auf dem LAN hab ich es dann aber auch noch getestet.
Und die Scheunenregel soll das Problem jetzt einfach nicht unnötig erschweren. Läuft das Ding mal, werden die Rules sauber gesetzt. Für ein Produktivsystem ist das natürlich ein NOGO.
netstat -r
Internet:
Destination Gateway Flags Netif Expire
0.0.0.0/1 172.16.2.1 UGS ovpnc1
default 192.168.1.1 UGS igb0
google-public-dns- 192.168.1.1 UGHS igb0
google-public-dns- 192.168.1.1 UGHS igb0
localhost link#7 UH lo0
128.0.0.0/1 172.16.2.1 UGS ovpnc1
172.16.2.0/29 link#9 U ovpnc1
172.16.2.2 link#9 UHS lo0
188.104.248.190/32 192.168.1.1 UGS igb0
192.168.1.0 link#1 U igb0
192.168.1.1 00:0d:b9:43:27:a0 UHS igb0
192.168.1.104 link#1 UHS lo0
192.168.2.0 link#2 U igb1
PandaSave link#2 UHS lo0
192.168.12.0 172.16.2.1 UGS ovpnc1
192.168.178.0 172.16.2.1 UGS ovpnc1
Internet6:
Destination Gateway Flags Netif Expire
default fe80::1%igb0 UGS igb0
localhost link#7 UH lo0
p2003006A681C6C140 link#1 U igb0
p2003006A681C6C140 link#1 UHS lo0
p2003006A681C6C350 link#1 U igb0
p2003006A681C6C350 link#1 UHS lo0
p2003006A681C6C400 link#1 U igb0
p2003006A681C6C400 link#1 UHS lo0
p2003006A681C6C440 link#1 U igb0
p2003006A681C6C440 link#1 UHS lo0
p2003006A681C6C550 link#1 U igb0
p2003006A681C6C550 link#1 UHS lo0
fe80::1 fe80::1%igb0 UGHS igb0
fe80::%igb0 link#1 U igb0
fe80::20d:b9ff:fe4 link#1 UHS lo0
fe80::%igb1 link#2 U igb1
fe80::20d:b9ff:fe4 link#2 UHS lo0
fe80::%lo0 link#7 U lo0
fe80::1%lo0 link#7 UHS lo0
fe80::2bd:c1ff:fed link#9 UHS lo0
ff01::%igb0 fe80::20d:b9ff:fe4 U igb0
ff01::%igb1 fe80::20d:b9ff:fe4 U igb1
ff01::%lo0 localhost U lo0
ff01::%ovpnc1 fe80::2bd:c1ff:fed U ovpnc1
ff02::%igb0 fe80::20d:b9ff:fe4 U igb0
ff02::%igb1 fe80::20d:b9ff:fe4 U igb1
ff02::%lo0 localhost U lo0
ff02::%ovpnc1 fe80::2bd:c1ff:fed U ovpnc1@aqui: SSH hab ich schon aktiviert gehabt, aber danke für den Hinweis
Natürlich wurde die Rule auf dem OVPN Interface festgelegt. Auf dem LAN hab ich es dann aber auch noch getestet.
Und die Scheunenregel soll das Problem jetzt einfach nicht unnötig erschweren. Läuft das Ding mal, werden die Rules sauber gesetzt. Für ein Produktivsystem ist das natürlich ein NOGO.
Nur mal zum Vergleich ein netstat -r einer pfSense mit OpenVPN-Client...
Wenn man ein /24 er Netz als Tunnelnetz verwendet, macht OpenVPN dann virtuell ein /32 er Netz, wie Du bei mir siehst....
Du solltest Deine Einstellungen hierzu noch einmal checken. Irgend etwas stimmt da noch nicht. Ich hatte bei meinen ersten OpenVPN-Versuchen auch solche Probleme und dann keine Verbindung ins remote Netz.
[2.3.3-RELEASE][root@bengie.orca.net]/root: netstat -r
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default fritz.box UGS vr0
10.12.7.1 link#10 UH ovpnc2
10.12.7.1/32 10.12.7.1 UGS ovpnc2
10.12.7.2 link#10 UHS lo0
10.15.8.0 10.12.7.1 UGS ovpnc2
localhost link#7 UH lo0
172.16.7.0 10.12.7.1 UGS ovpnc2
172.16.8.0 link#3 U vr2
172.16.8.1 link#3 UHS lo0
192.168.1.0 link#1 U vr0
192.168.1.2 link#1 UHS lo0
192.168.18.0 link#2 U vr1
bengie link#2 UHS lo0
192.168.66.0 link#9 U ath0_wla
192.168.66.1 link#9 UHS lo0
192.168.155.0 10.12.7.1 UGS ovpnc2
Internet6:
Destination Gateway Flags Netif Expire
localhost link#7 UH lo0
fe80::%vr0 link#1 U vr0
fe80::20d:b9ff:fe2 link#1 UHS lo0
fe80::%vr1 link#2 U vr1
fe80::20d:b9ff:fe2 link#2 UHS lo0
fe80::%vr2 link#3 U vr2
fe80::20d:b9ff:fe2 link#3 UHS lo0
fe80::%lo0 link#7 U lo0
fe80::1%lo0 link#7 UHS lo0
fe80::%ath0_wlan0 link#9 U ath0_wla
fe80::20b:6bff:fe2 link#9 UHS lo0
fe80::%ovpnc2 link#10 U ovpnc2
fe80::20d:b9ff:fe2 link#10 UHS lo0
ff01::%vr0 fe80::20d:b9ff:fe2 U vr0
ff01::%vr1 fe80::20d:b9ff:fe2 U vr1
ff01::%vr2 fe80::20d:b9ff:fe2 U vr2
ff01::%lo0 localhost U lo0
ff01::%ath0_wlan0 fe80::20b:6bff:fe2 U ath0_wla
ff01::%ovpnc2 fe80::20d:b9ff:fe2 U ovpnc2
ff02::%vr0 fe80::20d:b9ff:fe2 U vr0
ff02::%vr1 fe80::20d:b9ff:fe2 U vr1
ff02::%vr2 fe80::20d:b9ff:fe2 U vr2
ff02::%lo0 localhost U lo0
ff02::%ath0_wlan0 fe80::20b:6bff:fe2 U ath0_wla
ff02::%ovpnc2 fe80::20d:b9ff:fe2 U ovpnc2Wenn man ein /24 er Netz als Tunnelnetz verwendet, macht OpenVPN dann virtuell ein /32 er Netz, wie Du bei mir siehst....
10.12.7.1/32 10.12.7.1 UGS ovpnc2
bei Dir erscheint ein /29 er Netz.Du solltest Deine Einstellungen hierzu noch einmal checken. Irgend etwas stimmt da noch nicht. Ich hatte bei meinen ersten OpenVPN-Versuchen auch solche Probleme und dann keine Verbindung ins remote Netz.
Und was hast du dann gemacht, es zu beheben?
...die Server.conf Datei editiert natürlich und den Fehler behoben !!
Kann man bei dir schön sehen. .1 ist der Server. 2 der Client.
Die klassische Route beim Kollegen Orcape zeigt das 10.15.8.0 Subentz oben. So sieht eine Bilderbuch OVPN Client Routing Tabelle aus
Ganz so falsch ist die Routing Tabelle des TO im Grundsatz nicht, allerdings offenbaren da diverse Einträge das da etwas sehr im Argen liegt mit der server.conf Datei oder auch ggf. der client.conf Datei:
Hier können wir aber jetzt nur wild raten und spekulieren....
macht OpenVPN dann virtuell ein /32 er Netz
Das ist auch normal, denn das interne VPN Netz ist ein Point to Pont Netz mit /32er Hostrouten Kann man bei dir schön sehen. .1 ist der Server. 2 der Client.
Die klassische Route beim Kollegen Orcape zeigt das 10.15.8.0 Subentz oben. So sieht eine Bilderbuch OVPN Client Routing Tabelle aus
Ganz so falsch ist die Routing Tabelle des TO im Grundsatz nicht, allerdings offenbaren da diverse Einträge das da etwas sehr im Argen liegt mit der server.conf Datei oder auch ggf. der client.conf Datei:
- 0.0.0.0/1 Bedeutet das ja ein Default Gateway Redirect hier vorliegt. Ist der Client aktiv wird sämtlicher Traffic in den Tunnel geroutet. Siehe dazu auch HIER Setzen wir mal voraus das das auch so gewollt ist.
- Dann ist aber das Pushen der v4 Routen:
- 128.0.0.0/1, 192.168.12.0 und 192.168.178.0 zusätzlich ja völliger Blödsinn, denn wenn eh alles in den Tunnel geht muss man diese IP Netze ja nicht noch überflüssigerweise extra nochmal angeben. Das zeigt schon einen Fehler.
- Die Subnetzmasle "/1" an der Default Route und dem 128er Netz deutet auch auf einen Tippfehler oder Maskenfehler irgendwo in der Konfig hin.
Hier können wir aber jetzt nur wild raten und spekulieren....
@orcape
Also das /32 hab ich schon mal. Aber Pings von Hosts hinter der Sense funktioniert immer noch nicht.
Ich muss aber nicht weitere Konfigs an den Interfaces vornehmen. Hab da eben ein WAN und ein LAN definiert.
Weil manche Guides packen da noch ein OPT1 Interface dazu auf dem der VPN läuft.
@aqui: Hab die push Rules auf dem Server rausgenommen.
Internet:
Destination Gateway Flags Netif Expire
default 192.168.1.1 UGS igb0
google-public-dns- 192.168.1.1 UGHS igb0
google-public-dns- 192.168.1.1 UGHS igb0
localhost link#7 UH lo0
172.16.2.1/32 172.16.2.5 UGS ovpnc1
172.16.2.5 link#8 UH ovpnc1
172.16.2.6 link#8 UHS lo0
192.168.1.0 link#1 U igb0
192.168.1.1 00:0d:b9:43:27:a0 UHS igb0
192.168.1.104 link#1 UHS lo0
192.168.2.0 link#2 U igb1
PandaSave link#2 UHS lo0
192.168.12.0 172.16.2.5 UGS ovpnc1Also das /32 hab ich schon mal. Aber Pings von Hosts hinter der Sense funktioniert immer noch nicht.
Ich muss aber nicht weitere Konfigs an den Interfaces vornehmen. Hab da eben ein WAN und ein LAN definiert.
Weil manche Guides packen da noch ein OPT1 Interface dazu auf dem der VPN läuft.
@aqui: Hab die push Rules auf dem Server rausgenommen.
Ich muss aber nicht weitere Konfigs an den Interfaces vornehmen.
Doch natürlich !Du musst einmal die Firewall Regeln im LAN anpassen und noch viel wichtiger die Firewall Regel am virtuellen OVPN Interface in der Firewall !!
Per Default sind dort deny any any Regeln wie bei einer Firewall üblich sprich also alles verboten !
Das musst du anpassen sonst blockt die Firewall sämtlichen Traffic.
@aqui
Die Firewall Rules sind denke ich soweit gesetzt, dass es klappen sollte.
Meinte jetzt mehr die direkte Konfig der Interfaces. Das man da irgendwie noch was bridgen muss.
Die Firewall Rules sind denke ich soweit gesetzt, dass es klappen sollte.
Meinte jetzt mehr die direkte Konfig der Interfaces. Das man da irgendwie noch was bridgen muss.
07. 172.16.2.1/32 172.16.2.5 UGS ovpnc1
08. 172.16.2.5 link#8 UH ovpnc1
09. 172.16.2.6 link#8 UHS lo0 Immer noch ein Multiclienttunnel...
Zum Vergleich...
08. 10.12.7.1/32 10.12.7.1 UGS ovpnc2
09. 10.12.7.2 link#10 UHS lo0 Gruss orcape
@aqui @orcape
So, Pings funktionieren nun.
Lag an einer NAT Einstellung an der Sense.
Nur klappt das Internet bzw. DNS Resolve noch nich ganz.
Hab auf Server-Seite push redirect-gateway def 1 drin und auch den Google DNS dort angegeben.
Muss da noch was an der pfSense gemacht werden?
UPDATE:
Jetzt wirds total strange, ich kann Google via Browser nutzen. Gibt auch die Suchergebnisse an. Aber wenn ich auf eine Website will, kommt ein DNS Timeout.
Hab die MTU mal auf 1300 gesetzt. Weil ich dachte, vielleicht sind die Pakete zu groß. Aber hat nichts geändert.
So, Pings funktionieren nun.
Lag an einer NAT Einstellung an der Sense.
Nur klappt das Internet bzw. DNS Resolve noch nich ganz.
Hab auf Server-Seite push redirect-gateway def 1 drin und auch den Google DNS dort angegeben.
Muss da noch was an der pfSense gemacht werden?
UPDATE:
Jetzt wirds total strange, ich kann Google via Browser nutzen. Gibt auch die Suchergebnisse an. Aber wenn ich auf eine Website will, kommt ein DNS Timeout.
Hab die MTU mal auf 1300 gesetzt. Weil ich dachte, vielleicht sind die Pakete zu groß. Aber hat nichts geändert.
UPDATE: Kann dicht gemacht werden. Läuft nun alles.
Bin gerade an einem Guide für diesen Infra-Case. Sobald er fertig ist, pack ich ein Link hier rein.
Hab festgestellt, viele Tutorials/Guides sind sehr schwammig erklärt und irgendwo kommt man dann am eigenen Case nicht mehr weiter.
Bin gerade an einem Guide für diesen Infra-Case. Sobald er fertig ist, pack ich ein Link hier rein.
Hab festgestellt, viele Tutorials/Guides sind sehr schwammig erklärt und irgendwo kommt man dann am eigenen Case nicht mehr weiter.
Cool das nun alles klappt und ein Tutorial ist immer hilfreich. Dann sind wir mal gespannt auf den Link
