Update:

Ich habe heute weitere Tests mit ältern Versionen durchgeführt:

2.2.3 -> Keine Verbesserung der Bandbreite 2.2.2 -> Keine Verbesserung der Bandbreite 2.2.1 -> Keine Verbesserung der Bandbreite 2.2 -> Keine Verbesserung der Bandbreite 2.1.5 -> Keine Verbesserung der Bandbreite

Dann habe ich geupdatet auf die 2.2.5 Version, die seit heute released ist.
Auch hier ist keine Verbesserung zu verbuchen…

Öhm ich könnte gerade blind sein, aber auf dem WAN und dem LAN liegt das gleiche IPv4 Subnetz an? Das gibt zu nahezu 100% Probleme. Was versuchst du denn da zu bauen?

trotz mehrmaliger Änderung der DNS Server in pfSense wurden diese nicht übernommen, bis ich das Kabel einmal gezogen und wieder neu verbunden hatte (auch nicht beim Neustart von pfSense)…

Das würde nicht überraschen. Du startest zwar den DNS Forwarder durch, aber das Gerät selbst holt sich erst nach Ablauf des DHCP Leases neue Daten vom DHCP Server. Wenn du also dort was verändert hast um den MAC bspw. direkt einen DNS Server zu pushen, dann müsstest du schon manuell das Lease neu holen. (siehe unter Windows das übliche ipconfig /renew)

Muss allerdings gestehen, dass ich das Problem mit dem "Advanced" nicht ganz verstehe, bzw. warum du den Advanced Block selbst schreibst und nicht den Override Block in der GUI verwendest? Ansonsten kann man das ja recht einfach manuell testen in dem man von einem Client gegen den Forwarder der pfSense einen nslookup/dig macht und prüft, was als Ergebnis zurückkommt. Ich vermute da irgendwie einen Käfer in der Config ;) Aber das ist schwer zu debuggen wenn mans nicht selbst nachbaut :)

Grüße

@PiBa:

If that doesnt help change the "Http check method" to 'GET' instead of the default 'OPTIONS' method.

That did the job. Now it works.

THX

bakunin

@JeGr:

OpenVPN Server meinst du mit Clients to Server? (also keinen Site2Site Tunnel)

Genau Client to Server
und je nachdem wie umfangreich das sein soll natürlich auch Site2Site

@viragomann
Danke für deinen Hinweis, es war eigentlich ganz simpel.. es hatte sich die CIDR verändert gehabt aber ich hatte es beim Outbound nicht angepasst gehabt.
das Trace rt funktioniert.
Leider hapert es an der DNS auflösung, was könnte ich da verstellt haben ?
Irgendwann muss ich den DNS Resolver ausgeschaltet haben! Jetzt gehts….
:/
Hab mal den aktuellen trace angehängt ( natürlich etwas geschwärzt)  ;)
....es Funktioniert jetzt!!
Vielen Dank an alle die mir geholfen haben !!


Was mir auffällt:

Vorab: Erstelle ein Port Alias mit beliebigem Namen (bspw. P_web_default) und füge dort die Ports 80 & 443 ein.

Protokoll: TCP only, UDP hat bei HTTP/S nichts zu suchen ;)

Source: hat leer zu sein. also Type: any, hier NICHTS einfügen, sonst begrenzt du den Punkt, wer dir Daten senden darf (aka das Internet). Da das bei dir auf dem Telekom_VDSL net steht wird das so ziemlich niemand sein…

Source Port: hat leer zu sein, Verkehr VOM Client kommt nicht von Port 80/443, sondern von random HighPorts > 1024!

Destination: hier müsste die IP der Firewall hin, also wahrscheinlich die VDSL_address, also die Adresse die deine Firewall via VDSL im Internet hat.

Dest. Port: Hier dein vorher erstelltes Port Aliase eingeben (rote Felder unterstützen Auto-Completion)

Redirect Target/Port: Da muss dein Server und seine IP rein. Der Target Port sollte mit dem Alias oben übereinstimmen.

Reflection: wirst du nur brauchen, wenn du vom LAN aus mit der externen IP dich auf den Server verbinden willst (wegen DNS oder derlei), Normalfall aber erstmal nicht.

Filter Rule: Stelle das lieber auf add associated filter rule und gebe bei Description weiter oben einen sinnvollen Namen für diese Regel ein (allow HTTP to Server1 via NAT) und dann speicher das Ganze.

Was mit "add associated rule" passiert ist, dass dir jetzt bei Firewall/Rules eine mit Link/Ketten Symbol neu erstellte Regel ins Auge sticht, die den Verkehr, der vorher per NAT umgewandelt wird durchlässt. Eine eigene Regel zu haben ist aber einfacher als bei NAT "pass" auszuwählen und macht es einfacher, bei größeren Regelsets durchzusteigen, WARUM bspw. überhaupt was funktioniert oder nicht.

Editiere jetzt die neue verlinkte Regel und du siehst, dass der meiste Kram ausgegraut ist (da sie an der NAT Regel hängt). Du kannst aber bei "Log" den Haken bei Log packets reinmachen. Dann wirst du Verbindungsversuche via dieser Regel mitbekommen und kannst prüfen ob es klappt.

Speichern, Apply, testen.

Have fun

Da kann ich dir durchaus Recht geben :) Aber danke dass dus nochmal hier postest, die Posts aus dem deutschen Bereich landen ja recht zügig in Google, so wirds dann vielleicht auch dem ein oder anderen User helfen können :)

@mike Das ist auch keine Kunst ;) Aber im Ernst, die APU benutzt die Unterseite des Gehäuses als passive Abwärmeableitung, deshalb wird der Deckel auch gut wärmer als bei der alten ALIX.

Sieht man hier ganz schön: http://pcengines.ch/apucool.htm

Darum nicht wundern wenn die ganze Kiste schon einiges wärmer wird.

@JeGr:

pfSense nutzt normalerweise die WAN IP. Bei DynDNS Anbietern und wenn die WAN IP aus einem privaten Netzsegment stammt, wird normalerweise eine externe Abfrage nach checkip.dyndns.org getriggert und dieser Wert dann übernommen. Funktioniert bei mir - ebenfalls mit afraid.org - auch problemlos. Da muss also nichts extra gebaut werden.

Das kenne ich auch so. Aber bei einem Kunden wurde immer die IP des LINUX Router angegeben.

Hab jetzt ein Script von afraid.org modifiziert. Damit geht es dann mit cron…

Wget wird hier ersetzt, sowie anderer Port.

################################

#!/bin/sh
#FreeDNS updater script

UPDATEURL="https://freedns.afraid.org/dynamic/update.php?your-key"
DOMAIN="your.subdomain.tld"

registered=$(host $DOMAIN | sed s/[^0-9.]//g | sed 's/..//')

current=$(fetch -q -o - http://checkip.dyndns.org:8245|sed s/[^0-9.]//g)
      [ "$current" != "$registered" ] && {                         
          fetch -q -o /dev/null $UPDATEURL
          echo "DNS updated on:"; date >> dnslog.txt

}

#####################################################################

Hat leider nichts gebracht!

OK das macht es klarer. Dann würde ich das auch so sehen wie Virago und die pfsense Adresse in einem Alias mit aufnehmen, das einfach erlaubt wird. dann klappen auch Updates etc. sauber.

@tgrafen1:

Also die Clients surfen über einen Proxy (squid guard).

Was spricht dagegen, dass Du im SquidGuard eben diese URL *.TeamViewer.com einträgst, um sie freizugeben?

Wo steuerst Du auf den Clients, was über den Squid läuft und was nicht?
Kann es sein, dass sich der TeamViewer immer die System-Settings greift und daher sowieso am Squid strandet?

Danke für deinen Support. Kannst du mir noch sagen wo man sehen kann ob man nanobsd installiert hat?  Und hat das normale Bsd höhere Hardware Anforderungen?

Es gibt kein normales vs nanobsd. NanoBSD ist die interne Bezeichnung für die Embedded Variante, die für den Einsatz bspw. auf ALIX oder APUs gedacht ist, die das Image auf CF/SD Karten schreiben. Da die gern "ausleiern" (also ein mitunter schlechtes Wear Level haben und bei häufigem Schreiben schneller kaputt gehen) ist nanoBSD so gebaut, dass so wenig wie möglich Daten geschrieben werden, und wenn dann flüchtig auf eine Ramdisk.

Der installierte Status wird im Dashboard angezeigt unter "System Information" und "Platform".

https://forum.pfsense.org/index.php?topic=70378.0

Hier wurde der gleiche Fehler schon behandelt -> "typischerweise das Anzeichen einer sterbenden Festplatte, tauschen und hinterher bitte den Browsercache leeren, dann verschwindet auch der Fehler".

Siehe auch:

https://doc.pfsense.org/index.php/Filesystem_Full_/_Out_of_Inode_Errors
https://doc.pfsense.org/index.php/DMA_and_LBA_Errors

Ich würde ggf. auch die Disks ausbauen und an einem anderen Rechner mal ordentlich durchtesten. Wenn die Kiste selbst schon 6 Jahre alt ist, wäre es nicht unüblich, dass sich die Platten nach dem Alter verabschieden.

Ich habe wieder ein Vollimage installiert, hatte aber auch schonmal ein nano auf SD welches flott lief.

Da mag ich dich korrigieren, aber das ist vom Screenshot gesehen definitiv ein NanoBSD / CF Installation. Eine Vollinstallation auf HDD hat keinen Mountpoint /cf definiert. Weder unter 2.1 noch unter 2.2 habe ich hier Kisten, die ein /cf haben, wenn kein NanoBSD drauf läuft.

Damit wirst du nicht um eine Neuinstallation herumkommen, dieses Mal dann aber mit einer vollen Installation.