Sprich nach Update auf 2.4.2 ist der Sync-Portal-Bug weg (den du wohl auch hattest)? :)

danke für deine antwort, sonst klappt alles aus meinem lan.
danke noch für den tipp, ist warscheinlich passiert bei testen

Also ich glaube die Lösung für die langen Verbindungszeiten gefunden zu haben. Kann es sein, dass Vodafone und Unitymedia sich nicht mögen und untereinander schlechtes Routing haben?

Jedenfalls glaube ich, dass es daran gelegen hat. Habe einige Traceroutes aus dem Mobilfunknetz zu meinem heimischen Anschluss gemacht und es dauerte halt etwas länger bzw. gab an 2 Stellen diese langen Timeouts.
Danach habe ich Traceroute zur öffentlichen IP eines in der pfSense eingerichteten OpenVPN Clients gemacht und siehe da - alles lief schnell und in 1-2 Hops weniger durch.

So habe ich auf der Serverseite des VPN Tunnels eine Portweiterleitung und als WAN meines pfSense VPN Servers eben die o.g. öffentliche IP eingerichtet. Gleichzeitig den server-poll-timeout auf 3(!) Sekunden runtergesetzt. Was soll ich sagen? Läuft top und nur absolut selten brauchen die Clients länger als 3 Sekunden, noch deutlich seltener als beim 5-sekündigen Verbindungsaufbau zu meiner WAN IP.

@kebeil:

Edit:
Ich habe jetzt vom Log die Easyrule gesetzt. Damit gehts. Aber was macht diese Regel anders als meine any any???

Um das beurteilen zu können, müsste man dein Regel-Set von WAN und Floating kennen.
Vielleicht der Port, vielleicht das Protokoll, vielleicht die Reihenfolge?  ???

Servus,

nein das hab ich noch nicht Probiert aber wie gesagt ich hab auch ein Problem mit legacy mit 2.4.1 …
Ich blein jetzt ertmal auf 2.3.5 bis nächstes Jahr in nehme mich dann nochmal der Sache an. Verückt ist auch das ich 2 gleiche Server im betrieb habe also absolut identisch und beim zweiten gab es keine probleme beim update auf 2.4.1.

Ist ein bekannter Bug in 2.4.1, einfach auf 2.4.2 updaten.

https://www.netgate.com/blog/pfsense-2-4-2-release-now-available.html

Danke für deinen Tipp, blex.
Jedoch muss doch dies dann im SquidProxy definiert werden, oder woher weiss er denn welche IP er verlässt?

Gruss

Scheint heute ein Störung bei 1und1 zu sein

Hier müsstest du mal schauen was nicht geht.
Normalerweise hat das iPad eine ip aus einem VPN Netz.

Jetzt weis dc1 wie er da hin kommt da der Tunnel bei ihm endet. Dc2 weis es nicht. Er wird den Traffic vom iPad an das default fw. geben was wohl nicht dc1 sein dürfte. Somit kommt es nicht an.

Diese These zu testen ist einfach. Schau auf dc2 mit wireshark oder ähnlichen Tools nach ob Pakete ankommen und welche Absender ip diese Pakete haben. Siehst du Pakete vom iPad Bingo.
Die Lösung ist dann auf dem default Gw eine Route zu setzen die zu dc1 zeigt. Dies führt aber zu asynchronem routing

Ist das Setup aber anders z.b. iPad <- VPN -> pfSense < - Network -> dc1 hast du ein anderes zenario.
Dann wäre von Interesse wie du das von auf der pfsense konfiguriert hast. Wenn du hier ein paar Details schreibst können wir dir sicher weiterhelfen.

Gruß blex

@ JeGr

Deine Aussage "kaputtkonfiguriert" macht mich etwas stutzig.

Meine Konfiguration ist folgende.

pfSense Interface Assignment
NIC 1 als WAN
NIC 2 not assigned
VLAN10 auf NIC 2 (IP: 192.168.10.0/24)
VLAN20 auf NIC 2 (IP: 192.168.20.0/24)

pfSense Firewall VLAN10 (von oben nach unten)
1. Allow IPv4 * VLAN10 net Port * –> VLAN10 address Port *, Gateway *
2. Block IPv4 * VLAN10 net Port * --> VLAN20 net Port *, Gateway *
3. Allow IPv4 * VLAN10 net Port * --> * Port *, Gateway * (also auf any)

pfSense Firewall VLAN20
gleiche Konfiguration, wie VLAN10 nur mit VLAN20

24Port Switch
Port 1: Tagged VLAN10 und VLAN20 (hier ist pfSense angeschlossen) / PVID: 10
Port 2-10: Untagged VLAN10 (hier sind Rechner angeschlossen) / PVID: 10
Port 11-15: Untagged VLAN20 (hier sind Rechner angeschlossen) / PVID: 20
Port 16: Untagged VLAN20 (hier ist der Access Point angeschlossen) / PVID: 20
Port 17-23: diese Ports sind deaktiviert, gehören aber dem Default VLAN 1 an (hier sind logischerweise keine Geräte angeschlossen) / PVID: 1
Port 24: Untagged Default VLAN 1 (hier stecke ich einen Rechner an, wenn ich den Switch konfigurieren möchte) / PVID: 1

Die Port Security aller Ports steht auf 1-24, ist somit deaktiviert.

Die Konfigurationen von pfSense und dem Switch sollten doch so richtig sein, oder?

Vielen Dank nochmal,
KHR

nur für meine Weiterbildung. Warum war es nicht möglich in der VMWware über die LAN Schnittstelle zuzugreifen?

Ich würde denoch empfehlen den Zugiff auf die pfS über WAN (wenn überhaupt) über eine einzelne Firewall regel zu erlauben und dann die Firewall wieder zu aktivieren.

Gruß

Hagen

My Friends

So nun hier die Auflösung:

APU3B4 mit PFsense Version 2.4.1 und upgrade BIOS auf (apu3_v4.0.11.rom). Temperatur bei 61.5.  ;D

Cheers Laura

Vielen Dank an @JeGr, ich habe es endlich sauber gelöst bekommen.

Super! Vielen Dank auch für die Rückmeldung, freut mich dass es geklappt hat :D

OK. Man kommt auch im bridge-Modus auf den Vigor, sofern man denn ohne VLAN-Tag darauf zugreift.
Besten Dank nochmals.

Hi, das liegt eher am Vectoring, da hier das Ganze Bündel in die Berechnung einbezogen wird. Der BNG legt dann deinen Tarif fest. Deine Werte sind aber nicht optimal, teste bitte die höchste Modemversion, M4 oder M8. Dann sollte in beiden Richtungen Fast stehen.

Gruß
pfadmin

Danke fürs aktualisieren, aber das ist sehr schön zu hören :)

@Tesla:

WAN auf ein /25 (.1-.126) Netz, VLAN Kinder auf ein /26 (.193-254) Netz, Outbound NAT auf 192.168.138.192/26, DHCP VLAN Kinder auf .201-.250, IF VLAN Kinder auf .200 !

So hatte ich das allerdings gar nicht gesagt/gemeint. Meine Aussage war/ist: Wenn die pfSense hinter der Fritzbox NAT macht, erscheint sie beim ersten Kontakt der pfSense bzw. eines Clients dahinter in den Einstellungen der Fritzbox. Legt man jetzt für ein paar Adressen intern ein 1:1 NAT der pfSense ins FB Netz an (OHNE das FB Netz /24 zu verändern), dann erscheint die pfSense plötzlich "mehrfach" weil die FB Traffic von verschiedenen IPs von der pfSense bekommt. Einmal bspw. als .2 wenn das ihre IP ist und dann noch als .200 bspw. wenn man das als 1:1 NAT für eine Test IP genutzt hat. Da der Eintrag in der Fritte jetzt erscheint/aufgetaucht ist, kann man den dann auch entsprechend zuordnen, dass man auf der IP irgendwelche Filter/Kindersicherungen aktivieren will.

Das war gemeint - ganz ohne Bridge :) Die Unterscheidung erfolgt lediglich anhand der anderen NAT IP. Normaler Traffic geht über die default NAT IP raus, bestimmte Geräte werden 1:1 auf andere IPs geNATtet und damit anders behandelt. Das könnten theoretisch auch mehrere Clients sein, die man abgehend auf eine andere IP mappt und damit dann bspw. mit dem Kinderfilter bespaßt.