Public IPv4/IPv6 via VPN Tunnel
-
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
oder ist es möglich, mehrere Hosts direkt zu routen?
Also VPS IP 212.224.xxx.yyy <---> 10.0.99.222 und 10.0.20.223?Ja, klar ist es möglich, ich habe ja geschrieben, ich würde die Weiterleitung direkt am VPS machen.
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Würde die VPS IPv4 dafür opfern, komme ja noch per ssh und IPv6 auf den VPS.
Muss wohl sein. Ist ja die einzige statische IPv4, die du dann hast.
Die VPN-Verbindung wäre dann nur noch ein Transitnetz für den Traffic von außen zum Home-LAN. Aber klar kannst du sie dennoch nutzen, um auf den VPS zuzugreifen.
Aktuell ist der VPN-Server dein Standardgateway. Das heißt, dass auch alle ausgehenden, vom Home-LAN initiierten, Verbindungen, die nicht explizit anders geroutet werden, über die VPN laufen und damit öffentliche Quell-IP des VPS bekommen. Mir ist noch nicht klar, ob das so gewünscht ist. Ich habe das ich schon mehrmals angesprochen, du bist aber darauf nicht eingegangen. Auch das ist Geschmackssache, ich sehe keine Notwendigkeit dafür, kenne aber die Hintergründe nicht.
Die Frage sollte aber beantwortet werden, weil sie für die Konfiguration entscheidend ist. Aus diesem Grund hatte ich es fast in jedem Post hier erwähnt...@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Mir würde ein Routing zur pfSense reichen, oder ist es möglich, mehrere Hosts direkt zu routen?
Eine alternative Herangehensweise, allerdings wieder mit Double-NAT, für Leute, die sich nicht allzu viel mit iptables herumschlagen möchten, wäre, sämtlichen eingehenden Traffic am VPS mit einer einzigen Regel (mit Port-Ausnahmen für SSH etc.) weiterzuleiten und dann die Regeln für die einzelnen internen Ziele auf der pfSense setzen.
Wieder: Geschmackssache. Du musst mal sagen, was du genau umsetzen möchtest.
Meine Meinung habe ich schon kundgetan. Ich würde alle Weiterleitungen direkt am VPS setzen und die VPN als Transitnetz für eingehende Verbindungen ins Home nutzen. Bin allerdings auch nicht sehr vertraut mit iptables. -
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Aktuell ist der VPN-Server dein Standardgateway. Das heißt, dass auch alle ausgehenden, vom Home-LAN initiierten, Verbindungen, die nicht explizit anders geroutet werden, über die VPN laufen und damit öffentliche Quell-IP des VPS bekommen. Mir ist noch nicht klar, ob das so gewünscht ist.
Stimmt, hab Dir damals kein Feedback gegeben, Asche auf mein Haupt.
Nein, ist nicht gewünscht und durch den Schalter "Don't pull routes" deaktiviert.@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Du musst mal sagen, was du genau umsetzen möchtest.
Ein Host und die Spielkonsolen wenn nötig sollen später mit einer public IP von draussen zu erreichen sein.
Spielekonsolen deshalb, weil einige Dienste per v6 nicht zur Verfügung stehen, das kann sich eventuell bald ändern. Aktuell ist ein bestimmter "NAT Type" für ein einwandfreies Onlinepielen notwendig resultierend durch eine Portweiterleitung bestimmter Ports. Oder durch eine direkte Verbindung zu einem Modem. Ist das durch Routing machbar?
Ein Host mit SSH Zugang, einfach als Failover, falls der Zugriff per v6 nicht funzt. Das ist mein Ziel.
Die Konsolen und der Host befinden sich in versch. Subnetzen.
Dieses Doppel NAT ist nicht ideal, das weiss ich auch. Deswegen würde ich eine komplette Weiterleitung auf dem VPS vorziehen. Nur wie mache ich das?
Hier erstmal die Routingtabelle vom VPS:
root@ionos:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.255.255.1 0.0.0.0 UG 0 0 0 ens192 10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 10.255.255.1 0.0.0.0 255.255.255.255 UH 0 0 0 ens192Hoffe, konnte bisschen Licht ins Dunkle bringen.
-
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Nein, ist nicht gewünscht und durch den Schalter "Don't pull routes" deaktiviert.
Die Idee ist aber nun neu. Die Konfig Files oben zeigen was anderes: Serverseitig "redirect gateway" und am Client nichts von route nopull.
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Oder durch eine direkte Verbindung zu einem Modem.
UPnP vermutlich.
Das wäre auch nur eine Weiterleitung, eine die sich eben das Endgerät (Konsole) selbst setzt.
Ist das durch Routing machbar?
Wenn es grundsätzlich über die VPN machbar ist, ja. UPnP wird am VPS nicht gehen.
Dieses Doppel NAT ist nicht ideal, das weiss ich auch. Deswegen würde ich eine komplette Weiterleitung auf dem VPS vorziehen.
Die Weiterleitung des ganzen Traffics am VPS auf die pfSense wäre auch NAT. Auf der pfSense ist dann eine weiteres NAT nötig, um auf die einzelnen Geräte zu kommen, also auch Doppel-NAT.
Wenn du kein Doppel-NAT haben möchtest, musst du die Regeln am VPS (mit iptables) setzen und als Targets eben die Ziel-IPs in deinem LAN angeben.Dieses "ens192" hatte ich für das WAN gehalten. Es hat aber eine private IP?
Wenn so, muss ja da auch schon mal NAT im Spiel sein. -
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Die Idee ist aber nun neu. Die Konfig Files oben zeigen was anderes: Serverseitig "redirect gateway" und am Client nichts von route nopull.
Eigentlich nicht. Die Konfigs sind älter, den Tipp gabst Du mir danach.
Hab den vserver zwischenzeitlich neu aufgesetzt, hier die aktuellen Konfigs:
Server:
local 212.227.xxx.yyy port 1195 proto udp dev tun user nobody group nogroup persist-key persist-tun keepalive 10 120 topology subnet server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "dhcp-option DNS 127.0.0.1" push "redirect-gateway def1 bypass-dhcp" server-ipv6 fd42:42:42:42::/112 tun-ipv6 push tun-ipv6 push "route-ipv6 2000::/3" push "redirect-gateway ipv6" dh none ecdh-curve prime256v1 tls-crypt tls-crypt.key crl-verify crl.pem ca ca.crt cert server_server.crt key server_server.key auth SHA256 cipher AES-128-GCM ncp-disable tls-server tls-version-min 1.2 tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 client-config-dir /etc/openvpn/ccd status /var/log/openvpn/status.log verb 3 compressClient:
dev ovpnc2 verb 1 dev-type tun dev-node /dev/tun2 writepid /var/run/openvpn_client2.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp4 cipher AES-128-GCM auth SHA256 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 87.168.xxx.yyy tls-client client lport 0 management /var/etc/openvpn/client2.sock unix remote 212.227.xxx.yyy 1195 udp4 ca /var/etc/openvpn/client2.ca cert /var/etc/openvpn/client2.cert key /var/etc/openvpn/client2.key tls-crypt /var/etc/openvpn/client2.tls-crypt ncp-disable compress resolv-retry infinite route-nopull@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Oder durch eine direkte Verbindung zu einem Modem.
UPnP vermutlich.
Über PPPOE
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Dieses "ens192" hatte ich für das WAN gehalten. Es hat aber eine private IP?
Wenn so, muss ja da auch schon mal NAT im Spiel sein.Der VPS hat nur ein Interface, die ens192 und bekommt die IPs per dhcp zugeteilt, und die ist nicht privat. 212.227. nochwas
Wie das der Anbieter macht, keine Ahnung. Zumindest habe ich in der virtuellen Konsole ein Proxmox Logo beim booten gesehen.
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Die Weiterleitung des ganzen Traffics am VPS auf die pfSense wäre auch NAT. Auf der pfSense ist dann eine weiteres NAT nötig, um auf die einzelnen Geräte zu kommen, also auch Doppel-NAT.
Wenn du kein Doppel-NAT haben möchtest, musst du die Regeln am VPS (mit iptables) setzen und als Targets eben die Ziel-IPs in deinem LAN angeben.Es gibt Unterschiede zwischen routen und weiterleiten?
Und wie soll das gehen? Nach meinem Verständnis brauch es noch ein Routing auf der Sense, oder? Wie soll das Paket wissen, was auf 10.8.0.2 reinschneit, das es zur IP 10.0.99.222 soll?
@viragomann
Wie würdest Du es wuppen? Damit ich irgendwie mal einen Anfang habe... -
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Die Idee ist aber nun neu. Die Konfig Files oben zeigen was anderes: Serverseitig "redirect gateway" und am Client nichts von route nopull.
Eigentlich nicht. Die Konfigs sind älter, den Tipp gabst Du mir danach.
Redirect gateway am Server kombiniert mit route-nopull am Client? Nein, solche Tipps gebe ich nicht. Ersteres pusht die Default-Route zum Client, letzteres weist denselben an, sie nicht zu setzen. Hmm, nein, von mir hast du das nicht. Nicht in dieser Kombination.
Aber egal, du magst die VPN nicht als Default-Gateway nutzen, habe ich nun mitbekommen.
Die VPN würde ich allerdings für diesen Zweck in ein /30er-Netz ändern. Ist ja ein Site-2-Site und kein Access-Server. Damit wären die Rollen klar definiert.Am VPN-Server musst du eine Route für dein internes Netz setzen:
route 10.0.99.0 255.255.255.0für das 10.0.99.0/24. Wenn du noch weitere Netze hast, die über die VPN sollen, dann sind noch weitere Zeilen nötig.
Wie erwähnt, iptables ist nicht meine größte Stärke, also im Zweifel hol dir anderswo diesbezüglichen Rat.
Die Masquerading Regel macht das, was auf pfSense Outbound NAT tut:# sense -> vserver iptables -t nat -I POSTROUTING 1 -s 10.8.0.0/24 -o ens192 -j MASQUERADEDie gilt aktuell nur für das VPN-Tunnelnetz. Dieses wird dann gar nicht mehr benötigt. Statt 10.8.0.0/24 kannst du also dein internes Netz reinschreiben. Deine pfSense Outbound NAT Regel lässt vermuten, dass das 10.0.99.0/24 ist.
Du hast aber von verschiedenen Netzen gesprochen. Wenn auch andere über den VPS geroutet werden, musst du die auch mit reinnehmen. Du kannst mehrere dieser Regeln setzen oder die Netzwerkmaske entsprechend erweitern.Die Outbound NAT Regel auf der pfSense wird dann nicht mehr benötigt.
Falls du ausgehende Verbindungen über die VPN routen möchtest (könnte bei Spielen erforderlich sein), musst du das per Policy Routing Regeln machen. Ich glaube aber gelesen zu haben, das hast du bereits gemacht.
Dann musst du noch die Weiterleitung anpassen:
#vserver -> sense iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 10.8.0.2:80Hier dann als Ziel deinen Webserver. Und dann noch weitere Regeln für die übrigen Dienste.
Und jetzt musst du dieses beachten:
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:Achte darauf, dass nur Regeln auf dem speziell hinzugefügten VPN-Interface auf die eingehenden Verbindungen zutreffen, also keine auf dem OpenVPN Tab und keine Floating!
Grund dafür ist, du hast nun mehre Interfaces, an welchen Pakete aus dem WWW ins System kommen, Multi-WAN also. pfSense stellt hier das richtige Zurückrouten der Antwortpakete durch das "Reply-to" Flag sicher, mit welchem es eingehende Verbindungen markiert. Voraussetzung dafür ist, dass am eingehenden Interface ein Gateway eingerichtet ist (geschieht bei OpenVPN durch automatische Konfiguration, das Zuweisen eines Interfaces zur Instanz macht es eindeutig) und dass die Regel, die diese Verbindung erlaubt, nicht am Floating-Tab oder auf einer Interface-Group definiert ist.
Anhand der Filter-Regel wird diese Markierung für das entsprechende Gateway als Reply-to-Ziel gesetzt.
Regeln auf Floating- oder Interface-Group-Tabs können für mehere Interfaces gelten, daher wäre bei diesen das Interface (eigentlich das Gateway), an das zurückgesendet werden soll, nicht eindeutig.
Der OpenVPN Tab ist eine Interface-Gruppe, die sämtliche laufende OpenVPN Instanzen enthält.Ich weiß nicht, ob das nun verständlich ist, aber besser schaff ich es nicht.
Ich denke, das war dann schon alles. Versuch es mal.
-
Sorry für die späte Antwort, war ein Stresstag heute...
Alles top erklärt, @viragomann , habe alles verstanden soweit.
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Redirect gateway am Server kombiniert mit route-nopull am Client? Nein, solche Tipps gebe ich nicht. Ersteres pusht die Default-Route zum Client, letzteres weist denselben an, sie nicht zu setzen. Hmm, nein, von mir hast du das nicht. Nicht in dieser Kombination.
Nein, nicht in dieser Kombination. Der Tip mit dem "Don't pull routes", das kam von Dir. Das "redirect gateway" war einfach mit rein kopiert von mir, wusste ehrlich gesagt bis jetzt noch nichts von dessen Funktion.
Habe jetzt
route 10.0.99.0 255.255.255.0in die server.conf eingetragen und in der pfSense das Outbound Mapping entfernt. die Routingtabelle sieht jetzt so aus:
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.255.255.1 0.0.0.0 UG 0 0 0 ens192 10.0.99.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0 10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 10.255.255.1 0.0.0.0 255.255.255.255 UH 0 0 0 ens192Die iptables NAT POST- und PREROUTE Einträge sind auf 10.0.99.0/24 bzw. 10.0.99.222 geändert.:
root@ionos:~# iptables -t nat -vnL Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:10.0.99.222:80 Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * ens192 10.0.99.0/24 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destinationEs gibt noch andere Einträge per Script, gehe von aus, die sind nötig:
# sense --> server iptables -t nat -I POSTROUTING 1 -s 10.0.99.0/24 -o ens192 -j MASQUERADE iptables -I INPUT 1 -i tun0 -j ACCEPT iptables -I FORWARD 1 -i ens192 -o tun0 -j ACCEPT iptables -I FORWARD 1 -i tun0 -o ens192 -j ACCEPT iptables -I INPUT 1 -i ens192 -p udp --dport 1195 -j ACCEPT # server --> sense iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 10.0.99.222:80Ist das soweit richtig? Die Sache ist, komme mit der VPS IP nicht auf die Testseite vom Host bzw der Host kommt nicht raus. Auch ein komplettes Reboot beider Parteien brachte nichts. An der Porfreigabe und dem VPN Rule ist nichts geändert, das testing Subnet hat ein "allow any to any" und als Gateway das von dem VPN ausgewählt.
Muss ich eventuell noch was an der Clienten Konfig ändern?
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Die VPN würde ich allerdings für diesen Zweck in ein /30er-Netz ändern. Ist ja ein Site-2-Site und kein Access-Server. Damit wären die Rollen klar definiert.
Das klappte nicht, /29 ja, bei /30 steikt openvpn. hier der Log, nur so als Info :):
Options error: --server directive when used with --dev tun must define a subnet of 255.255.255.248 (/29) or lower -
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
> # server --> sense > iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 10.0.99.222:80Ich würde hier zumindest auch noch das Interface des reinkommenden Traffics mit angeben. Also "-i ens192".
Zeige bitte mal die Firewall Regeln auf der pfSense, alle Tabs bitte.
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Das klappte nicht, /29 ja, bei /30 steikt openvpn.
Da hast du vermutlich eine Access-Server Konfiguration.
Nimm mal diese Zeilen raus:topology subnet ifconfig-pool-persist ipp.txt -
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
> # server --> sense > iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 10.0.99.222:80Ich würde hier zumindest auch noch das Interface des reinkommenden Traffics mit angeben. Also "-i ens192".
Zeige bitte mal die Firewall Regeln auf der pfSense, alle Tabs bitte.
Hier die Screenshots
Zur Info, habe den Test mit einer Konsole erweitert.
Portfreigabe:
VPN_WAN:
GAMING:
Test Subnet:
Und zu guter Letzt Outbound Mapping:
Hier noch die Server- und Clientconfig:
#Server: port 1195 #proto udp6 proto udp dev tun user nobody group nogroup persist-key persist-tun keepalive 10 120 topology subnet server 10.8.0.0 255.255.255.248 ifconfig-pool-persist ipp.txt #push "dhcp-option DNS 94.140.14.14" #push "dhcp-option DNS 94.140.15.15" #push "redirect-gateway def1 bypass-dhcp" #server-ipv6 fd42:42:42:42::/112 #tun-ipv6 #push tun-ipv6 #push "route-ipv6 2000::/3" #push "redirect-gateway ipv6" dh none ecdh-curve prime256v1 tls-crypt tls-crypt.key crl-verify crl.pem ca ca.crt cert server_2XW5mmuaPgD2ThUw.crt key server_2XW5mmuaPgD2ThUw.key auth SHA256 cipher AES-128-GCM ncp-disable tls-server tls-version-min 1.2 tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 #client-config-dir /etc/openvpn/ccd status /var/log/openvpn/status.log verb 4 compress ### own ### route 10.0.50.0 255.255.255.0 route 10.0.99.0 255.255.255.0 #push "dhcp-option DNS 127.0.0.1" # # # #Client: dev ovpnc2 verb 1 dev-type tun dev-node /dev/tun2 writepid /var/run/openvpn_client2.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp4 cipher AES-128-GCM auth SHA256 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 87.168.xxx.yyy tls-client client lport 0 management /var/etc/openvpn/client2.sock unix remote 212.227.xxx.yyy 1195 udp4 ca /var/etc/openvpn/client2.ca cert /var/etc/openvpn/client2.cert key /var/etc/openvpn/client2.key tls-crypt /var/etc/openvpn/client2.tls-crypt ncp-disable compress resolv-retry infinite route-nopull auth-nocacheUnd hier noch der Syslogeintrag vom Server restart inkl. Client Start:
Feb 23 18:35:49 ionos systemd[1]: Starting OpenVPN service... Feb 23 18:35:49 ionos ovpn-server[939]: event_wait : Interrupted system call (code=4) Feb 23 18:35:49 ionos ovpn-server[939]: TCP/UDP: Closing socket Feb 23 18:35:49 ionos ovpn-server[939]: /sbin/ip route del 10.0.50.0/24 Feb 23 18:35:49 ionos systemd[1]: Stopping OpenVPN connection to server... Feb 23 18:35:49 ionos openvpn[939]: RTNETLINK answers: Operation not permitted Feb 23 18:35:49 ionos ovpn-server[939]: ERROR: Linux route delete command failed: external program exited with error status: 2 Feb 23 18:35:49 ionos ovpn-server[939]: /sbin/ip route del 10.0.99.0/24 Feb 23 18:35:49 ionos systemd[1]: Started OpenVPN service. Feb 23 18:35:49 ionos openvpn[939]: RTNETLINK answers: Operation not permitted Feb 23 18:35:49 ionos ovpn-server[939]: ERROR: Linux route delete command failed: external program exited with error status: 2 Feb 23 18:35:49 ionos ovpn-server[939]: Closing TUN/TAP interface Feb 23 18:35:49 ionos ovpn-server[939]: /sbin/ip addr del dev tun0 10.8.0.1/29 Feb 23 18:35:49 ionos openvpn[939]: RTNETLINK answers: Operation not permitted Feb 23 18:35:49 ionos ovpn-server[939]: Linux ip addr del failed: external program exited with error status: 2 Feb 23 18:35:49 ionos ovpn-server[939]: SIGTERM[hard,] received, process exiting Feb 23 18:35:49 ionos systemd[1]: openvpn@server.service: Succeeded. Feb 23 18:35:49 ionos systemd[1]: Stopped OpenVPN connection to server. Feb 23 18:35:49 ionos systemd[1]: Starting OpenVPN connection to server... Feb 23 18:35:49 ionos ovpn-server[962]: Current Parameter Settings: Feb 23 18:35:49 ionos ovpn-server[962]: config = '/etc/openvpn/server.conf' Feb 23 18:35:49 ionos ovpn-server[962]: mode = 1 Feb 23 18:35:49 ionos ovpn-server[962]: persist_config = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: persist_mode = 1 Feb 23 18:35:49 ionos ovpn-server[962]: show_ciphers = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: show_digests = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: show_engines = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: genkey = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: key_pass_file = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: show_tls_ciphers = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: connect_retry_max = 0 Feb 23 18:35:49 ionos ovpn-server[962]: Connection profiles [0]: Feb 23 18:35:49 ionos ovpn-server[962]: proto = udp Feb 23 18:35:49 ionos ovpn-server[962]: local = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: local_port = '1195' Feb 23 18:35:49 ionos ovpn-server[962]: remote = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: remote_port = '1195' Feb 23 18:35:49 ionos ovpn-server[962]: remote_float = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: bind_defined = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: bind_local = ENABLED Feb 23 18:35:49 ionos ovpn-server[962]: bind_ipv6_only = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: connect_retry_seconds = 5 Feb 23 18:35:49 ionos ovpn-server[962]: connect_timeout = 120 Feb 23 18:35:49 ionos ovpn-server[962]: socks_proxy_server = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: socks_proxy_port = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: tun_mtu = 1500 Feb 23 18:35:49 ionos ovpn-server[962]: tun_mtu_defined = ENABLED Feb 23 18:35:49 ionos ovpn-server[962]: link_mtu = 1500 Feb 23 18:35:49 ionos ovpn-server[962]: link_mtu_defined = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: tun_mtu_extra = 0 Feb 23 18:35:49 ionos ovpn-server[962]: tun_mtu_extra_defined = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: mtu_discover_type = -1 Feb 23 18:35:49 ionos ovpn-server[962]: fragment = 0 Feb 23 18:35:49 ionos systemd[1]: Started OpenVPN connection to server. Feb 23 18:35:49 ionos ovpn-server[962]: mssfix = 1450 Feb 23 18:35:49 ionos ovpn-server[962]: explicit_exit_notification = 0 Feb 23 18:35:49 ionos ovpn-server[962]: Connection profiles END Feb 23 18:35:49 ionos ovpn-server[962]: remote_random = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: ipchange = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: dev = 'tun' Feb 23 18:35:49 ionos ovpn-server[962]: dev_type = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: dev_node = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: lladdr = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: topology = 3 Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_local = '10.8.0.1' Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_remote_netmask = '255.255.255.248' Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_noexec = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_nowarn = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_ipv6_local = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_ipv6_netbits = 0 Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_ipv6_remote = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: shaper = 0 Feb 23 18:35:49 ionos ovpn-server[962]: mtu_test = 0 Feb 23 18:35:49 ionos ovpn-server[962]: mlock = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: keepalive_ping = 10 Feb 23 18:35:49 ionos ovpn-server[962]: keepalive_timeout = 120 Feb 23 18:35:49 ionos ovpn-server[962]: inactivity_timeout = 0 Feb 23 18:35:49 ionos ovpn-server[962]: ping_send_timeout = 10 Feb 23 18:35:49 ionos ovpn-server[962]: ping_rec_timeout = 240 Feb 23 18:35:49 ionos ovpn-server[962]: ping_rec_timeout_action = 2 Feb 23 18:35:49 ionos ovpn-server[962]: ping_timer_remote = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: remap_sigusr1 = 0 Feb 23 18:35:49 ionos ovpn-server[962]: persist_tun = ENABLED Feb 23 18:35:49 ionos ovpn-server[962]: persist_local_ip = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: persist_remote_ip = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: persist_key = ENABLED Feb 23 18:35:49 ionos ovpn-server[962]: passtos = DISABLED Feb 23 18:35:49 ionos systemd-udevd[957]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Feb 23 18:35:49 ionos ovpn-server[962]: resolve_retry_seconds = 1000000000 Feb 23 18:35:49 ionos ovpn-server[962]: resolve_in_advance = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: username = 'nobody' Feb 23 18:35:49 ionos ovpn-server[962]: groupname = 'nogroup' Feb 23 18:35:49 ionos ovpn-server[962]: chroot_dir = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: cd_dir = '/etc/openvpn' Feb 23 18:35:49 ionos ovpn-server[962]: writepid = '/run/openvpn/server.pid' Feb 23 18:35:49 ionos ovpn-server[962]: up_script = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: down_script = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: down_pre = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: up_restart = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: up_delay = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: daemon = ENABLED Feb 23 18:35:49 ionos ovpn-server[962]: inetd = 0 Feb 23 18:35:49 ionos ovpn-server[962]: log = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: suppress_timestamps = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: machine_readable_output = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: nice = 0 Feb 23 18:35:49 ionos ovpn-server[962]: verbosity = 4 Feb 23 18:35:49 ionos ovpn-server[962]: mute = 0 Feb 23 18:35:49 ionos ovpn-server[962]: gremlin = 0 Feb 23 18:35:49 ionos ovpn-server[962]: status_file = '/var/log/openvpn/status.log' Feb 23 18:35:49 ionos ovpn-server[962]: status_file_version = 1 Feb 23 18:35:49 ionos ovpn-server[962]: status_file_update_freq = 10 Feb 23 18:35:49 ionos ovpn-server[962]: occ = ENABLED Feb 23 18:35:49 ionos ovpn-server[962]: rcvbuf = 0 Feb 23 18:35:49 ionos ovpn-server[962]: sndbuf = 0 Feb 23 18:35:49 ionos ovpn-server[962]: mark = 0 Feb 23 18:35:49 ionos ovpn-server[962]: sockflags = 0 Feb 23 18:35:49 ionos ovpn-server[962]: fast_io = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: comp.alg = 1 Feb 23 18:35:49 ionos ovpn-server[962]: comp.flags = 4 Feb 23 18:35:49 ionos ovpn-server[962]: route_script = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: route_default_gateway = '10.8.0.2' Feb 23 18:35:49 ionos ovpn-server[962]: route_default_metric = 0 Feb 23 18:35:49 ionos ovpn-server[962]: route_noexec = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: route_delay = 0 Feb 23 18:35:49 ionos ovpn-server[962]: route_delay_window = 30 Feb 23 18:35:49 ionos ovpn-server[962]: route_delay_defined = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: route_nopull = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: route_gateway_via_dhcp = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: allow_pull_fqdn = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: route 10.0.99.0/255.255.255.0/default (not set)/default (not set) Feb 23 18:35:49 ionos ovpn-server[962]: route 10.0.50.0/255.255.255.0/default (not set)/default (not set) Feb 23 18:35:49 ionos ovpn-server[962]: management_addr = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: management_port = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: management_user_pass = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: management_log_history_cache = 250 Feb 23 18:35:49 ionos ovpn-server[962]: management_echo_buffer_size = 100 Feb 23 18:35:49 ionos ovpn-server[962]: management_write_peer_info_file = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: management_client_user = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: management_client_group = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: management_flags = 0 Feb 23 18:35:49 ionos ovpn-server[962]: shared_secret_file = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: key_direction = not set Feb 23 18:35:49 ionos ovpn-server[962]: ciphername = 'AES-128-GCM' Feb 23 18:35:49 ionos ovpn-server[962]: ncp_enabled = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: ncp_ciphers = 'AES-256-GCM:AES-128-GCM' Feb 23 18:35:49 ionos ovpn-server[962]: authname = 'SHA256' Feb 23 18:35:49 ionos ovpn-server[962]: prng_hash = 'SHA1' Feb 23 18:35:49 ionos ovpn-server[962]: prng_nonce_secret_len = 16 Feb 23 18:35:49 ionos ovpn-server[962]: keysize = 0 Feb 23 18:35:49 ionos ovpn-server[962]: engine = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: replay = ENABLED Feb 23 18:35:49 ionos ovpn-server[962]: mute_replay_warnings = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: replay_window = 64 Feb 23 18:35:49 ionos ovpn-server[962]: replay_time = 15 Feb 23 18:35:49 ionos ovpn-server[962]: packet_id_file = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: use_iv = ENABLED Feb 23 18:35:49 ionos ovpn-server[962]: test_crypto = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: tls_server = ENABLED Feb 23 18:35:49 ionos ovpn-server[962]: tls_client = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: key_method = 2 Feb 23 18:35:49 ionos ovpn-server[962]: ca_file = 'ca.crt' Feb 23 18:35:49 ionos ovpn-server[962]: ca_path = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: dh_file = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: cert_file = 'server_2XW5mmuaPgD2ThUw.crt' Feb 23 18:35:49 ionos ovpn-server[962]: extra_certs_file = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: priv_key_file = 'server_2XW5mmuaPgD2ThUw.key' Feb 23 18:35:49 ionos ovpn-server[962]: pkcs12_file = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: cipher_list = 'TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256' Feb 23 18:35:49 ionos ovpn-server[962]: cipher_list_tls13 = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: tls_cert_profile = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: tls_verify = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: tls_export_cert = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: verify_x509_type = 0 Feb 23 18:35:49 ionos ovpn-server[962]: verify_x509_name = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: crl_file = 'crl.pem' Feb 23 18:35:49 ionos ovpn-server[962]: ns_cert_type = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_ku[i] = 0 Feb 23 18:35:49 ionos ovpn-server[962]: remote_cert_eku = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: ssl_flags = 192 Feb 23 18:35:49 ionos ovpn-server[962]: tls_timeout = 2 Feb 23 18:35:49 ionos ovpn-server[962]: renegotiate_bytes = -1 Feb 23 18:35:49 ionos ovpn-server[962]: renegotiate_packets = 0 Feb 23 18:35:49 ionos ovpn-server[962]: renegotiate_seconds = 3600 Feb 23 18:35:49 ionos ovpn-server[962]: handshake_window = 60 Feb 23 18:35:49 ionos ovpn-server[962]: transition_window = 3600 Feb 23 18:35:49 ionos ovpn-server[962]: single_session = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: push_peer_info = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: tls_exit = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: tls_auth_file = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: tls_crypt_file = 'tls-crypt.key' Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_protected_authentication = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_private_mode = 00000000 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_cert_private = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_pin_cache_period = -1 Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_id = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: pkcs11_id_management = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: server_network = 10.8.0.0 Feb 23 18:35:49 ionos ovpn-server[962]: server_netmask = 255.255.255.248 Feb 23 18:35:49 ionos ovpn-server[962]: server_network_ipv6 = :: Feb 23 18:35:49 ionos ovpn-server[962]: server_netbits_ipv6 = 0 Feb 23 18:35:49 ionos ovpn-server[962]: server_bridge_ip = 0.0.0.0 Feb 23 18:35:49 ionos ovpn-server[962]: server_bridge_netmask = 0.0.0.0 Feb 23 18:35:49 ionos ovpn-server[962]: server_bridge_pool_start = 0.0.0.0 Feb 23 18:35:49 ionos ovpn-server[962]: server_bridge_pool_end = 0.0.0.0 Feb 23 18:35:49 ionos ovpn-server[962]: push_entry = 'route-gateway 10.8.0.1' Feb 23 18:35:49 ionos ovpn-server[962]: push_entry = 'topology subnet' Feb 23 18:35:49 ionos ovpn-server[962]: push_entry = 'ping 10' Feb 23 18:35:49 ionos ovpn-server[962]: push_entry = 'ping-restart 120' Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_pool_defined = ENABLED Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_pool_start = 10.8.0.2 Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_pool_end = 10.8.0.5 Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_pool_netmask = 255.255.255.248 Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_pool_persist_filename = 'ipp.txt' Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_pool_persist_refresh_freq = 600 Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_ipv6_pool_defined = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_ipv6_pool_base = :: Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_ipv6_pool_netbits = 0 Feb 23 18:35:49 ionos ovpn-server[962]: n_bcast_buf = 256 Feb 23 18:35:49 ionos ovpn-server[962]: tcp_queue_limit = 64 Feb 23 18:35:49 ionos ovpn-server[962]: real_hash_size = 256 Feb 23 18:35:49 ionos ovpn-server[962]: virtual_hash_size = 256 Feb 23 18:35:49 ionos ovpn-server[962]: client_connect_script = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: learn_address_script = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: client_disconnect_script = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: client_config_dir = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: ccd_exclusive = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: tmp_dir = '/tmp' Feb 23 18:35:49 ionos ovpn-server[962]: push_ifconfig_defined = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: push_ifconfig_local = 0.0.0.0 Feb 23 18:35:49 ionos ovpn-server[962]: push_ifconfig_remote_netmask = 0.0.0.0 Feb 23 18:35:49 ionos ovpn-server[962]: push_ifconfig_ipv6_defined = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: push_ifconfig_ipv6_local = ::/0 Feb 23 18:35:49 ionos ovpn-server[962]: push_ifconfig_ipv6_remote = :: Feb 23 18:35:49 ionos ovpn-server[962]: enable_c2c = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: duplicate_cn = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: cf_max = 0 Feb 23 18:35:49 ionos ovpn-server[962]: cf_per = 0 Feb 23 18:35:49 ionos ovpn-server[962]: max_clients = 1024 Feb 23 18:35:49 ionos ovpn-server[962]: max_routes_per_client = 256 Feb 23 18:35:49 ionos ovpn-server[962]: auth_user_pass_verify_script = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: auth_user_pass_verify_script_via_file = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: auth_token_generate = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: auth_token_lifetime = 0 Feb 23 18:35:49 ionos ovpn-server[962]: port_share_host = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: port_share_port = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: client = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: pull = DISABLED Feb 23 18:35:49 ionos ovpn-server[962]: auth_user_pass_file = '[UNDEF]' Feb 23 18:35:49 ionos ovpn-server[962]: OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 20 2019 Feb 23 18:35:49 ionos ovpn-server[962]: library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10 Feb 23 18:35:49 ionos ovpn-server[962]: ECDH curve prime256v1 added Feb 23 18:35:49 ionos ovpn-server[962]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key Feb 23 18:35:49 ionos ovpn-server[962]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication Feb 23 18:35:49 ionos ovpn-server[962]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key Feb 23 18:35:49 ionos ovpn-server[962]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication Feb 23 18:35:49 ionos ovpn-server[962]: TLS-Auth MTU parms [ L:1622 D:1156 EF:94 EB:0 ET:0 EL:3 ] Feb 23 18:35:49 ionos ovpn-server[962]: ROUTE_GATEWAY 10.255.255.1 Feb 23 18:35:49 ionos ovpn-server[962]: TUN/TAP device tun0 opened Feb 23 18:35:49 ionos ovpn-server[962]: TUN/TAP TX queue length set to 100 Feb 23 18:35:49 ionos ovpn-server[962]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Feb 23 18:35:49 ionos ovpn-server[962]: /sbin/ip link set dev tun0 up mtu 1500 Feb 23 18:35:49 ionos ovpn-server[962]: /sbin/ip addr add dev tun0 10.8.0.1/29 broadcast 10.8.0.7 Feb 23 18:35:49 ionos ovpn-server[962]: /sbin/ip route add 10.0.50.0/24 via 10.8.0.2 Feb 23 18:35:49 ionos ovpn-server[962]: /sbin/ip route add 10.0.99.0/24 via 10.8.0.2 Feb 23 18:35:49 ionos ovpn-server[962]: Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ] Feb 23 18:35:49 ionos ovpn-server[962]: Could not determine IPv4/IPv6 protocol. Using AF_INET Feb 23 18:35:49 ionos ovpn-server[962]: Socket Buffers: R=[212992->212992] S=[212992->212992] Feb 23 18:35:49 ionos ovpn-server[962]: UDPv4 link local (bound): [AF_INET][undef]:1195 Feb 23 18:35:49 ionos ovpn-server[962]: UDPv4 link remote: [AF_UNSPEC] Feb 23 18:35:49 ionos ovpn-server[962]: GID set to nogroup Feb 23 18:35:49 ionos ovpn-server[962]: UID set to nobody Feb 23 18:35:49 ionos ovpn-server[962]: MULTI: multi_init called, r=256 v=256 Feb 23 18:35:49 ionos ovpn-server[962]: IFCONFIG POOL: base=10.8.0.2 size=4, ipv6=0 Feb 23 18:35:49 ionos ovpn-server[962]: ifconfig_pool_read(), in='pfsense,10.8.0.2', TODO: IPv6 Feb 23 18:35:49 ionos ovpn-server[962]: succeeded -> ifconfig_pool_set() Feb 23 18:35:49 ionos ovpn-server[962]: IFCONFIG POOL LIST Feb 23 18:35:49 ionos ovpn-server[962]: pfsense,10.8.0.2 Feb 23 18:35:49 ionos ovpn-server[962]: Initialization Sequence Completed Feb 23 18:36:00 ionos ovpn-server[962]: MULTI: multi_create_instance called Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy4:3557 Re-using SSL/TLS context Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 Control Channel MTU parms [ L:1622 D:1156 EF:94 EB:0 ET:0 EL:3 ] Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ] Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1550,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-GCM,auth [null-digest],keysize 128,key-method 2,tls-server' Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1550,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-GCM,auth [null-digest],keysize 128,key-method 2,tls-client' Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 TLS: Initial packet from [AF_INET]87.168.56.124:3557, sid=0cbd430f 8c200096 Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 VERIFY OK: depth=1, CN=cn_HwSmMZwjLayH0uQ7 Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 VERIFY OK: depth=0, CN=pfsense Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 peer info: IV_VER=2.4.9 Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 peer info: IV_PLAT=freebsd Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 peer info: IV_PROTO=2 Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 peer info: IV_LZ4=1 Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 peer info: IV_LZ4v2=1 Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 peer info: IV_LZO=1 Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 peer info: IV_COMP_STUB=1 Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 peer info: IV_COMP_STUBv2=1 Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 peer info: IV_TCPNL=1 Feb 23 18:36:00 ionos ovpn-server[962]:87.168.xxx.yyy:3557 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit EC, curve: prime256v1 Feb 23 18:36:00 ionos ovpn-server[962]: 87.168.xxx.yyy:3557 [pfsense] Peer Connection Initiated with [AF_INET]87.168.56.124:3557 Feb 23 18:36:00 ionos ovpn-server[962]: pfsense/87.168.xxx.yyy:3557 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled) Feb 23 18:36:00 ionos ovpn-server[962]: pfsense/87.168.xxx.yyy:3557 MULTI: Learn: 10.8.0.2 -> pfsense/87.168.56.124:3557 Feb 23 18:36:00 ionos ovpn-server[962]: pfsense/87.168.xxx.yyy:3557 MULTI: primary virtual IP for pfsense/87.168.56.124:3557: 10.8.0.2 Feb 23 18:36:01 ionos ovpn-server[962]: pfsense/87.168.xxx.yyy:3557 PUSH: Received control message: 'PUSH_REQUEST' Feb 23 18:36:01 ionos ovpn-server[962]: pfsense/87.168.xxx.yyy:3557 SENT CONTROL [pfsense]: 'PUSH_REPLY,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.248,peer-id 0' (status=1) Feb 23 18:36:01 ionos ovpn-server[962]: pfsense/87.168.xxx.yyy:3557 MULTI: bad source address from client [::], packet dropped Feb 23 18:36:02 ionos ovpn-server[962]: pfsense/87.168.xxx.yyy:3557 MULTI: bad source address from client [::], packet dropped -
Und Teil 2:
Und derOpenVPN Log der pfSense, fängt unten an:
Feb 23 18:36:01 openvpn 67955 Initialization Sequence Completed Feb 23 18:36:01 openvpn 67955 /usr/local/sbin/ovpn-linkup ovpnc2 1500 1553 10.8.0.2 255.255.255.248 init Feb 23 18:36:01 openvpn 67955 /sbin/ifconfig ovpnc2 10.8.0.2 10.8.0.1 mtu 1500 netmask 255.255.255.248 up Feb 23 18:36:01 openvpn 67955 TUN/TAP device /dev/tun2 opened Feb 23 18:36:01 openvpn 67955 TUN/TAP device ovpnc2 exists previously, keep at program end Feb 23 18:36:00 openvpn 67955 [server_2XW5mmuaPgD2ThUw] Peer Connection Initiated with [AF_INET]212.227.xxx.yyy:1195 Feb 23 18:36:00 openvpn 67955 UDPv4 link remote: [AF_INET]212.227.214.68:1195 Feb 23 18:36:00 openvpn 67955 UDPv4 link local (bound): [AF_INET]87.168.56.124:0 Feb 23 18:36:00 openvpn 67955 TCP/UDP: Preserving recently used remote address: [AF_INET]212.227.214.68:1195 Feb 23 18:36:00 openvpn 67955 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Feb 23 18:36:00 openvpn 67955 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Feb 23 18:36:00 openvpn 67736 library versions: OpenSSL 1.0.2u-freebsd 20 Dec 2019, LZO 2.10 Feb 23 18:36:00 openvpn 67736 OpenVPN 2.4.9 amd64-portbld-freebsd11.3 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on May 4 2020 Feb 23 18:35:33 openvpn 48589 SIGTERM[hard,] received, process exiting Feb 23 18:35:33 openvpn 48589 /usr/local/sbin/ovpn-linkdown ovpnc2 1500 1553 10.8.0.2 255.255.255.248 init Feb 23 18:35:33 openvpn 48589 event_wait : Interrupted system call (code=4)@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Das klappte nicht, /29 ja, bei /30 steikt openvpn.
Da hast du vermutlich eine Access-Server Konfiguration.
Nimm mal diese Zeilen raus:topology subnet ifconfig-pool-persist ipp.txtJa, waren drin. Habe sie auskommentiert, danach die Fehlermeldung unter /30
Feb 23 16:43:17 ionos ovpn-server[1401]: Options error: --server directive when used with --dev tun must define a subnet of 255.255.255.248 (/29) or lowerDer Client konnte sich nicht verbinden :(
Mit der Konstellation komme ich nicht rein über die VPS IP, dafür raus, über WAN :(
Zumindest wird die DTAG IP angezeigt beim speedtest-cli. Unter der sense das gleiche, Traffic nur über WAN. sollte über IONOS_VPN_WAN laufen, oder?
Hier noch mal die iptables:
iptables -t nat -vnL Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 148 6020 DNAT tcp -- ens192 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:3478:10080 to:10.0.50.11:3478-10080 12 4394 DNAT udp -- ens192 * 0.0.0.0/0 0.0.0.0/0 udp dpts:3478:10080 to:10.0.50.11:3478-10080 5 236 DNAT tcp -- ens192 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:10.0.99.222:80 0 0 DNAT tcp -- ens192 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:10.0.99.222:80 Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * ens192 10.0.50.0/24 0.0.0.0/0 0 0 MASQUERADE all -- * ens192 10.0.99.0/24 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination root@ionos:/home/mike# iptables -t nat -vnL Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 148 6020 DNAT tcp -- ens192 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:3478:10080 to:10.0.50.11:3478-10080 12 4394 DNAT udp -- ens192 * 0.0.0.0/0 0.0.0.0/0 udp dpts:3478:10080 to:10.0.50.11:3478-10080 5 236 DNAT tcp -- ens192 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:10.0.99.222:80 Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * ens192 10.0.50.0/24 0.0.0.0/0 0 0 MASQUERADE all -- * ens192 10.0.99.0/24 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination -
Die Portweiterleitung auf der pfSense sollte nicht mehr nötig sein. Kann aber auch nicht für das Nicht-Erreichen des Webservers verantwortlich sein.
Was ist mit den Regeln am OpenVPN und Floating Tab?
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Ja, waren drin. Habe sie auskommentiert, danach die Fehlermeldung unter /30
Feb 23 16:43:17 ionos ovpn-server[1401]: Options error: --server directive when used with --dev tun must define a subnet of 255.255.255.248 (/29) or lowerJa, da muss die Server-Zeile auch noch angepasst werden.
Anstattserver 10.8.0.0 255.255.255.0ifconfig 10.8.0.1 10.8.0.2Am Client ist dann nach meiner jüngsten Erfahrung das Tunnel Subnetz einzutragen, also 10.8.0.0/30. War früher bei SSL nicht nötig.
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Zumindest wird die DTAG IP angezeigt beim speedtest-cli. Unter der sense das gleiche, Traffic nur über WAN. sollte über IONOS_VPN_WAN laufen, oder?
Wenn die Verbindung steht, ja. Das Policy Routing sollte nichts anderes zulassen.
Du kannst das Firewall Log auf die angewandte Regel checken.
Es empfiehlt sich aber, dass die deinen Regeln erst eindeutige Beschreibungen gibst und auf allen relevanten das Logging aktivierst. -
Beim abschicken der Antwort gibt es eine Fehlermeldung "forbidden" :(
Jetzt aber...
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Die Portweiterleitung auf der pfSense sollte nicht mehr nötig sein. Kann aber auch nicht für das Nicht-Erreichen des Webservers verantwortlich sein.
Ja, schon mal zur Probe deaktiviert. Oke, wenn weg dann weg.
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Was ist mit den Regeln am OpenVPN und Floating Tab?
Welche OpenVPN Regeln? Die vom Client stehen oben. Oder meinst Du den OVPN Server:
Floating:
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Ja, da muss die Server-Zeile auch noch angepasst werden.
Anstatt
server 10.8.0.0 255.255.255.0ifconfig 10.8.0.1 10.8.0.2
Am Client ist dann nach meiner jüngsten Erfahrung das Tunnel Subnetz einzutragen, also 10.8.0.0/30. War früher bei SSL nicht nötig.
Laut dem Log war ein "ifconfig 10.8.0.2 10.8.0.1" in der remote conf gefordert, eingetragen in den Custom Options, looft.
Was auch in der server.conf raus muss ist das:
client-config-dir /etc/openvpn/ccddamit eine Verbindung aufgebaut wurde. Die server.conf sieht jetzt recht aufgeräumt aus. :)
Was aufgefallen ist, nach einem Restart des OVPN Servers kam die Meldung im Sekundentakt:ovpn-server[1327]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]87.168.xxx.yyy:49560 [0]Erst nach einem Neustart des Clienten der pfSense war Ruhe. Ist die Verbindung jetzt so empfindlich?
Feb 23 22:33:27 ionos ovpn-server[1327]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]87.168.xxx.yyy:49560 [0] Feb 23 22:33:27 ionos ovpn-server[1327]: TLS Error: local/remote TLS keys are out of sync: [AF_INET]87.168.xxx.yyy:49560 [0] Feb 23 22:33:28 ionos ovpn-server[1327]: TLS: Initial packet from [AF_INET]87.168.56.124:31730, sid=118e30cb 001f7b40 Feb 23 22:33:28 ionos ovpn-server[1327]: VERIFY OK: depth=1, CN=cn_HwSmMZwjLayH0uQ7 Feb 23 22:33:28 ionos ovpn-server[1327]: VERIFY OK: depth=0, CN=pfsense Feb 23 22:33:28 ionos ovpn-server[1327]: peer info: IV_VER=2.4.9 Feb 23 22:33:28 ionos ovpn-server[1327]: peer info: IV_PLAT=freebsd Feb 23 22:33:28 ionos ovpn-server[1327]: peer info: IV_PROTO=2 Feb 23 22:33:28 ionos ovpn-server[1327]: peer info: IV_LZ4=1 Feb 23 22:33:28 ionos ovpn-server[1327]: peer info: IV_LZ4v2=1 Feb 23 22:33:28 ionos ovpn-server[1327]: peer info: IV_LZO=1 Feb 23 22:33:28 ionos ovpn-server[1327]: peer info: IV_COMP_STUB=1 Feb 23 22:33:28 ionos ovpn-server[1327]: peer info: IV_COMP_STUBv2=1 Feb 23 22:33:28 ionos ovpn-server[1327]: peer info: IV_TCPNL=1 Feb 23 22:33:28 ionos ovpn-server[1327]: WARNING: 'ifconfig' is present in local config but missing in remote config, local='ifconfig 10.8.0.1 10.8.0.2' Feb 23 22:33:28 ionos ovpn-server[1327]: Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key Feb 23 22:33:28 ionos ovpn-server[1327]: Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key Feb 23 22:33:28 ionos ovpn-server[1327]: Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit EC, curve: prime256v1 Feb 23 22:33:28 ionos ovpn-server[1327]: [pfsense] Peer Connection Initiated with [AF_INET]87.168.56.124:31730 Feb 23 22:33:29 ionos ovpn-server[1327]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Feb 23 22:33:29 ionos ovpn-server[1327]: Initialization Sequence Completed Feb 23 22:33:29 ionos ovpn-server[1327]: PUSH: Received control message: 'PUSH_REQUEST' Feb 23 22:33:29 ionos ovpn-server[1327]: SENT CONTROL [pfsense]: 'PUSH_REPLY,peer-id 0' (status=1)Hmmm, die Warnug kommt immer noch, obwohl die Verbindung steht. Seltsam...
Feb 23 22:33:28 ionos ovpn-server[1327]: WARNING: 'ifconfig' is present in local config but missing in remote config, local='ifconfig 10.8.0.1 10.8.0.2' -
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Welche OpenVPN Regeln? Die vom Client stehen oben. Oder meinst Du den OVPN Server:
Du hast also auch einen Server laufen? Und das Subnetz in der Regel ist für dessen Clients?
Bedenke, dass diese Regeln auch für den Client gelten.
Der OpenVPN Tab ist eine Interface Group und enthält sämtliche OpenVPN Instanzen, die auf der Maschine laufen. Auf einem Interface-Group Tab definierte Regeln haben Vorrang gegenüber Regeln der Interfaces. Kommt eine solche Regel für die Site-to-Site-Verbindung zur Anwendung, funktioniert Reply-to nicht!
Deshalb wollte ich die Regeln sehen.Wenn du das also sauber trennen möchtest, solltest du dem Server auch ein eigenes Interface zuweisen und die Regeln dahin verschieben.
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Hmmm, die Warnug kommt immer noch, obwohl die Verbindung steht. Seltsam...
Feb 23 22:33:28 ionos ovpn-server[1327]: WARNING: 'ifconfig' is present in local config but missing in remote config, local='ifconfig 10.8.0.1 10.8.0.2'Am Client das Tunnel Netzwerk richtig einzutragen, hatte ich ja empfohlen.
Ansonsten sollten Pakete über den VPS eigentlich reinkommen.
Falls nicht und du aus den Filter-Log auch nichts herauslesen kannst, mach ein Packet-Capter auf der pfSense am VPN-Interface. Wenn Paket da, auch am internen.
Falls schon am VPN Interface nichts kommt, würde ich mal am VPS ein tcpdump auf beiden Interfaces machen. -
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Du hast also auch einen Server laufen? Und das Subnetz in der Regel ist für dessen Clients?
Ja, damit greife ich von Aussen aufs LAN zu.
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Bedenke, dass diese Regeln auch für den Client gelten.
Der OpenVPN Tab ist eine Interface Group und enthält sämtliche OpenVPN Instanzen, die auf der Maschine laufen. Auf einem Interface-Group Tab definierte Regeln haben Vorrang gegenüber Regeln der Interfaces. Kommt eine solche Regel für die Site-to-Site-Verbindung zur Anwendung, funktioniert Reply-to nicht!
Deshalb wollte ich die Regeln sehen.Echt jetzt? Das war mir bis jetzt nicht bekannt.
Und ehrlich gesagt stolper ich irgendwie über den Begriff "Tab". Das ist nicht die OpenVPN Oberfläche der pfSense inkl. aller Reiter, oder doch?Beide Instanzen (Server/Client) greifen auf das Interface "WAN" zu, das ist zu korrigieren?
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Am Client das Tunnel Netzwerk richtig einzutragen, hatte ich ja empfohlen.
Stimmt, wo trage ich die /30 ein, unter "IP Tunnel Network"?
Wenn ja, Meldung bleibt im Syslog.
Da gibt es noch den Punkt "Topology", der Punkt "net /30", der zaubert dir das "ifconfig 10.8.0.2 10.8.0.1" in die client.conf der pfSense. Also ist unter "custom options" kein Eintrag nötig. Langsam wird es... :)
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Wenn du das also sauber trennen möchtest, solltest du dem Server auch ein eigenes Interface zuweisen und die Regeln dahin verschieben.
Bahnhof...
Verstehe ich nicht. Habe nur ein WAN. Hier laufen zwei OVPN Instanzen, je einen für Server und Client mit jeweils eigenen Port. Unter Firewall/Rules gibt es zwei Reiter, Server und Client.Mal weiter googlen...
Erst mal grossen Dank, @viragomann, für deine Geduld und dein Engagement. Opferst richtig Zeit für die "Unwissenden" hier, mein grössten Respekt. sollte mal gesagt werden.
-
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Bedenke, dass diese Regeln auch für den Client gelten.
Der OpenVPN Tab ist eine Interface Group und enthält sämtliche OpenVPN Instanzen, die auf der Maschine laufen. Auf einem Interface-Group Tab definierte Regeln haben Vorrang gegenüber Regeln der Interfaces. Kommt eine solche Regel für die Site-to-Site-Verbindung zur Anwendung, funktioniert Reply-to nicht!
Deshalb wollte ich die Regeln sehen.Echt jetzt? Das war mir bis jetzt nicht bekannt.
Und ehrlich gesagt stolper ich irgendwie über den Begriff "Tab". Das ist nicht die OpenVPN Oberfläche der pfSense inkl. aller Reiter, oder doch?Hatte es oben erklärt und auch hinzugefügt, dass der OpenVPN Tab (ja, die Reiter in Firewall > Rules) eine Interface-Gruppe ist, die sämtliche OpenVPN Instanzen enthälten. Regeln hier wirken sich also auf alle Instanzen aus.
Und deine Antwort:@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Alles top erklärt, @viragomann , habe alles verstanden soweit.
Was ich da aber vergessen habe, war zu erwähnen, dass Regeln auf Interface Groups, also auf OpenVPN, Vorrang gegenüber anderen haben. Heißt, trifft eine solche Regel zu wird sie angewandt und Regeln an den Interface Tabs ignoriert.
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Da gibt es noch den Punkt "Topology", der Punkt "net /30", der zaubert dir das "ifconfig 10.8.0.2 10.8.0.1" in die client.conf der pfSense.
Wusste gar nicht, dass der hier eine Auswirkung hat. Bei einem Peer-to-Peer Client hatte ich da noch nie was geändert.
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Wenn du das also sauber trennen möchtest, solltest du dem Server auch ein eigenes Interface zuweisen und die Regeln dahin verschieben.
Bahnhof...
Verstehe ich nicht. Habe nur ein WAN. Hier laufen zwei OVPN Instanzen, je einen für Server und Client mit jeweils eigenen Port. Unter Firewall/Rules gibt es zwei Reiter, Server und Client.Hast du doch auch schon für die Client-Instanz gemacht.
Interfaces > Assignments
Bei "Available network ports:" die OpenVPN Server auswählen (bspw. ovpns3) > Add, das Interface öffnen, Enable anhaken und einen hübschen Namen für eigene Zwecke eingeben, Save.Danach sind die VPN-Verbindungen erstmal weg. Gehe dann auf Firewall > Rules > OpenVPN und editiere die Regel und ändere das Interface auf das neu erstellte.
Eventuell will die pfSense neu gestartet werden, damit alle VPNs wieder laufen. -
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Hatte es oben erklärt und auch hinzugefügt, dass der OpenVPN Tab (ja, die Reiter in Firewall > Rules) eine Interface-Gruppe ist, die sämtliche OpenVPN Instanzen enthälten. Regeln hier wirken sich also auf alle Instanzen aus.
Und deine Antwort:
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:Alles top erklärt, @viragomann , habe alles verstanden soweit.
Ich beziehe mich auf das soweit. :)
Hatte es so verstanden, dass ein Firewall Tab inkl aller darin vorhandener Interfaces eine Gruppe ist, nicht alle (OVPN) Tabs zusammen. Danke für den Hinweis, wieder was gelernt :)
Jedenfalls läuft es jetzt.
Das 10.8.0.0/30 unter "Tunnel Subnet" ist genauso notwendig wie das "net /30" unter Topologie imho.
Ein sauberer Neustart der Sense und Server und die Verbindung steht, die Testseite im LAN ist durch die IP des VPS erreichbar und etliche Anfragen prasseln auf die PS4 nieder.
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Falls nicht und du aus den Filter-Log auch nichts herauslesen kannst, mach ein Packet-Capter auf der pfSense am VPN-Interface. Wenn Paket da, auch am internen.
Falls schon am VPN Interface nichts kommt, würde ich mal am VPS ein tcpdump auf beiden Interfaces machen.Gesagt, getan. nachdem es läuft und der Traffic raus weiter nicht über das Client Interface geht, habe ich das IF ne Zeitlang gesnifft. Zu erkennen ist der Zugriff auf die Testseite rein und raus und die etlichen Anfragen und Antworten auf die IP der Playse. Das muss ich noch ändern in der iptables Liste, die ist gerade recht weit offen.
Was nicht über das Client VPN Gateway geht sind die Anfragen aus dem LAN, obwohl dieser ausgewählt ist in den Rules. Zumindest sehe ich keine Pakete auf dem Interface in die Richtung. :(
Müsste mal tcpdump auf dem VPS installieren und das da mal checken.
Auf alle Fälle geht der Zugriff von Aussen, Danke.
-
Schon mal ein deutlicher Fortschritt. @mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Was nicht über das Client VPN Gateway geht sind die Anfragen aus dem LAN, obwohl dieser ausgewählt ist in den Rules. Zumindest sehe ich keine Pakete auf dem Interface in die Richtung. :(
Müsste mal tcpdump auf dem VPS installieren und das da mal checken.Dafür hast du ja die Policy Routing Regel.
Du hast oben geschrieben, die Pakete gehen zum WAN raus. Ist das immer noch der Fall?Damit diese Regel nicht angewandt wird, müsste eine dieser Bedingungen erfüllt sein:
- die Regelparameter treffen nicht zu (Kombi aus Interface, Protocol, Source IP u. Port, Dest. IP u. Port)
- das gesetzte Interface ist down
Das lässt sich leicht überprüfen. Dafür auch die Empfehlung oben schon, den Regeln eindeutige Beschreibungen zu geben und das Logging zu aktivieren. Dann kannst du im Log nachsehen, welche Regel den Traffic erlaubt hat.
Wenn die Policy Routing Regel ihre Funktion erfüllt, ist dann noch die Masquerading Regel am VPS verantwortlich, dass die Paket richtig genattet werden. Funktioniert diese nicht, das Policy Routing jedoch schon, schlägt aber die Verbindung total fehl.
-
Gratuliere Jungs.
-
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Dafür hast du ja die Policy Routing Regel.
Du hast oben geschrieben, die Pakete gehen zum WAN raus. Ist das immer noch der Fall?Ja.
Der Check mit tcpdump auf dem VPS erkennt kein Traffic, weder auf tun0 noch auf dem anderen env192.@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Damit diese Regel nicht angewandt wird, müsste eine dieser Bedingungen erfüllt sein:
die Regelparameter treffen nicht zu (Kombi aus Interface, Protocol, Source IP u. Port, Dest. IP u. Port)
das gesetzte Interface ist downInterface ist up
Hier nochmal die aktuellen Screenshots der Rules.
OVPN Server:
OVPN Client:
TESTING Subnet:
GAMING Subnet:
VPN Client, Test- und Gamingsubnet sind alle allow any to any, da kann alles raus.
Die Firewallogs besagen, dass z. B. der Testhost beim Pingen das eigene Interface nutzt. :(
Witzigerweise nutzt die Playse beide Interfaces:
Langsam verstehe ich gar nichts mehr. :(
Edit:
Durch das "USER RULE (1614078764)" werde die Pakete von Gaming Richtung IONOS_VPN_WAN geschupst. 1614078764 ist die Tracking ID von der letzten Rule unter GAMING. Also ist das so richtig.Edit2:
In den Rules steht zwar der IONOS_VPN_WAN Gateway drin, in den Einstellungen war das Feld leer. :(
Also neu auswählen, speichern, nun funzt es auch unter TESTING:
Eine schwere Geburt. :)
-
-
@mike69
Hätte ja erstmal ein Packet Capture auf der pfSense am VPN-Interface gereicht, um zu sehen, ob die Pakete da raus gehen.Mich verwirrt dass das VPN-Gateway auf TESTING "IONOS_VPN_VPNV4" heißt, während es auf GAMING "IONOS_VPN_WAN_VPNV4" heißt.
Kannst du mal abklären, woher die beiden Namen kommen? Welche Namen haben die Interfaces der VPN Instanzen?
Was findet sich in System > Routing > Gateways?@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Die Firewallogs besagen, dass z. B. der Testhost beim Pingen das eigene Interface nutzt. :(
Das Log zeigt das Interface, auf welchem die Regel definiert ist.
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Witzigerweise nutzt die Playse beide Interfaces:
Hier greifen offenbar zwei Regeln. Die mit dem Dreieck sollte eien ausgehende Floating Regel sein.
Das was in der Spalte "Rule" zu finden ist, ist die Beschreibung der Regel. "USER RULE" ist abgesehen von der ID leider die ganze Info, die das Log zeigen kann, wenn du den Regeln keine Beschreibungen spendierst. Wenn du so vehement meine Empfehlungen missachtest, kann ich leider auch nicht wirklich weiterhelfen.
Du kannst bestenfalls die ID der Regel verwenden, um weitere Details der Regel ausfindig zu machen. Kopiere diese, gehe auf Diagnostic > Command Prompt und füge sie folgendem Befehl an und führe ihn aus:
pfctl -vvsr | grepEinfach das in Execute Shell Command einfügen, die Regel ID hinten dran und ausführen.
