Was @viragomann sagt. Linux ist je nach Distro, GUI und Client vogelwild was gemacht wird. Auch bei den DNS Einstellungen. Jeder hat da was Eigenes. Bisschen nervig. Ich vermute da auch, dass schlicht der Linux Client einfach alles übers VPN juckelt weil irgendein Automatismus mal wieder überreaktiv ist oder irgendein Haken in der UI gesetzt ist, was die Settings vom Configfile/Client überschreibt. Wäre nicht das erste Mal :)

@hsrtreml Ticket bei Netgate aufgemacht dafür? Da ist meist innerhalb eines Tages der Download Link da. Für die 4860 ist es aber auch schwieriger ein Image zu bekommen, weil die schon lange EOS/EOL ist. Wenn sich aber niemand meldet, gib ggf. nochmal Bescheid, wir haben als Partner die Images ggf. auch schon direkt abrufen können. Cheers

@fireodo Nicht unbedingt. Wenn der HW Watchdog wegen harter Limitüberschreitung ggf. direktes Powerdown anfordert, steht vllt. was auf der Konsole aber nicht unbedingt im Log wenn da alles abgeschossen wird. Dann ist keine Zeit mehr auf liebes Logging vom Temp Prozess zu warten ;) Also gerade bei >80° klingt das sehr nach Thermikproblemen. Das ist einer der großen Schwachpunkte der APU/APUx Serie leider schon immer gewesen. Wenn die nicht sauber und akkurat mit dem Wärmepad und der Paste verbaut und verschraubt werden, gehen die extrem schnell über ihre Temp-Werte raus. Hatten da leider auch viel zu viel Rückläufer und deshalb angefangen die Boxen im professionellen Umfeld schlicht zu meiden. Wenn so ein Ding irgendwo in nem Schaltschrank verbastelt wird, dann kannst du da nicht alle 2 Wochen reinkrabbeln und neu starten o.ä. das muss laufen, egal obs mal 5-6° wärmer im Schrank ist. ;) Ansonsten scheint es ja das Netzteil nicht zu sein - ich würde mit Wärmemessung das Ding im Auge behalten und die nächsten Tage schauen, klingt aber sehr nach Wärme. Cheers

Ja, wobei die so viel CPU Power hat, die man ohne die Möglichkeit eine 10G Karte nach zu rüsten, gar nicht auf die NIC bekommt. Das Teil ist also eher ein Hypervisor, bei dem dann x Sachen parallel drauf laufen und keine reine Firewall Appliance. Denn dann müssten hier wie bei einer SG-6100er 10G NICs rein und die Leistung auf auf die Straße zu bekommen.

Moinsen, so. Update via Neuinstallation und conifg.xml einspielen hat gut funktioniert. Im Nachgang mussten: die Paketquellen angepasst werden, um verfügbare Pakete anzeigen zu lassen die Listen für pfblockerNG_dev neu eingelesen werden FreeRadius musste neuinstalliert werden, danach erfolgte das Starten desselben via console, da via GUI kein Start erfolgte (merhfach versucht, keine Ahnung warum, läuft jetzt aber)...die KOnfiguration blieb dabei aber erhalten alle bis auf eine Firewallregel wurden aus der config.xml übernommen, lediglich das Erlauben von DNS Anfragen für unbound musste neu angelegt werden. Alles andere funktionierte sofort ohne weiteres Zutun. Bisher läuft es seit 16 Stunden problemlos durch, alle Aliase, IPv4 und v6 Einstellungen am Start, openVPN problemlos. Danke für die Arbeit... :) Grüßle the other

Wobei ich es praktisch finde z.B. die 1.1.1.1 für das GW Monitoring zu nutzen, denn so ist dann wirklich sichergestellt das hier das Internet auch wirklich erreichbar ist. Zudem sieht man dann auch schon was für einen verknotetes Routing der Provider hier schon mal abliefert.

@mike69 hab ich gemacht, pinge was anderes an, passt und nochmals danke für die vielen Hinweise, echt Klasse hier, das Forum meine ich!

in deiner Client Config solltest du mal : Address = 192.168.255.253/24 setzen. Die Peer Config in der pfsense aber so lassen wie es ist (/32)

@knebb ja, in deinem fall ist die gegenseite dein provider und nicht dein modem. das ist dein gedanken fehler

@msiemers Aah split personality ... ja sowas kann fies sein :) Fein dass es läuft!

@mpatzwah Also solange nicht klar definiert ist, was du bauen willst, kann ich da schlecht weiterhelfen. Manchmal schreibst du aus Sicht von deinem "Homeoffice", mal aus der Firmensicht, da verstehe ich inzwischen nichts mehr. Es wäre schön, wenn du a) entweder mal nen kleinen Netzplan machst, egal ob Ascii oder sonst wie (siehe angepinnter Beitrag da sind Möglichkeiten drin) b) oder einfach mal klar und deutlich beschrieben wird: wo sind welche Anschlüsse vorhanden klare Definition, WO MultiWAN und wo SingleWAN ist klare Ansage, was an OpenVPN konfiguriert ist auf welcher Seite und wie Erst dann kann ich sinnvoll sagen, was genau wie konfiguriert werden muss. Vorher ist das ein einziges Durcheinander, weil es sich teils so anhört, als wenn abgehend aus dem Homeoffice 2 Leitungen da sind - dann muss die Client Seite ja entsprechend konfiguriert sein. Und dann kommen wieder Sätze die so klingen als wäre die Firma mit 2 Leitungen angebunden, dann müsste der Server entsprehchend ganz anders konfiguriert werden und ggf. noch ein Kniff zum MultiWAN rein, damit das sauber funktioniert. Daher bitte einfach mal klarstellen, welches Szenario wir hier haben :) Cheers

@ags101 said in Newbe Hardware Frage: Ich glaube ich verstehe Euch jetzt und merke, dass für meinen usecase fast schon ein raspi 4 reichen würde (sofern man intel nics daran schrauben könnte/würde). Nö, weil ARM wieder ne ganz andere Plattform ist. Vielleicht ja, aber das kann man nicht einfach transferieren und deshalb nicht so einfach abstrahierbar. Aber ja für den normalen Hausgebrauch mit Gigabit ist sicher ein Atom C3k mehr als genug. Da würde wahrscheinlich sogar noch ein alter C2k Atom reichen. Wobei man da wiederum nicht wieder Atom mit Atom verwechseln sollte. Die C-Atoms sind für Netzwerk gebaut. Kann man wiederum nicht einfach mit E- oder anderen Atom CPUs vergleichen :) @ags101 said in Newbe Hardware Frage: Vom preispunkt gefällt mir das Supermicro board mit Atom C3558 für um die 350€ recht gut. Dazu noch 16GB ECC und eine 128GB M2 und ich habe mehr Leistung als die 6100, liege preislich aber drunter. Der C3558 ist ein extrem guter SOC für den Zweck. Du hast zwar nicht mehr Leistung als eine 6100 aber vergleichbar. @ags101 said in Newbe Hardware Frage: Btw. Nachdem meine Fragen beantwortet wurden, muss ich diesen thread schließen oder irgendwie markieren? Nö schon OK, aber du kannst dein Anfangs-Post nochmal editieren und da den Topic ändern mit [Gelöst] oder [Solved] vor dem Rest, aber das ist optional. :)

Ich habe auf dem Client zum Test mal eine etwas größere Datei heruntergeladen und siehe da: Der Traffic erhöht sich in der Folge tatsächlich bei beiden VPN-Verbindungen. Somit scheinen beide Tunnel wohl kaskadiert zu laufen. Mein aktuelles Setup funktioniert allerdings anscheinend nur solange, bis es zur nächtlichen Zwangstrennung kommt. Anschließend werden beide VPN-Tunnel zwar wieder verbunden, aber der Client hat trotzdem keinen Internetzugang. Erst wenn ich beim VPN-Client PIA_SCHWEIZ das Interface einmal manuell von PIA_LUXEMBURG auf WAN und wieder zurück auf PIA_LUXEMBURG stelle, hat der Client im LAN wieder Zugang zum Internet. Hat jemand eine Idee woran dies liegen könnte? In den Logs der pfSense zu Open-VPN sieht es folgendermaßen aus: Feb 10 03:30:01 openvpn 52072 write UDPv4: No route to host (code=65) Feb 10 03:30:01 openvpn 736 write UDPv4: No route to host (code=65) Feb 10 03:30:01 openvpn 736 write UDPv4: No route to host (code=65) Feb 10 03:30:01 openvpn 52072 write UDPv4: No route to host (code=65) Feb 10 03:30:02 openvpn 52072 write UDPv4: No route to host (code=65) Feb 10 03:30:02 openvpn 52072 write UDPv4: No route to host (code=65) Feb 10 03:30:03 openvpn 52072 write UDPv4: No route to host (code=65) Feb 10 03:30:03 openvpn 52072 write UDPv4: No route to host (code=65) Feb 10 03:30:04 openvpn 52072 write UDPv4: No route to host (code=65) Feb 10 03:30:04 openvpn 52072 write UDPv4: No route to host (code=65) Feb 10 03:30:05 openvpn 52072 write UDPv4: No route to host (code=65) Feb 10 03:30:05 openvpn 52072 write UDPv4: No route to host (code=65) Feb 10 03:30:05 openvpn 52072 write UDPv4: No route to host (code=65) Feb 10 03:30:05 openvpn 736 write UDPv4: No route to host (code=65) Feb 10 03:30:06 openvpn 52072 write UDPv4: No route to host (code=65) Feb 10 03:30:06 openvpn 736 write UDPv4: No route to host (code=65) Feb 10 03:30:06 openvpn 52072 write UDPv4: No route to host (code=65) Feb 10 03:30:06 openvpn 736 write UDPv4: No route to host (code=65) Feb 10 03:30:07 openvpn 52072 write UDPv4: No route to host (code=65) Feb 10 03:30:07 openvpn 736 write UDPv4: No route to host (code=65) Feb 10 03:30:07 openvpn 52072 write UDPv4: No route to host (code=65) Feb 10 03:30:07 openvpn 736 write UDPv4: No route to host (code=65) Feb 10 03:30:18 openvpn 736 event_wait : Interrupted system call (code=4) Feb 10 03:30:18 openvpn 736 SIGTERM received, sending exit notification to peer Feb 10 03:30:19 openvpn 736 /usr/local/sbin/ovpn-linkdown ovpnc2 1500 1552 10.2.112.73 255.255.255.0 init Feb 10 03:30:19 openvpn 736 SIGTERM[soft,exit-with-notification] received, process exiting Feb 10 03:30:19 openvpn 74448 WARNING: file '/var/etc/openvpn/client2/up' is group or others accessible Feb 10 03:30:19 openvpn 74448 OpenVPN 2.5.2 amd64-portbld-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Nov 15 2021 Feb 10 03:30:19 openvpn 74448 library versions: OpenSSL 1.1.1k-freebsd 25 Mar 2021, LZO 2.10 Feb 10 03:30:19 openvpn 75337 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Feb 10 03:30:19 openvpn 75337 WARNING: experimental option --capath /var/etc/openvpn/client2/ca Feb 10 03:30:19 openvpn 75337 TCP/UDP: Preserving recently used remote address: [AF_INET]5.253.204.107:1198 Feb 10 03:30:19 openvpn 75337 UDPv4 link local (bound): [AF_INET]217.xxx.xxx.xxx:0 Feb 10 03:30:19 openvpn 75337 UDPv4 link remote: [AF_INET]5.253.204.107:1198 Feb 10 03:30:19 openvpn 75337 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1569', remote='link-mtu 1542' Feb 10 03:30:19 openvpn 75337 WARNING: 'auth' is used inconsistently, local='auth SHA256', remote='auth SHA1' Feb 10 03:30:19 openvpn 75337 WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128' Feb 10 03:30:19 openvpn 75337 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo' Feb 10 03:30:19 openvpn 75337 [luxembourg404] Peer Connection Initiated with [AF_INET]5.253.204.107:1198 Feb 10 03:30:19 openvpn 75337 Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS]) Feb 10 03:30:19 openvpn 75337 Options error: option 'route-ipv6' cannot be used in this context ([PUSH-OPTIONS]) Feb 10 03:30:19 openvpn 75337 Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS]) Feb 10 03:30:19 openvpn 75337 TUN/TAP device ovpnc2 exists previously, keep at program end Feb 10 03:30:19 openvpn 75337 TUN/TAP device /dev/tun2 opened Feb 10 03:30:19 openvpn 75337 /sbin/ifconfig ovpnc2 10.9.112.52 10.9.112.1 mtu 1500 netmask 255.255.255.0 up Feb 10 03:30:19 openvpn 75337 /usr/local/sbin/ovpn-linkup ovpnc2 1500 1552 10.9.112.52 255.255.255.0 init Feb 10 03:30:19 openvpn 75337 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Feb 10 03:30:19 openvpn 75337 Initialization Sequence Completed Feb 10 03:31:00 openvpn 52072 [zurich402] Inactivity timeout (--ping-restart), restarting Feb 10 03:31:00 openvpn 52072 SIGUSR1[soft,ping-restart] received, process restarting Feb 10 03:31:05 openvpn 52072 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Feb 10 03:31:05 openvpn 52072 TCP/UDP: Preserving recently used remote address: [AF_INET]212.102.37.200:1198 Feb 10 03:31:05 openvpn 52072 TCP/UDP: Socket bind failed on local address [AF_INET]10.2.112.73:0: Can't assign requested address (errno=49) Feb 10 03:31:05 openvpn 52072 Exiting due to fatal error Feb 10 03:31:05 openvpn 52072 /usr/local/sbin/ovpn-linkdown ovpnc1 1500 1622 10.23.112.116 255.255.255.0 init Feb 10 03:32:00 openvpn 76840 WARNING: file '/var/etc/openvpn/client1/up' is group or others accessible Feb 10 03:32:00 openvpn 76840 OpenVPN 2.5.2 amd64-portbld-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Nov 15 2021 Feb 10 03:32:00 openvpn 76840 library versions: OpenSSL 1.1.1k-freebsd 25 Mar 2021, LZO 2.10 Feb 10 03:32:00 openvpn 77162 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Feb 10 03:32:00 openvpn 77162 WARNING: experimental option --capath /var/etc/openvpn/client1/ca Feb 10 03:32:00 openvpn 77162 TCP/UDP: Preserving recently used remote address: [AF_INET]212.102.37.60:1198 Feb 10 03:32:00 openvpn 77162 UDPv4 link local (bound): [AF_INET]10.9.112.52:0 Feb 10 03:32:00 openvpn 77162 UDPv4 link remote: [AF_INET]212.102.37.60:1198 Feb 10 03:32:00 openvpn 77162 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1569', remote='link-mtu 1542' Feb 10 03:32:00 openvpn 77162 WARNING: 'auth' is used inconsistently, local='auth SHA256', remote='auth SHA1' Feb 10 03:32:00 openvpn 77162 WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128' Feb 10 03:32:00 openvpn 77162 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo' Feb 10 03:32:00 openvpn 77162 [zurich404] Peer Connection Initiated with [AF_INET]212.102.37.60:1198 Feb 10 03:32:00 openvpn 77162 Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS]) Feb 10 03:32:00 openvpn 77162 Options error: option 'route-ipv6' cannot be used in this context ([PUSH-OPTIONS]) Feb 10 03:32:00 openvpn 77162 Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS]) Feb 10 03:32:00 openvpn 77162 TUN/TAP device ovpnc1 exists previously, keep at program end Feb 10 03:32:00 openvpn 77162 TUN/TAP device /dev/tun1 opened Feb 10 03:32:00 openvpn 77162 /sbin/ifconfig ovpnc1 10.17.112.127 10.17.112.1 mtu 1500 netmask 255.255.255.0 up Feb 10 03:32:00 openvpn 77162 /usr/local/sbin/ovpn-linkup ovpnc1 1500 1552 10.17.112.127 255.255.255.0 init Feb 10 03:32:00 openvpn 77162 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Feb 10 03:32:00 openvpn 77162 Initialization Sequence Completed

@eyetap said in DNS Forwarder bei Dual WAN im Failover: Nun ja - logisch dass die Routen bleiben - OK. Nicht logisch wenn die auch, wenn das zugewiesene Gateway down ist, auch aktiv weiter versucht werden zu verwenden und dann Timeouts liefern. Durchaus logisch, denn sie werden fest konfiguriert über DIESE GWs zu gehen. Wenn du keine GW Zuweisung machst, gehen sie übers Default. Das ist aber auch in der Doku beschrieben :) @eyetap said in DNS Forwarder bei Dual WAN im Failover: Einfach nur in der Annahme, dass der Provider bzw Downstream DNS flotter ist als ich. Wäre ja eigentlich auch traurig wenn nicht.. :) Was ist Geschwindigkeit ggü Zuverlässigkeit? ;) Zumal der Vorteil beim echten Resolver nur einmal besteht, danach greift Caching und der Rest ist dann egal. Zu viel Zentralisierung war leider gerade bei DNS noch nie zielführend :) @eyetap said in DNS Forwarder bei Dual WAN im Failover: Mit genug Forwardern wär das ja kein Thema.. ;-) Doch, denn die meisten bleiben dann doch wieder bei den großen/größten Forwardern hängen. Und dann gibt es schlicht Abhängigkeit von ein paar großen DNS Schleudern, die dann lustig fröhlich ausliefern können was sie wollen. Worin das gipfelt zeigt sich gerade erst beim Prozess gegen die (jetzt schweizer) Betreiber von 9.9.9.9 die per Verfügung dazu genötigt werden (sollen), dass diverse Domains nicht mehr erreichbar / auflösbar sind über ihre Resolver. Allerdings soll das dann auch nur aus dem entsprechenden Land nicht auflösbar sein, etc. bla fasel. Es ist wieder kompletter Nonsense, weil die Leute DNS nicht verstehen und die Komplexität von "IP Adresse ist keine fixe Hausnummer in Deutschland" nicht begreifen. Da klebt in den Köpfen, dass man IPs festnageln kann auf ein Land (jeder der schon GeoIP gemacht oder genutzt hat weiß wie ungenau und doof solch eine Annahme ist). Und dann ist das ja einfach zu machen. Dass die Umsetzung extrem schwierig und schwammig wird und im Endeffekt nur dazu führt, dass die Leute andere Forwarder - oder wesentlich sinniger - einen eigenen Resolver nutzen, der auf irgendwelche Forwarder pfeift und die Domain einfach vom eingetragenen SOA Server der Domain holt ist in den Kleinhirnen leider nicht angekommen. Aber an genau diesen Prozessen sowie den vergangenen Problemen mit irgendwelchen Forwardern von Betreibern sowie Happenings wie DNS Search Redirection, falschen IPs statt NXDOMAIN Antworten, DNS Umleitungen, Domain Parking DNS Redirection und was-weiß-ich-nicht-mehr-alles-für-anderen-Schmutz lernt man auf die harte Tour, dass man von zentralen Ansätzen lieber die Finger lässt. Die Idee, einfach lokal bspw. 10 oder noch mehr Forwarder einzutragen ist BTW leider genauso unsinnig, da die Forwarder/Logik das gar nicht sinnvoll nutzen kann. Der korrekte Ansatz in der Richtig wäre dann tatsächlich ein Konzept wie ODNS oder DoHoT was zusammen mit dnscrypt als stub resolver und DNS "loadbalancer" inkl. selection mechanism gegen DNS bias einhergeht. Damit könnte man dann so halbwegs was anfangen :)

@shadeless said in DynDNS Client Einstellungen für STRATO: Wenn du mehrmals innerhalb kurzer Zeit ein Update machst, sperrt dich Strato für ein paar Minuten bis wenige Stunden. Hab ich auch gehabt beim ausprobieren. Ging bis jetzt immer nach etwas abwarten von alleine wieder. Ja, ging dann wieder :-) @shadeless said in DynDNS Client Einstellungen für STRATO: Anstatt "good %IP% | nochg %IP%" musst du "good %IP%|nochg %IP%" (ohne leerzeichen vor und nach dem |) eintragen. Dann kann das Ergebnis richtig ausgewertet werden. ok, habe ich drin. Werde es beobachten

@zomhad Der Kollege mit dem ich damals telefoniert hatte meinte, er mache gerade nix anderes, da sie gerade endlos Kunden von Kabelanbietern etc. bekommen würden und die natürlich pandemisch bedingt hauptsächlich ne stabile Verbindung brauchen würden und meistens eben in irgendwelche FirmenVPNs rein müssen. Und da hier ganz viel noch v4 only läuft und es durch MTU und sonstige Sperenzchen dann durchaus Probleme gab/gibt, wissen die da schon Bescheid. Solang sie noch größere IP4 Bereiche haben, wird das sehr wahrscheinlich kein Problem. Kabel- und Neuanbieter am Markt haben es da meist schwerer da sie auf nicht so große IP4 Segmente zurückgreifen können und schneller am Limit sind wo sie einsparen müssen.

@benjaminpc said in PfSense AWS OpenVPN kein Internet: Wenn ich mich aber nun via OpenVPN verbinde kann ich zwar die PfSense pingen aber nicht die Server im LAN Netz Ebenso haben die Server kein Internet Beide Symptome könnten hier dieselbe Ursache haben, aber auch verschiedene. Ich würde die Internet Verbindung der VMs als erstes in Angriff nehmen. Scheint mir leichter zu klären zu sein. Nachdem die pfSense aus dem Internet erreichbar ist und ihrerseits die Server erreichen kann, besteht mal "physisch" eine durchgehende Verbindung. Ich nehme an, vom LAN ist nach wie vor alles erlaubt, also die standardmäßige any-to-any Regel aktiv. Dann versuche mal von einer VM einen Ping auf 8.8.8.8. Wenn das funktionieren sollte, liegt es vermutlich daran, dass die VMs keine Hostnamen auflösen können. Falls der Ping auch scheitert, könnte das Outbound NAT nicht funktionieren. Dann würde ich die Frage stellen, wie dein WAN konfiguriert ist. Wenn manuell, hast du in den Interface Einstellungen auch das Gateway angegeben?

@jegr HAProxy 1.6 konnte noch kein HTTP/2, das wurde erst mit der Version 1.8 eingeführt. Die 1.6 Version war stable und die 1.8 devel. Siehe https://www.haproxy.org/#desc

Ok, den Forward-Mode deaktiviert und dort die Host-Überschreibung gelöscht. Den Resolver-Mode wieder aktiviert und dort die Host-Überschreibung hinzugefügt. In den Allgemeinen Einstellungen die beiden DNS-Server entfernt. Mit dig vom Client aus die gw.meinedomain.de abegfragt. Als Ergebnis erhalte ich die LAN-IP. So sollte es nun passen

@ileonard said in Hinter PfSense HaProxy KeyHelp: Die Zertifikate müsste man ja wie gehabt in der Sense hinterlegen und dann noch einmal in KeyHelp. Warum das denn? Wenn HAproxy die SSL Verbindung terminiert braucht der Server dahinter kein öffentlich gültiges Zert zu haben. Klar, ist schön, muss aber nicht. Müsste nicht mal SSL sprechen, denn das übernimmt gegenüber dem Client ja HAproxy für ihn - dafür ist er ja da. Und ob das im Bild jetzt irgendwelche wurstigen Webserver 01/02/03 sind die am "HAproxy hängen" oder ob das irgendein ISP-haumichblau-machsdireinfach Server ist ist doch für HAproxy völlig egal. Ich weiß zwar nicht, wie in einem netz mit 192.168.4.x plötzlich eine 10.0.0.5 auftaucht (eigenes Netzsegment der pfSense dann?) aber für den HAProxy ist das einfach nur noch ein weiteres Backend das er bedient. Solang das richtig eingerichtet ist, ist dem der Server egal. Er braucht die Zerts zum Ausliefern und die Info, was er mit "kundendomain1, kundendomain2, wordpress3, etc." anfangen soll. Also per Host Header weiterreichen aufs Backend. Ende Gelände Aber dann sollte man sich vielleicht einfach überlegen, ob man - wenn man schon irgendein ISP Wartungsdings Server bauen möchte für Kunden - diesen dann nicht mit ner eigenen IP betreibt. Und dann eben notfalls noch ne zusätzliche IP oder nen Anschluß ranholt. "Mal eben" so nebenbei auf der kleinen Leitung noch nen Server zu hosten haben schon viele gedacht, die es dann zerlegt hat. Wenn das irgendein halbwegs ernstes Business werden soll, sollte man das von Anfang an auch so aufziehen und ernst nehmen und entsprechend bauen und nicht quick & dirty reinhauen. Das beißt einen später beim Wachsen wenns gut läuft nämlich ordentlich in den Allerwertesten. Cheers