Vielen dank für eure Hilfe.

Folgendes war das Problem:
Der DHCP Server hat den Request bekommen, allerdings konnte er ohne Standardgateway nicht auf die Anfrage antworten.
Nachdem ich die Firewall als Standardgateway hinzugefügt habe lief alles ohne Probleme. Anschließend habe ich ihn einfach per Route auf das Gateway gezogen. Alles tuti nun :)

Falls jemand den Thread findet und ein ähnliches Problem hat:

Das Problem habe ich gefunden in dem ich mit hilfe von Wireshark, mir den Traffic auf dem Server angeschaut habe. Dort war zu sehen, dass die DHCP Anfrage eintrifft aber nicht raus kommt.

Ok, aber wie würde man das Schritt für Schritt einstellen? Das ist nicht gerade ersichtlich im Traffic Shaper.
Ich würde im Traffic Shaper das VLAN auswählen, aktivieren, Scheduler Typ auf HFSC, Bandbreite auf 500 MBit/s stellen und speichern. Dann auf Add new Queue, aktivieren,  bei Service Curve die Bandbreite auf 100 MBit/s stellen. Dann gibt es ja noch minimale Bandbreite für die Queue - Echtzeit - m1 - d - m2. Was soll man da machen? Oder muss man davor erst die WAN Verbindung auf 500MBit/s stellen? Wie soll man das dann mit der Firewall verknüpfen?

Hmm.. dann hoffe ich mal es hat noch jemand eine Idee.

Habe es grade mit dem LoadBalancer probiert, aber wenig erfolgreich (oder ich bin einfach nur zu blöd)

Der hat sich tatsächlich auf Port 2 geändert…

Nun läuft er wieder auf 443, wenn ich jetzt noch wüsste wie es dazu kam.

Vielen Dank.

Hallo

ok - schaue ich mir an …

Eigentlich würde ich viel lieber Load Balancing einsetzten - aber hic habe hier ein Verhalten das ich absolut NICHT verstehe - ich mache dazu mal einen neuen Post auf da das mit dem hier nix zu tun hat - evtl kannst du mal rein schauen ...

CU
GTR

Mit CloudPBX leider nicht. Mir bangt auch vor dem Tag dass unser ISDN Anlagenanschluß wegfällt (Ende des Monats :() Da wird auch gerade schwer gebastelt mit dem SIP Provider der den neuen Trunk liefern soll grusel

Hi,

in der Tat ist es so, dass ich die Auth Methode "SSL/TLS+User Auth" verwende und für jeden User ein eigenes Zertifikat verwende.
Da ich nur 4 User habe werde ich das so machen wie du gesagt hast.

War ja eh nur eine Bequemlichkeits-Frage :)

Super Danke!

Servus,
Entschuldigung für die späte Antwort. Der Ton war weg. Aktuell bleiben die Gespräche bestehen. Ich stelle mal den Firewall Opt. Mode wieder um und lasse NAT-alive auf 30Sek. Vielleicht genügt das ja.

Werde berichten.

Super, es funktioniert
Danke

und neben dem VPN-Gateway noch das WAN-Gateway

:o Huh? Nein du kannst beim OpenVPN Client als Interface auch die LB-Routing Gruppe auswählen und nicht nur ein statisches Interface. Wenn dann ein IF der LB Gruppe down ist, wird logischerweise das andere für den Verbindungsaufbau genutzt und die Verbindung wiederhergestellt. Das hat mit deinem sonstigen Routing was du tust erstmal nicht wirklich was zu tun.

Hallo

au weier ich hatte mich total veramt.

der OpenVPN access server war mein Fehler wenn ich die Netze mit Peer to Peer verbinde geht alles wie ich es haben möchte.

Danke du hast mich aber auf den richtigen weg gebracht.

Mfg

Heribert

@Grimson:

pfSense ist eine Firewall und kein Server, warum sollte da also ein Superserver Prozess laufen. Außerdem reicht ein Thread: https://forum.pfsense.org/index.php?topic=111517.msg786194#msg786194

https://redmine.pfsense.org/issues/6308

Hi Grimson,
sorry für das crosspost, aber erfahrungsgemäß gibt es viele englischsprachige Menschen, die kein Deutsch sprechen :-(  Deren Wissen hätte ich auch gerne angezapft.
Warum ich den xinetd brauche habe ich ja geschrieben: Monitoring mit check_mk (einem Nagios-Ableger). Dafür gab es früher sogar ein pfsense-Modul - jetzt leider nicht mehr :-((
Aus deinem link zu bug#6308 werde ich auch nicht schlau. Dort läuft ja offensichtlich der xinetd und schreibt seine Meldungen ins log. Wie soll mir das helfen?

TIA, Karl

Ja, um das Routing brauchst du dich da nicht zu kümmern.
Doch musst du auf einem weiteren Interface selbst Firewall-Regeln hinzufügen, die den gewünschten Traffic erlauben. Am LAN ist ja ab Installation bereits eine Regel gesetzt, die alles erlaubt.

Kein Problem, an den LB hätte ich an der Stelle als Proxy Ersatz aber auch denken können :D

Wenn System neu aufgesetzt:

DNS Resolver aufrufen Unten in der Rubrik Host Override einen Eintrag machen für (bspw. xyz.dyndns.org)
– Host: xyz
-- Domain: dyndns.org
-- IP: deine_interne_IP_des_webservers Speichern DNS Resolver sicherheitshalber neu starten

Am PC den DNS Namen testen (Eingabeaufforderung, Powershell, whatever): nslookup xyz.dyndns.org

Sollte nun auf die interne Adresse, nicht auf die externe Adresse zeigen. Wenn nicht nutzt dein entsprechender PC nicht die pfSense als DNS Server, dann wird das ohne NAT Reflection schwierig.

Profit.

@Parsec: das war die Methode über link local unicast die mir noch im Kopf herumgeschwirrt ist - danke dafür :)

@pfadmin: na die Weisheit hab ich auch nicht gefressen :P

Ansonsten geht eben Hetzner bei der Vergabe nicht davon aus, dass du da viele kleine Maschinen laufen lässt, sondern dass du eben eine dicke hast und dafür ist das v6 Prefix auch genug. Bzw. wird da eher nicht davon ausgegangen, dass du da ne Router VM vornedranbastelst. Daher sind die auch extrem zickig, das "schön" zu machen mit ordentlichen Netzen auf jeder Seite. Daher kann man das /64 entweder auf dem WAN auflegen oder ins LAN schieben lassen - indem man wie Parsec eben den link-local für das Routing mit Hetzner nutzt und das v6 Netz dann auf dem LAN konfiguriert.

Bei v6 gibt es (für 99% der Fälle) keine extern/intern/privat/öffentlich Diskussion mehr. Alle Adressen die vergeben werden sind erstmal weltweit erreichbar außer es wird dediziert was anderes gesagt. Punkt. Es gibt kein NAT oder sonstiges Geschwurbel. Auf jedem Interface das v6 fähig ist, liegt ein v6 Netz auf und es wird ganz normal und sauber geroutet und sonst nix. Keine NAT Krücken, keine Forwardings, Mappings, Source- oder Destination NAT, Redirects oder sonstwas. Clean & Simple.

Ah my bad, ich meinte nicht den Ping, sondern die Response Zeit bei den DNS Fragen. Wenn ich da in der Diagnostic Seite schaue, waren die 9er ziemlich lahm ggü der Antwortzeit von den 8ern oder bspw. OpenDNS. Aber vielleicht war das auch zum Launch nur so. :)

Damit war unglücklich formuliert gemeint, dass das zweite WAN bei zugeteiltem Gateway via DHCP auch dieses als "sein Upstream Gateway" nimmt, wenn es Daten vom LAN o.ä. bekommt. Das kommt dadurch, dass das GW fest auf das physische/logische Interface gebunden wird. Zudem gibt es dann automatisch erstellte Reply-To Regeln, die Traffic von diesem Interface auch wieder über dieses zurückliefern :)

Aber ja "default" an der Stelle war doof ausgedrückt.