12
PfSense als OpenVPN-Client einrichten bzw. Ports 80 und 443 umleiten
Hallo,
ich habe hier auf unserem Server pfSense als OpenVPN-Client einrichten und habe es mit einem OpenVPN-Server verbiunden.
Laut pfsense-Status funktioniert die Verbindung unn der Dienst läuft.
Ich habe zwar die OpenVPN-Anleitungen durchgelesen es ist mir aber doch nicht klar, wie ich die NAT-Regel festlege, wenn dieselbe pfsense-Installation sowohl als OpenVPN--Server und auch OpenVPN-Client funktioniert.
Meine Frage wäre, wie ich die Ports 80/443 Richtung neues OVPN-Netzes umleite. Woher weiss pfSense, dass Internetseiten nicht durch den eigenen, lokalen ISP sondern durch das OpenVPN-Server ausgeleitet werden müssen?
Ich stehe irgendwie auf der Leitung.
Das Problem ist folgendes: Wenn ich versuche mit einem NAT-Regel umzuleiten dann bräuchte ich natürlich die virtuelle LAN-IP des Servers, die ich nirgendswo finde. Die ist bei einer "down" Verbindung wohl gar nicht existiert. Wie lege ich also menuell fest, welche IP-Segment das neue virtuelle Netz in meinem System haben wird. Irgendwie muss ich ja festlegen in welches Netz die Pakete umgeleitet werden müssen ...
Danke für die Hilfe.
Gr. I.
ich habe hier auf unserem Server pfSense als OpenVPN-Client einrichten und habe es mit einem OpenVPN-Server verbiunden.
Laut pfsense-Status funktioniert die Verbindung unn der Dienst läuft.
Ich habe zwar die OpenVPN-Anleitungen durchgelesen es ist mir aber doch nicht klar, wie ich die NAT-Regel festlege, wenn dieselbe pfsense-Installation sowohl als OpenVPN--Server und auch OpenVPN-Client funktioniert.
Meine Frage wäre, wie ich die Ports 80/443 Richtung neues OVPN-Netzes umleite. Woher weiss pfSense, dass Internetseiten nicht durch den eigenen, lokalen ISP sondern durch das OpenVPN-Server ausgeleitet werden müssen?
Ich stehe irgendwie auf der Leitung.
Das Problem ist folgendes: Wenn ich versuche mit einem NAT-Regel umzuleiten dann bräuchte ich natürlich die virtuelle LAN-IP des Servers, die ich nirgendswo finde. Die ist bei einer "down" Verbindung wohl gar nicht existiert. Wie lege ich also menuell fest, welche IP-Segment das neue virtuelle Netz in meinem System haben wird. Irgendwie muss ich ja festlegen in welches Netz die Pakete umgeleitet werden müssen ...
Danke für die Hilfe.
Gr. I.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 244853
Url: https://administrator.de/forum/pfsense-als-openvpn-client-einrichten-bzw-ports-80-und-443-umleiten-244853.html
Ausgedruckt am: 05.04.2025 um 18:04 Uhr
12 Kommentare
Neuester Kommentar
Ich hab nicht ganz verstanden, was Du machen willst.
Kannst Du das detaillierter beschreiben?
Kannst Du das detaillierter beschreiben?
Ich habe ein Netzwerk "A" mit einer pfSense-Install. Ich habe außerhalb des Netzes einen OpenVPN-Server (Netzwerk "B")
ich möchte, dass mein Netz mit diesem OVPN Server durch pfSense verbunden wird und der Traffic (http und https) aus dem Netz "A" auf diesen Server umgeleitet wird, damit der Traffic dort bei dieser Niederlassung das Firmennetz verlässt. Wir möchte also den Webtraffic der Büro auf diesen Server konzentrieren.
Mein technisches Problem ist, dass der Dienst läuft, die Authentifizierung soll also OK sein, trotzdem weiss ich nicht welche IP-Segment dieses neue Netz hat. Laut einer Anleitung, die ich für diesen Server bekam, musste ich solche Infos nicht manuell vergeben. Ich kenne lediglich die externe IP des Servers, worauf ich aber so - in pfSense - kein Datenverkehr umleiten kann.
Vorher hatte ich etwas unklar geschrieben.
Gr. I.
ich möchte, dass mein Netz mit diesem OVPN Server durch pfSense verbunden wird und der Traffic (http und https) aus dem Netz "A" auf diesen Server umgeleitet wird, damit der Traffic dort bei dieser Niederlassung das Firmennetz verlässt. Wir möchte also den Webtraffic der Büro auf diesen Server konzentrieren.
Mein technisches Problem ist, dass der Dienst läuft, die Authentifizierung soll also OK sein, trotzdem weiss ich nicht welche IP-Segment dieses neue Netz hat. Laut einer Anleitung, die ich für diesen Server bekam, musste ich solche Infos nicht manuell vergeben. Ich kenne lediglich die externe IP des Servers, worauf ich aber so - in pfSense - kein Datenverkehr umleiten kann.
Vorher hatte ich etwas unklar geschrieben.
Gr. I.
Erstmal musst du keinerlei NAT machen bei einem VPN !! Ist ja auch logisch, denn warum willst du bei deinen eigenen IP Netzen irgendwelche IP Adressen umsetzen. Das ist in einem VPN Blödsinn und macht man bei einer Standard Installation nicht.
Vergiss also den Unsinn mit NAT.
Das Ziel der Port 80 oder 443 Pakete findet der VPN Router immer anhand der Destination IP Adresse. Die gibt doch das Zielnetz vor bzw. wo sich der Webhost befindet. Anhand seiner internen Routing Tabelle (und da kennt pfSense alle IP Netze !) fällt dann aufgrund der Ziel IP Adresse die Entscheidung auf welchem Port die pfSense dieses Paket raussendet !
Das sind nun aber wirklich allereinfachste Grundlagen der TCP/IP Kommunikation die man in der Grundschule lernt...oder war die Frage jetzt falsch verstanden ?!
Kollege beider... hat aber auch Recht deine Fragestellung ist genrell ziemlich kryptisch und wirr. Was soll z.B. eine "virtuelle LAN-IP des Servers" sein ???
Down bedeutet ja das ein Interface nicht aktiv ist und logischerweise auch kein Traffic darüber fliesst !
Also lesen:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
und
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Da steht alles was man wissen muss....oder du präzisierst deine Fragestellung hier etwas.
Mit dem Kauderwelsch von oben was du eigentlich willst ist schwer was anzufangen...sorry ?!
Vergiss also den Unsinn mit NAT.
Das Ziel der Port 80 oder 443 Pakete findet der VPN Router immer anhand der Destination IP Adresse. Die gibt doch das Zielnetz vor bzw. wo sich der Webhost befindet. Anhand seiner internen Routing Tabelle (und da kennt pfSense alle IP Netze !) fällt dann aufgrund der Ziel IP Adresse die Entscheidung auf welchem Port die pfSense dieses Paket raussendet !
Das sind nun aber wirklich allereinfachste Grundlagen der TCP/IP Kommunikation die man in der Grundschule lernt...oder war die Frage jetzt falsch verstanden ?!
Kollege beider... hat aber auch Recht deine Fragestellung ist genrell ziemlich kryptisch und wirr. Was soll z.B. eine "virtuelle LAN-IP des Servers" sein ???
Down bedeutet ja das ein Interface nicht aktiv ist und logischerweise auch kein Traffic darüber fliesst !
Wie lege ich also menuell fest, welche IP-Segment das neue virtuelle Netz in meinem System haben wird
Das machst du im Hypervisor als dem ESXi oder HyperV oder was immer du da nutzt. DA bestimmst du selber die IP Adressierung und auch das Routing wie dann final auch in der pfSense, denn die muss ja wissen WO sie WAS hinschicken soll.Also lesen:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
und
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Da steht alles was man wissen muss....oder du präzisierst deine Fragestellung hier etwas.
Mit dem Kauderwelsch von oben was du eigentlich willst ist schwer was anzufangen...sorry ?!
Danke Aqui,
hier sind meine "präzisierte" Fragen:
1. hier in diesem Fall würde pfSense ein Teil meines LAN-Traffics durch das OpenVPN Netz zum fremden OpenVPN Server leiten. Wir bringe ich pfSense bei, dass es die Anfrage nach "google.de" nicht durch mein lokales WAN sondern durch VPN heraussende? Normalerweise wird all das durchs WAN Interface geroutet, was wir jetzt nicht wollen.
2. Ich finde in den Logs kein Hinweis dafür, ob die Verbindung zu dem externen OpenVPN-Server jetzt tatsächlich in Ordnung ist. (Mein pfSense ist ja in diesem Fall der OpenVPN Client) Steht bei der neuen Verbindung einfach "openvpn service is running". Wenn dieser Hinweis kommt kann man dafür ausgehen, dass die ganze Authentifizierung klappte und die "Leitung" da ist?
3. Wie kann ich am einfachsten testen, ob die Verbindung funktioniert? In den sonstigen Fällen wo meine lokale pfSense als OpenVPN-Server funktioniert haben wir Rules dafür im Firewall eingerichtet, weil alles blockiert war. In diesem Fall wird aber wohl alles aus dem LAN durchs "OpenVPN-Leitung" zu dem Server durchgelassen?
Verstehe ich es richtig?
Gr. I.
hier sind meine "präzisierte" Fragen:
1. hier in diesem Fall würde pfSense ein Teil meines LAN-Traffics durch das OpenVPN Netz zum fremden OpenVPN Server leiten. Wir bringe ich pfSense bei, dass es die Anfrage nach "google.de" nicht durch mein lokales WAN sondern durch VPN heraussende? Normalerweise wird all das durchs WAN Interface geroutet, was wir jetzt nicht wollen.
2. Ich finde in den Logs kein Hinweis dafür, ob die Verbindung zu dem externen OpenVPN-Server jetzt tatsächlich in Ordnung ist. (Mein pfSense ist ja in diesem Fall der OpenVPN Client) Steht bei der neuen Verbindung einfach "openvpn service is running". Wenn dieser Hinweis kommt kann man dafür ausgehen, dass die ganze Authentifizierung klappte und die "Leitung" da ist?
3. Wie kann ich am einfachsten testen, ob die Verbindung funktioniert? In den sonstigen Fällen wo meine lokale pfSense als OpenVPN-Server funktioniert haben wir Rules dafür im Firewall eingerichtet, weil alles blockiert war. In diesem Fall wird aber wohl alles aus dem LAN durchs "OpenVPN-Leitung" zu dem Server durchgelassen?
Verstehe ich es richtig?
Gr. I.
Ad 1.)
OK, das ist ja normal auch der tiefere Sinn und Zweck eines VLANs, das Traffic der zu IP Zielnetzen innerhalb dieses VPNs durch den VPN Tunnel gehen. Der VPN Tunnel ja quasi wie eine separate Standleitung zum remoten Netz oder Host zu sehen !
Um die Frage zu google.de zu benatworten geht der Router/Firewall immer nach der IP Adresse.
In deinem Falle 173.194.39.23.
Normal wird bei OpenVPN alles was interne eigene VPN IP Adressen sind in den Tunnel geroutet. Folglich würde also die 173.194.39.23 von google.de normal an den WAN Provider Port ins Internet gesendet, denn es ist ja eine öffenltiche IP.
Das kannst du mit 2 Optionen ändern:
a.) du sagst OpenVPN das dein Default Gateway das Tunnel Interface ist. Dann wird OpenVPN aber ALLES in den Tunnel routen und nichts mehr lokal. Das wäre die Lösung wenn ich generell eine andere Absender IP im Internet haben möchte um z.B. meinen Traffic zu verschleiern.
Versteht man dich richtig, willst du das aber nicht sondern nur bestimmte Ziele in den Tunnel routen. Dann greift Möglichkeit...
b.) Das sog. Policy Based Routing. Du legst auf der Firewall/Router eine statische Route an wo du z.B. entweder den Host oder das ganze Netz an das Tunnel Interface sendest. Klar, das muss auch so sein, denn sonst würde die Firewall/Router immerstrikt nach seiner internen Routing Tabelle gehen und das Provider Default Gateway nutzen.
Sagst du ihm aber nun er soll mit einer statischen Route 173.194.39.23 /32 in den VPN Tunnel routen, dann macht OVPN das auch brav.
Logischerweise musst du aber auch sicherstellen das am Tunnel Endpunkt dieses Paket weiter ins Internet geroutet werden kann.
Traceroute oder Pathping zeigen dir dann immer die Wege Hop für Hop an so das du den Weg eines Pakets ganz genau verfolgen kannst !
pfSense upported sowohl die Option a. als auch PBR mit Option b. !
Ad 2.)
Normalerweise sieht man das eindeutig wenn du dir die Logs ansiehst. Zudem kannst du über die Console immer einen Shell Zugang aufmachen und dir über den Kommando Prompt den OVPN Status ganz genau ansehen !
Das OpenVPN_Tutorial beschreibt das im Kapitel "Ist der OVPN Server aktiv" explizit wie das zu machen ist ! Unter /var/log/messages kannst du dir auch die entsprechenden Logs genau ansehen.
Ad 3.)
Am einfachsten testest du das mit einem simplen Ping auf die Engeräte IP Adresse !! Bei der Firewall musst du natürlich aufpassen das die Rules auf dem virtuellen VPN Interface entsprechend eingestellt sind !!
Generell, und das weisst du selber, ist bei einer Firewall per default alles verboten !!
Das Ruleset musst du also in jedem Falle anpassen auch wenn du erstmal zum Testen eine Schrotschuss Regel aufsetzt die alles erlaubt !
Bedneke immer das die Regeln nur inbound gelten und das die Grundregel "First match wins !" gilt. Will sagen du kannst nicht oben was verbieten was du untern wieder erlaubst.
Reihenfolge zählt hier also !!!
Als alter pfSense Hase weisst du das ja aber selber ?!
OK, das ist ja normal auch der tiefere Sinn und Zweck eines VLANs, das Traffic der zu IP Zielnetzen innerhalb dieses VPNs durch den VPN Tunnel gehen. Der VPN Tunnel ja quasi wie eine separate Standleitung zum remoten Netz oder Host zu sehen !
Um die Frage zu google.de zu benatworten geht der Router/Firewall immer nach der IP Adresse.
In deinem Falle 173.194.39.23.
Normal wird bei OpenVPN alles was interne eigene VPN IP Adressen sind in den Tunnel geroutet. Folglich würde also die 173.194.39.23 von google.de normal an den WAN Provider Port ins Internet gesendet, denn es ist ja eine öffenltiche IP.
Das kannst du mit 2 Optionen ändern:
a.) du sagst OpenVPN das dein Default Gateway das Tunnel Interface ist. Dann wird OpenVPN aber ALLES in den Tunnel routen und nichts mehr lokal. Das wäre die Lösung wenn ich generell eine andere Absender IP im Internet haben möchte um z.B. meinen Traffic zu verschleiern.
Versteht man dich richtig, willst du das aber nicht sondern nur bestimmte Ziele in den Tunnel routen. Dann greift Möglichkeit...
b.) Das sog. Policy Based Routing. Du legst auf der Firewall/Router eine statische Route an wo du z.B. entweder den Host oder das ganze Netz an das Tunnel Interface sendest. Klar, das muss auch so sein, denn sonst würde die Firewall/Router immerstrikt nach seiner internen Routing Tabelle gehen und das Provider Default Gateway nutzen.
Sagst du ihm aber nun er soll mit einer statischen Route 173.194.39.23 /32 in den VPN Tunnel routen, dann macht OVPN das auch brav.
Logischerweise musst du aber auch sicherstellen das am Tunnel Endpunkt dieses Paket weiter ins Internet geroutet werden kann.
Traceroute oder Pathping zeigen dir dann immer die Wege Hop für Hop an so das du den Weg eines Pakets ganz genau verfolgen kannst !
pfSense upported sowohl die Option a. als auch PBR mit Option b. !
Ad 2.)
Normalerweise sieht man das eindeutig wenn du dir die Logs ansiehst. Zudem kannst du über die Console immer einen Shell Zugang aufmachen und dir über den Kommando Prompt den OVPN Status ganz genau ansehen !
Das OpenVPN_Tutorial beschreibt das im Kapitel "Ist der OVPN Server aktiv" explizit wie das zu machen ist ! Unter /var/log/messages kannst du dir auch die entsprechenden Logs genau ansehen.
Ad 3.)
Am einfachsten testest du das mit einem simplen Ping auf die Engeräte IP Adresse !! Bei der Firewall musst du natürlich aufpassen das die Rules auf dem virtuellen VPN Interface entsprechend eingestellt sind !!
Generell, und das weisst du selber, ist bei einer Firewall per default alles verboten !!
Das Ruleset musst du also in jedem Falle anpassen auch wenn du erstmal zum Testen eine Schrotschuss Regel aufsetzt die alles erlaubt !
Bedneke immer das die Regeln nur inbound gelten und das die Grundregel "First match wins !" gilt. Will sagen du kannst nicht oben was verbieten was du untern wieder erlaubst.
Reihenfolge zählt hier also !!!
Als alter pfSense Hase weisst du das ja aber selber ?!
Danke sehr Aqui, informative wie immer 
Gr. I.
Gr. I.
Hallo Aqui.
Ich habe jetzt erfolgreich ein OpenVPN gateway eingerichtet, der via DHCP die IPs vom externen OpenVPN-Server bekommen sollte. Obwohl die pfSense Dashboard die Verbindung als "up" bezeichnet kommt keine IP sondern einfach nur 0.0.0.0 wird angezeigt.
Woran kann es liegen? Ich vermute mal, dass kein Certifikate-Problem der Grund ist sonst wäre die Verbindung selbst nicht möglich.
Bei den Client-Einstellungen habe ich schon TUN / TAP probiert. Kann es sein, dass DHCP in diesem Fall gar nich so sinnvoll ist. Eventuell etwas festlegen?
Ich habe sicherheitshalber bei WAN alles von und zu neues OVPN Netzes freigegeben. Daran dürfte es also nicht liegen.
Gr. I.
Ich habe jetzt erfolgreich ein OpenVPN gateway eingerichtet, der via DHCP die IPs vom externen OpenVPN-Server bekommen sollte. Obwohl die pfSense Dashboard die Verbindung als "up" bezeichnet kommt keine IP sondern einfach nur 0.0.0.0 wird angezeigt.
Woran kann es liegen? Ich vermute mal, dass kein Certifikate-Problem der Grund ist sonst wäre die Verbindung selbst nicht möglich.
Bei den Client-Einstellungen habe ich schon TUN / TAP probiert. Kann es sein, dass DHCP in diesem Fall gar nich so sinnvoll ist. Eventuell etwas festlegen?
Ich habe sicherheitshalber bei WAN alles von und zu neues OVPN Netzes freigegeben. Daran dürfte es also nicht liegen.
Gr. I.
Was sagt denn die Routing Tabelle in der pfSense ?? (Unter Diagnostics)
Kannst du dort denn alle remoten Netze sehen oder ist das Default Gateway auf den Tunneladapter dort gesetzt ?
Relevant ist ob generell Traffic durch den Tunnel geht ? Hast du das getestet ?
Wenn das der Fall ist dann ist die Einwahl wirklich erforlgreich. 0.0.0.0 darf da eigentlich nicht stehen !
Jeder eingewählte Client bekommt immer eine IP Adresse des internen OVPN IP Netzes das mit
server 172.16.2.0 255.255.255.0
auf der Serverseite in dessen Konfig Date definiert ist !
Kannst du dort denn alle remoten Netze sehen oder ist das Default Gateway auf den Tunneladapter dort gesetzt ?
Relevant ist ob generell Traffic durch den Tunnel geht ? Hast du das getestet ?
Wenn das der Fall ist dann ist die Einwahl wirklich erforlgreich. 0.0.0.0 darf da eigentlich nicht stehen !
Jeder eingewählte Client bekommt immer eine IP Adresse des internen OVPN IP Netzes das mit
server 172.16.2.0 255.255.255.0
auf der Serverseite in dessen Konfig Date definiert ist !
So sieht es aus... 
Interfaces:
255.255.255.255 steht bei VPN.
Den Server stellt ein Patnerfirma zur Verfügung ich habe keine Einfluss auf die serverseitige Config. Ich habe es laut der Anleitung ihres Administrators gemacht.
Eine Frage: als ich den CA.cert importiert habe, habe ich zu dem privaten Key nichts reinkopiert, es ist ja als optional angegeben. Ich konnte dann keinen internen Cert erstellen, weil/denn ein Fehler kam.
Können die Probleme eventuell damit zusammenhängen? Da die Verbindung scheinbar klappte habe ich mich dann nicht wirklich darum gekümmert.
Interfaces:
255.255.255.255 steht bei VPN.
Den Server stellt ein Patnerfirma zur Verfügung ich habe keine Einfluss auf die serverseitige Config. Ich habe es laut der Anleitung ihres Administrators gemacht.
Eine Frage: als ich den CA.cert importiert habe, habe ich zu dem privaten Key nichts reinkopiert, es ist ja als optional angegeben. Ich konnte dann keinen internen Cert erstellen, weil/denn ein Fehler kam.
Können die Probleme eventuell damit zusammenhängen? Da die Verbindung scheinbar klappte habe ich mich dann nicht wirklich darum gekümmert.
Was hat der externe Administrator denn gesagt was er für interne OVPN IP Adressen fährt. Ser OVPN Server hat immer die erste Adresse und die muss in jedem Falle anpingbar sein.
Kannst du diese Pingen ??
Wenn nicht hast du auch keine aktive OVPN Verbindung.
Gehe doch mal bei deiner pfSense in die Shell über die serielle Schnittstelle oder SSH und sieh dir unter /var/log/messages mal das OpenVPN Log an ??
Was steht da wenn der Client die Verbindung eröffnent ?
Auch auf der grafischen Oberfläche hast du ja unter Status - System Logs ein OpenVPN Log ! Was steht da drin wenn der Client die Verbindung öffnet ?
Kannst du diese Pingen ??
Wenn nicht hast du auch keine aktive OVPN Verbindung.
Gehe doch mal bei deiner pfSense in die Shell über die serielle Schnittstelle oder SSH und sieh dir unter /var/log/messages mal das OpenVPN Log an ??
Was steht da wenn der Client die Verbindung eröffnent ?
Auch auf der grafischen Oberfläche hast du ja unter Status - System Logs ein OpenVPN Log ! Was steht da drin wenn der Client die Verbindung öffnet ?
Danke.
Hier ist das Log:
Hier wird es bemängelt, dass klein Auth stattfindet. Der Admin hat mir allerdings extra geschrieben, dass ich es deaktivieren soll bei den Client-Einstellungen ... Blöd.
Jul 31 16:19:33 openvpn[85151]: TLS Error: incoming packet authentication failed from [AF_INET][EIGENERVPNSERVER]:42351
Jul 31 16:19:33 openvpn[85151]: Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 31 16:19:29 openvpn[85151]: TLS Error: incoming packet authentication failed from [AF_INET][EIGENERVPNSERVER]:42351
Jul 31 16:19:29 openvpn[85151]: Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 31 16:19:27 openvpn[85151]: TLS Error: incoming packet authentication failed from [AF_INET][EIGENERVPNSERVER]:42351
Jul 31 16:19:27 openvpn[85151]: Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 31 16:19:27 openvpn[85721]: UDPv4 link remote: [AF_INET][EIGENERVPNSERVER]:1194
Jul 31 16:19:27 openvpn[85721]: UDPv4 link local (bound): [AF_INET][EIGENERVPNSERVER]
Jul 31 16:19:27 openvpn[85721]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 31 16:19:27 openvpn[85721]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jul 31 16:19:25 openvpn[85721]: SIGUSR1[soft,ping-restart] received, process restarting
Jul 31 16:19:25 openvpn[85721]: [UNDEF] Inactivity timeout (--ping-restart), restarting
Jul 31 16:19:24 openvpn[86700]: UDPv4 link remote: [AF_INET][FREMDERVPNSERVER]:53
Jul 31 16:19:24 openvpn[86700]: UDPv4 link local (bound): [AF_INET][EIGENERVPNSERVER]
Jul 31 16:19:24 openvpn[86699]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 31 16:19:24 openvpn[86699]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jul 31 16:19:24 openvpn[86699]: WARNING: file '/tmp/openvpn-password.txt' is group or others accessible
Jul 31 16:19:24 openvpn[86699]: OpenVPN 2.3.2 i386-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on Mar 27 2014
Jul 31 16:19:23 openvpn[88318]: SIGTERM[hard,] received, process exiting
Jul 31 16:19:23 openvpn[88318]: event_wait : Interrupted system call (code=4)
Jul 31 16:19:17 openvpn[88318]: UDPv4 link remote: [AF_INET][FREMDERVPNSERVER]:53
Jul 31 16:19:17 openvpn[88318]: UDPv4 link local (bound): [AF_INET][EIGENERVPNSERVER]
Jul 31 16:19:17 openvpn[88318]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 31 16:19:17 openvpn[88318]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jul 31 16:19:16 openvpn[76236]: UDPv4 link remote: [AF_INET][FREMDERVPNSERVER]:53
Jul 31 16:19:16 openvpn[76236]: UDPv4 link local (bound): [AF_INET][EIGENERVPNSERVER]
Jul 31 16:19:16 openvpn[76164]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 31 16:19:16 openvpn[76164]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jul 31 16:19:16 openvpn[76164]: WARNING: file '/tmp/openvpn-password.txt' is group or others accessible
Jul 31 16:19:16 openvpn[76164]: OpenVPN 2.3.2 i386-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on Mar 27 2014
Jul 31 16:19:15 openvpn[84125]: SIGTERM[hard,] received, process exiting
Jul 31 16:19:15 openvpn[84125]: event_wait : Interrupted system call (code=4)
Jul 31 16:19:15 openvpn[88318]: SIGUSR1[soft,ping-restart] received, process restarting
Jul 31 16:19:15 openvpn[88318]: [UNDEF] Inactivity timeout (--ping-restart), restarting
Jul 31 16:19:13 openvpn[66810]: UDPv4 link remote: [AF_INET][FREMDERVPNSERVER]:53
Jul 31 16:19:13 openvpn[66810]: UDPv4 link local (bound): [AF_INET][EIGENERVPNSERVER]
Jul 31 16:19:13 openvpn[65681]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 31 16:19:13 openvpn[65681]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jul 31 16:19:13 openvpn[65681]: WARNING: file '/tmp/openvpn-password.txt' is group or others accessible
Jul 31 16:19:13 openvpn[65681]: OpenVPN 2.3.2 i386-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on Mar 27 2014
Jul 31 16:19:12 openvpn[61138]: SIGTERM[hard,] received, process exiting
Jul 31 16:19:12 openvpn[61138]: event_wait : Interrupted system call (code=4)
Jul 31 16:19:12 openvpn[84125]: UDPv4 link remote: [AF_INET][FREMDERVPNSERVER]:53
Jul 31 16:19:12 openvpn[84125]: UDPv4 link local (bound): [AF_INET][EIGENERVPNSERVER]
Jul 31 16:19:12 openvpn[84125]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 31 16:19:12 openvpn[84125]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jul 31 16:19:10 openvpn[84125]: SIGUSR1[soft,ping-restart] received, process restarting
Jul 31 16:19:10 openvpn[84125]: [UNDEF] Inactivity timeout (--ping-restart), restarting
Jul 31 16:19:06 openvpn[61138]: UDPv4 link remote: [AF_INET][FREMDERVPNSERVER]:53
Jul 31 16:19:06 openvpn[61138]: UDPv4 link local (bound): [AF_INET][EIGENERVPNSERVER]
Hier ist das Log:
Hier wird es bemängelt, dass klein Auth stattfindet. Der Admin hat mir allerdings extra geschrieben, dass ich es deaktivieren soll bei den Client-Einstellungen ... Blöd.
Jul 31 16:19:33 openvpn[85151]: TLS Error: incoming packet authentication failed from [AF_INET][EIGENERVPNSERVER]:42351
Jul 31 16:19:33 openvpn[85151]: Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 31 16:19:29 openvpn[85151]: TLS Error: incoming packet authentication failed from [AF_INET][EIGENERVPNSERVER]:42351
Jul 31 16:19:29 openvpn[85151]: Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 31 16:19:27 openvpn[85151]: TLS Error: incoming packet authentication failed from [AF_INET][EIGENERVPNSERVER]:42351
Jul 31 16:19:27 openvpn[85151]: Authenticate/Decrypt packet error: packet HMAC authentication failed
Jul 31 16:19:27 openvpn[85721]: UDPv4 link remote: [AF_INET][EIGENERVPNSERVER]:1194
Jul 31 16:19:27 openvpn[85721]: UDPv4 link local (bound): [AF_INET][EIGENERVPNSERVER]
Jul 31 16:19:27 openvpn[85721]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 31 16:19:27 openvpn[85721]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jul 31 16:19:25 openvpn[85721]: SIGUSR1[soft,ping-restart] received, process restarting
Jul 31 16:19:25 openvpn[85721]: [UNDEF] Inactivity timeout (--ping-restart), restarting
Jul 31 16:19:24 openvpn[86700]: UDPv4 link remote: [AF_INET][FREMDERVPNSERVER]:53
Jul 31 16:19:24 openvpn[86700]: UDPv4 link local (bound): [AF_INET][EIGENERVPNSERVER]
Jul 31 16:19:24 openvpn[86699]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 31 16:19:24 openvpn[86699]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jul 31 16:19:24 openvpn[86699]: WARNING: file '/tmp/openvpn-password.txt' is group or others accessible
Jul 31 16:19:24 openvpn[86699]: OpenVPN 2.3.2 i386-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on Mar 27 2014
Jul 31 16:19:23 openvpn[88318]: SIGTERM[hard,] received, process exiting
Jul 31 16:19:23 openvpn[88318]: event_wait : Interrupted system call (code=4)
Jul 31 16:19:17 openvpn[88318]: UDPv4 link remote: [AF_INET][FREMDERVPNSERVER]:53
Jul 31 16:19:17 openvpn[88318]: UDPv4 link local (bound): [AF_INET][EIGENERVPNSERVER]
Jul 31 16:19:17 openvpn[88318]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 31 16:19:17 openvpn[88318]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jul 31 16:19:16 openvpn[76236]: UDPv4 link remote: [AF_INET][FREMDERVPNSERVER]:53
Jul 31 16:19:16 openvpn[76236]: UDPv4 link local (bound): [AF_INET][EIGENERVPNSERVER]
Jul 31 16:19:16 openvpn[76164]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 31 16:19:16 openvpn[76164]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jul 31 16:19:16 openvpn[76164]: WARNING: file '/tmp/openvpn-password.txt' is group or others accessible
Jul 31 16:19:16 openvpn[76164]: OpenVPN 2.3.2 i386-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on Mar 27 2014
Jul 31 16:19:15 openvpn[84125]: SIGTERM[hard,] received, process exiting
Jul 31 16:19:15 openvpn[84125]: event_wait : Interrupted system call (code=4)
Jul 31 16:19:15 openvpn[88318]: SIGUSR1[soft,ping-restart] received, process restarting
Jul 31 16:19:15 openvpn[88318]: [UNDEF] Inactivity timeout (--ping-restart), restarting
Jul 31 16:19:13 openvpn[66810]: UDPv4 link remote: [AF_INET][FREMDERVPNSERVER]:53
Jul 31 16:19:13 openvpn[66810]: UDPv4 link local (bound): [AF_INET][EIGENERVPNSERVER]
Jul 31 16:19:13 openvpn[65681]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 31 16:19:13 openvpn[65681]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jul 31 16:19:13 openvpn[65681]: WARNING: file '/tmp/openvpn-password.txt' is group or others accessible
Jul 31 16:19:13 openvpn[65681]: OpenVPN 2.3.2 i386-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on Mar 27 2014
Jul 31 16:19:12 openvpn[61138]: SIGTERM[hard,] received, process exiting
Jul 31 16:19:12 openvpn[61138]: event_wait : Interrupted system call (code=4)
Jul 31 16:19:12 openvpn[84125]: UDPv4 link remote: [AF_INET][FREMDERVPNSERVER]:53
Jul 31 16:19:12 openvpn[84125]: UDPv4 link local (bound): [AF_INET][EIGENERVPNSERVER]
Jul 31 16:19:12 openvpn[84125]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 31 16:19:12 openvpn[84125]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Jul 31 16:19:10 openvpn[84125]: SIGUSR1[soft,ping-restart] received, process restarting
Jul 31 16:19:10 openvpn[84125]: [UNDEF] Inactivity timeout (--ping-restart), restarting
Jul 31 16:19:06 openvpn[61138]: UDPv4 link remote: [AF_INET][FREMDERVPNSERVER]:53
Jul 31 16:19:06 openvpn[61138]: UDPv4 link local (bound): [AF_INET][EIGENERVPNSERVER]
Die Probleme hingen damit zusammen, dass es zwei "etc" Verzeichnisse waren: ich habe nicht gesehen, dass es schon existiert und habe noch einmal manuell unter root erstellt. /root/etc ist nicht dasselbe wie /etc.
Dies habe ich erst mit winSCP entdeckt.
Die Verbindung funkzt:
Jul 31 21:10:00 openvpn[19720]: UDPv4 link remote: [AF_INET]192.186.132.XXX:53
Jul 31 21:10:00 openvpn[19720]: UDPv4 link local (bound): [AF_INET]217.8.62.XXX
Jul 31 21:10:00 openvpn[19720]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 31 21:10:00 openvpn[19720]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
192.186.132.XXX kann ich von der pfsense webGUI anpingen. Die Pakete gehen durch.
DHCP habe ich trotzdem nicht. Ich versuche mal die IP dem Interface manuell zuzuordnen.
Wenn ich das Interface einem Gateway zuordne passiert nichts. Wenn ich meine externe IP kontrolliere ist es die Normale.
Gr. I.
Dies habe ich erst mit winSCP entdeckt.
Die Verbindung funkzt:
Jul 31 21:10:00 openvpn[19720]: UDPv4 link remote: [AF_INET]192.186.132.XXX:53
Jul 31 21:10:00 openvpn[19720]: UDPv4 link local (bound): [AF_INET]217.8.62.XXX
Jul 31 21:10:00 openvpn[19720]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 31 21:10:00 openvpn[19720]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
192.186.132.XXX kann ich von der pfsense webGUI anpingen. Die Pakete gehen durch.
DHCP habe ich trotzdem nicht. Ich versuche mal die IP dem Interface manuell zuzuordnen.
Wenn ich das Interface einem Gateway zuordne passiert nichts. Wenn ich meine externe IP kontrolliere ist es die Normale.
Gr. I.
