Hi,

am Ende deines Posts fehlt der Dank, dass jemand bis dahin gelesen hat. Das verdient doch auch schon Anerkennung.  ;)

@Jorval:

A Kein Auto NAT
also hab ich einfach eine Route an der 2.Sense im Branch1 ins direkt ins Internet gesetzt. und die Clients die das dürfen sollen in einen Alias gepackt und eine Regel erstellt die den Clients diese Netze erlauben sollen. Klappte aber nicht. Ich bin nicht gleich darauf gekommen einen Blick ins Firewall -> NAT zu werfen aber da war keine Regel automatisch erstellt worden. Sollte die Sense das nicht eigentlich tun? Oder gibt es eine Einstellung die vorher dafür aktiviert werden muss? Ich habe jedenfalls auf Hybrid umgestellt und das NAT dann von Hand eingerichtet, Ich bin mir aber sicher das die Große im Hauptbetrieb das allein gemacht hat die steht auch auf Automatisch und hat Einträge generiert.

Automatisch erstellt werden nur Regeln fürs WAN, nicht für andere Interfaces. Da ist das auch nur selten gewollt, und Wünsche von den Augen des Admin abzulesen, gibt es erst im übernächsten großen Release.  ;)

@Jorval:

B Mal gilt die Regel mal nicht.
Hat mit der gleichen Sache zu tun. Die oben erwähnte Regel funktionierte Tadellos. Am nächsten Tag ein aufgeregter User das Programm geht nicht?! Regel Überprüft, alles richtig meiner Meinung nach.Das Log zeigt mir aber Blocks an wenn der User das Programm startet. Die Pakete landen in der default ipv4 deny rule? Regel einmal anfassen, speichern Apply und Sie funktioniert wieder. Auf nachfrage im IRC antwortete jemand das dies passieren könnte wenn ein FIN Packet für eine Bereits terminierte Verbindung ankommt (z.b. wegen packetloss) Ich verstehe aber nicht warum das gleich die ganze Regel außer kraft setzen sollte?

Was für Flags habe die gelockten Pakete im Log?
pfSense loggt nur die ersten Pakete einer Verbindung, also bei ordnungsgemäßer TCP Verbindung nur die SYN Pakete. Andere TCP Pakete stehen nur im Log, wenn die Verbindung bereits geschlossen wurde oder nie aufgebaut wurde.
Könnte damit in Zusammenhang stehen:
https://doc.pfsense.org/index.php/Why_do_my_logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection

Falls die Pakete aber in Ordnung sind, kann es sein, dass die VPN Verbindung unterbrochen wurde, ehe das Problem auftritt? Check mal das Log danach.

@Jorval:

C Eigentlich wollte ich den kompletten Verkehr durch den Tunnel an den Hauptstandort haben wie es auch bei der abgelösten TKom Verbindung der Fall war. Das im OVPN Server auf der HauptbetriebsSense eingetragene push "route 0.0.0.0/0" hat er auch min. 1 mal gezogen, das habe ich beim Diagnostic -> Routes gesehen, aber dann war ich so mit Problem B beschäftigt und hatte einiges geändert das ich das erst einmal nicht weiter verfolgt habe. Jetzt steht das Default Gw aber nur noch ins inet. Das ist für mich generell auch ok da wir vllt. einmal Proxy vor Ort nachrüsten möchten, aber auch hier verstehe ich nicht ganz warum er die Anweisung dropt. Vielleicht hat jemand einen kleinen schubs ins richtige log für mich ?

Warum das nicht geht, kann ich dir auch nicht sagen, aber Gegenfrage:
Warum arbeitest du bei einer dauerhaften Verbindung überhaupt mit push route??
Die Netze, die über die VPN geroutet werden sollen, kannst du ja in der Client Konfiguration, nehme an das ist Branch 1, eintragen (Remote Networks), bzw. ebenso am Server. Das hat faktisch den gleichen Effekt, als ob du es in die Routingtabelle einträgst und funktioniert immer (wenn die Verbindung steht).
Andere Routen sind für diese Netze ohnehin nicht vorgesehen, denke ich.

@Jorval:

D Kein ssh durch den Tunnel.
An Branch1 geht auf Seite der Benutzer soweit alles, Die User machen RDP Verbindungen ins RZ das RZ schickt Druckaufträge in Branch1 die Kollegen kommen via Browser und Proxy ins Internet und selbst Seiten die nochmal hinter einem NAT am Hauptstandort liegen funktionieren ohne Probleme.
Ich kann allerdings von Standort Branch2 wo nun die IT sitzt keine ssh Verbindung mehr zum Debian Server an Standort Branch1 aufbauen. Manchmal kommt nach langer wartezeit wenigstens die Passwort abfrage. ping und tracepath laufen den korrekten weg. Ich kann weder den xenserver 192.168.1.2 noch den debian 192.168.1.3 connecten. ssh zur Sense 192.168.1.1 funktioniert hingegen perfekt (zu meinem Glück)
Vom Hauptbetrieb das selbe Spiel die Sense in Branch1 ist erreichbar die beiden anderen (Xen,Deb) leider nicht.
Das OVPN hat ja ein Telekom VPN abgelöst.

Die pfSense erreichst du per ssh über den VPN Tunnel? Wenn ja, stimmt die Threadüberschrift nicht und die Ursache ist möglicherweise auch nicht beim Tunnel zu suchen.

Gleichzeitig mit der Umstellung von der früheren Lösung habt ihr die neue pfSense auch virtualisiert. Vielleicht ein XEN Problem? Schau dir mal diesen Thread an und prüfe die Empfehlungen:
https://forum.pfsense.org/index.php?topic=88467.0

Grüße

@tripelm:

Hallo zusammen,

ich hoffe das mir hier jemand weiterhelfen kann.

zuerst einmal meine captive portal page:

<title>Kunde</title>

-->

|
                       Willkommen im Gast WLAN von Kunde.
                    |
|
                       Kundenpdf
                    |
|
                       Kundenpdf
                    |
|
                       Kundenpdf
                    |
|
                       
                        Durch drücken des Bestätigen Buttons akzeptieren Sie unsere AGB.
                       
                       
                    |

Nun besteht das Phänomen das wenn der Kunde auf den Button klickt nichts passiert. Die Willkommens Seite bleibt
weiterhin geöffnet und sonst geschieht nichts.

woran könnte das liegen?

Danke im Voraus

Also so auf die schnelle würd ich sagen, fehlt bei Dir:

Wobei XXXX für den Namen des Captive portals steht

na am download manger solls nicht scheitern

Selbst den kann man tunen auf mehr als die normalen bzw. üblichen 15 simultanen Kanäle
hoch setzen.

Und ein Cache Proxy hätte ja auch mit im Spiel sein können.

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".