Hi flachfalke, nur mal noch so als Hinweis zu Samba und deren config… Wenn Du die smb.conf händisch bearbeitest, weil da z.B. im GUI des FreeNAS auf Grund von Versions-Unterschieden keine Einstellungsmöglichkeiten sind und anschließen den Samba-Server neu startest ist das kein Problem. Dann solltest Du aber nicht mehr über den GUI Änderungen vornehmen, der überschreibt sonst Deine händische Config. Gruß orcape

@sh0gun: Ich habe jetzt in /boot/boot.loader.local mal kern.ipc.nmbclusters=7006 und gesetzt und mit sysctl ins laufende System eingetragen. Das entspricht dem 1,5fachen Wert, welcher voreingestellt war. Das ist ja interessant. Ich habe noch eine pfSense 2.1.5 auf einem 2D13 laufen und hier ist der Defaultwert 8512. Sollte das in 2.2 reduziert worden sein? Für dieselbe Hardware? Stand der Wert bei dir in der loader.conf? Bei mir steht da nämlich kern.ipc.nmbclusters="0" drinnen. Der tatsächliche max. Wert könnte sich also aufgrund der übrigen Konfiguration ergeben.

Hallo, danke für die Hilfe. Also, der FTP Client hat nur aktives FTP unterstüzt. Zwischenzeitlich konnte aber eine andere Lösung über HTTPs realisiert werden. Gruß, Valle

Hallo Andreas Mit IPv6 scheint mir der Aufwand in diesem Bereich einiges höher. das hängt immer stark von der Systemumgebung ab. Wenn das alles ordentlich automatisiert oder / und dokumentiert ist, braucht es da kein DNS als Nachschlagewerk ;) auch wenn es praktisch ist. Rechnername in ein Tool wie bspw. GLPI zusammen mit Hardware Daten und Leasing Terminen o.ä. eintragen und schon fluppt das auch so ordentlich :) Ist aufwändig, sicher, aber lässt sich mit der Zeit auch gut automatisieren (bspw. kann man in GLPI über Tools wie OCS Inventory und dessen Clients automatisiert die Hardware und Software des Clients scannen und eintragen lassen, dann hat man auch gleich den richtigen Stand mit Seriennummern etc.). Das aber nur als Tipp am Rande :) Ansonsten ist bei v6 wieder die Frage, was man genau möchte. Natürlich kann man da alte Dinge beibehalten (siehe DynDNS oder AD Integration), kann in diesem Zuge aber auch versuchen manchen alten Zopf loszuwerden und neu/sauber zu machen. Risiko, aber auch Chance :) Grüße Jens

Die Anleitung ist der Hammer !  ;D Gruss Auric

@jahlives: re1.840 –> LAN re1.999 --> WLAN Entschuldige meine Ignoranz … was sind denn re1.840 und re1.999 für Interfaces? Sind das VLANs auf einem re1 oder verschiedene physikalische Adapter oder ... ? Eine solche Benennung ist mir bislang noch nicht untergekommen.

Ja Philipp, kann sein das ich das auch schon so erlebt habe, siehe hier:https://forum.pfsense.org/index.php?topic=58700.msg482763#msg482763 Da steht auch drin wie man diesen Fehler abstellt und weitermacht. Gelöst ist es aber nicht, hierzu ist der Beitrag von marcelloc hier recht aussagekräftig: https://forum.pfsense.org/index.php?topic=87782.msg483244#msg483244 Also mein Fazit ist das es mit Proxy und sso bei pfsense momentan ganz schlecht aussieht. Würd mich aber sehr freuen wenn jemand meinem Fazit widerspricht! Gruß Alex

Und hier ist die Lösung für das Problem: https://forum.pfsense.org/index.php?topic=73988.msg487813#msg487813

Wir können das Thema schließen. Der endgültige Praxistest steht zwar noch aus aber die ersten Tests waren alle erfolgreich. Sowohl Multiwan auf Basis von bestimmten Rules (Nutzung von beiden Leitungen auf Portbasis) als auch die Traffic Shaping Geschichte. Danke an flix87 für seine Unterstützung.

Hier meine Switch Config: sh running-config Building configuration... Current configuration : 1418 bytes ! version 12.1 no service pad service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname Peter ! ! ip subnet-zero ! ip ssh time-out 120 ip ssh authentication-retries 3 ! spanning-tree mode pvst no spanning-tree optimize bpdu transmission spanning-tree extend system-id ! ! ! ! interface FastEthernet0/1 ! interface FastEthernet0/2 switchport access vlan 10 switchport mode access ! interface FastEthernet0/3 switchport access vlan 10 switchport mode access ! interface FastEthernet0/4 switchport access vlan 10 switchport mode access ! interface FastEthernet0/5 switchport access vlan 10 switchport mode access ! interface FastEthernet0/6 switchport access vlan 20 switchport mode access ! interface FastEthernet0/7 switchport access vlan 20 switchport mode access ! interface FastEthernet0/8 switchport access vlan 20 switchport mode access ! interface FastEthernet0/9 switchport access vlan 20 switchport mode access ! interface FastEthernet0/10 ! interface FastEthernet0/11 switchport mode trunk ! interface FastEthernet0/12 switchport mode trunk ! interface Vlan1 ip address 192.168.1.2 255.255.255.0 no ip route-cache ! interface Vlan10 no ip address no ip route-cache shutdown ! interface Vlan20 ip address 192.168.20.2 255.255.255.0 no ip route-cache shutdown ! ip http server ! line con 0 line vty 0 4 login line vty 5 15 login ! ! end Eine Fritz!box (192.168.178.1) ist an WAN mit Static IPv4 192.168.178.254 angeschlossen. IPv4 Upstream Gateway hab ich 192.168.178.1 eingetragen. Ich hab den pfSense an den Port 12 angeschlossen und den Accesspoint an Port 11. Ein Testrechner an Port 1 erhält vom DHCP die IP 192.168.1.x Das Internet funktioniert, alles top. Kann die FritzBox auf 192.168.178.1 nicht erreichen, gut. Ich kann die pfSense Oberfläche erreichen. Ein Testrechner an Port 4 erhält vom DHCP die IP 192.168.10.x Internet funktioniert nicht, kann auch den pfSense auf 192.168.10.1 nicht erreichen. Der Accesspoint ist in VLAN10 und VLAN20 erreichbar 192.168.10.3 und 192.168.20.3, kann auch von einem Client der am Switch hängt darauf zugreifen. Muss ich bei den VLAN Interfaces noch ein Gateway eintragen, damit das Internet funktioniert, oder sind noch weitere Firewallregeln erforderlich?

Kann ich bestätigen mit der Anpassung von NAT läuft Telekom Voip mit einem Gigaset dx800a ohne Probleme

Der Thread ist zwar schon ein wenig älter, aber steht ja noch nicht auf Gelöst: So eine Konfig betreibe ich auch: pfsense 1: xx.xx.xx.2 pfsense 2: xx.xx.xx.3 WAN-CARP: xx.xx.xx.4 die xx.xx.xx.5 brauchst Du nicht. Die Regel Protokoll IPv4/UDP SOURCE any Port any -> DEST CARP_IP5  Port 1194 ACCEPT ist ok, nur eben auf die IP xx.xx.xx.4. Bei mir ist das zwar TCP/443, weil wir auch aus Proxy-Netzen drankommen müssen, aber das spielt in diesem Kontext ja keine Rolle. Damit OpenVPN auf die virtuelle IP hört, musst Du bei 'Advanced configuration' den Eintrag local xx.xx.xx.4 machen. Dann läuft das.

Habe herausgefunden dass der TP-LINK TL-WR710N  das auch kann  :)

Da ich da auch festgehangen habe mit dem Vigor 130: Folgende Einstellungen waren nötig: 1. Unter "Internet Access>>PPPoE/PPPoA" wurde der PPPoE/PPPoA Client disabled 2. Unter "Internet Access>>MPoA / Static or dynamic IP" muss man a) MPoA (RFC1483/2684) aktivieren b) VPI=1 und VCI=32 setzen c) Bridge Mode einschalten

Nein, es sind keine Device-Ids in der fstab. Daher ist das Skript ja auch nicht erforderlich. Es arbeitet ja nur mit Device-Ids. Ich habe den Upgrade-Guide nochmal gelesen: ATA disks are labeled as /dev/adaX rather than /dev/adX. […] For a full install, running /usr/local/sbin/ufslabels.sh before the upgrade will convert /etc/fstab to UFS labels rather than disk device names bypassing any device name issues that could arise due to the switch. Solange also keine Device-Ids in der fstab stehen, ist das gar kein Problem. Und Du hast recht: Der Upgrade-Guide ist da nicht ausreichend genau. -flo-