FreeNAS via Subnet erreichen für CIFS Freigabe

flachfalke

Guten Tag,

ich stehe am Abgrund zur Weißglut.

Ich habe einen FreeNAS aufgesetzt um diesen in einem Netzwerk was mit einer pfSense 2.1.5 betrieben wird einzubinden.

Das Netzwerk hat mehrere Subnets. Der NAS hat sein eigenes bekommen.
Beim eintichten habe ich mich eher auf die Benutzerechte konzentreirt und nicht an die Broadcast Probleme mit Windows Freigaben geadcht.

Jetzt habe ich den NAS ins Netzwerk eingebunden und hatte vorher schon die Regeln konfiguriert und war schon erfreut, dass ich von einem PC, der seine Backups auf dem NAS ablegen sollte, diesen auch anpingen kann. Aber das war es dann auch ;(
Nach etwas Suche im Netz wurde mit klar, dass es für Windowsfreigaben nicht einfach ist, diese über verschiedene Subnets zu erreichen.
Nachdem was ich hier im Forum gefunden habe, gibt die zwei Fälle, dass der NAS entweder nicht anzupingen ist, oder/und mit Namen nicht erreichbar ist und oft ein DNS Problem vorliegt.

Um einen Fehler bei den Rules auszuschließen, habe ich auf dem NAS Subnet und einem LAN Netz testweise any-to-any auf beiden Seiten erstellt und alle anderen deaktiviert - nur um es wirklich auszuschliessen!
Aber schon vorher konnte ich sowohl pingen, als auch einen erfolgreichen nslookup machen.
Das einzige was nicht klappt, ist auf die Freigaben zu kommen.

Weder via IP noch über den Namen. Mein Ziel ist es ja nicht mal, dass ich per Windows Explorer das Netz durchsuchen kann. Es würde mir vollkommen reichen, wenn ich die für den PC bestimmte Freigabe als Laufwerk einbinden kann.

Wenn ich den NAS an ein Switch im selben Subnet stecke, klappt natürlich alles auf Anhieb. Darum suche ich in der pfSense den Fehler.

Sowohl PC als auch der NAS haben eine feste IP.
Ich kann vom NAS den PC im anderen Subnet anpingen, nslookup im Lan wie auch ins I-Net klappen von beiden Seiten aus.

Wenn ich über CMD: "dir \ip_des_NAS" ausführe kommt:
Der Netzwerkpfad wurde nicht gefunden

Via Explorer und Diagnose kommt: Die Verbindung wird vom Remotegerät nicht akzeptiert

Jemand einen Ansatz für mich, was ich übersehe oder wie ich testen könnte, woran ich scheiter?

Gruß…

orcape

Hi flachfalke,

ich stehe am Abgrund zur Weißglut.

…und das bringt Dich auch nicht weiter.... ;)
Du bist wohl nicht der einzige der an Layer3 und Broadcasts scheitert.
Ich betreibe so in etwa ein ähnliches Szenario und muss mich bis Dato auch damit zufrieden geben, das es nichts mit Samba wird.
Kleines Trostpflaster für mich, nur ganz selten ein Windows-PC im Netzwerk.
Alle Versuche, das mit einem Regelwerk zurecht zu biegen, waren nicht von Erfolg gekrönt, obwohl ab und an im Netz zu lesen ist, das es funktionieren soll.

und war schon erfreut, dass ich von einem PC, der seine Backups auf dem NAS ablegen sollte, diesen auch anpingen kann.

ICMP hat eben nichts mit TCP/IP zu tun. :)
Ich habe mich für den Zugriff bis jetzt mit FTP beholfen, ist zwar nicht so kompfortabel, funktioniert aber.
Schau mal hier…
http://www.unixboard.de/vb3/showthread.php?52131-Samba-subnetz%FCbergreifend
Scheitert bei mir am Verständnis….

wirst du ein echtes Routing zwischen den Subnets ermöglichen müssen, das auch Broadcasts durchlässt (indem du z.B. direkte Neighbors mittels iproute2 definierst).

Wenn Du da was nachvollziehen kannst wäre ich über eine Rückmeldung ganz dankbar.
Gruß orcape

fbd

Mal Windowsfirewall ausschalten und falls das was ändert in der Windowsfirewall andere Subnets durchlassen?

orcape

Mal Windowsfirewall ausschalten und falls das was ändert in der Windowsfirewall andere Subnets durchlassen?

Sorry, aber was hat ein blocken von Broadcasts auf Layer3 in der pfSense mit einer Windows Firewall zu tun ?

fbd

@orcape:

Mal Windowsfirewall ausschalten und falls das was ändert in der Windowsfirewall andere Subnets durchlassen?

Sorry, aber was hat ein blocken von Broadcasts auf Layer3 in der pfSense mit einer Windows Firewall zu tun ?

So wie ich es verstanden habe sind im konkreten Fall die Broadcasts ja nur für die Namensauflösung notwendig. Er hat aber schon das Problem dass er mit \ <ip>nicht auf die Freigabe kommt. Das gleiche hatte ich auch schon - und da hat die Windowsfirewall den Zugriff auf das andere Subnet blockiert.

Um einen Fehler bei den Rules auszuschließen, habe ich auf dem NAS Subnet und einem LAN Netz testweise any-to-any auf beiden Seiten erstellt und alle anderen deaktiviert - nur um es wirklich auszuschliessen!

Wenn er damit sagen will dass es mit any-to-any klappt, dann ist mein Hinweis natürlich fehl am Platz.</ip>

flachfalke

@fbd:

Um einen Fehler bei den Rules auszuschließen, habe ich auf dem NAS Subnet und einem LAN Netz testweise any-to-any auf beiden Seiten erstellt und alle anderen deaktiviert - nur um es wirklich auszuschliessen!

Wenn er damit sagen will dass es mit any-to-any klappt, dann ist mein Hinweis natürlich fehl am Platz.

Nein, mit any-to-any klappt genau so nichts, wie mit den Rules, die ich mir vorher aus dem Netz abgeschaut habe, um nicht das Scheunentor öffnen zu müssen. Aber bevor ich mich todsuche an dem Problem und es nachher, bedingt durch eine falsche Regel nicht klappt, teste ich lieber so.
Nach meinem pfSense Verständnis, ist doch mit einer solchen any-to-any Rule theoretisch keine Regelwerk im Weg, oder doch?!

Ich habe mich für den Zugriff bis jetzt mit FTP beholfen, ist zwar nicht so kompfortabel, funktioniert aber.
Schau mal hier…
http://www.unixboard.de/vb3/showthread.php?52131-Samba-subnetz%FCbergreifend
Scheitert bei mir am Verständnis….

Korrekt, wenn ich per ftp:\ anfrage, kommt die Benutzkennungsabfrage als "Antwort"….grrrr

Der Threadersteller aus deinem Link, hat im ServerSubNetz einen WINS Server aufgeführt....der sorgt glaub ich in dem Fall dafür, dass er zumindest die Freigaben aufgelistet bekommt mit einem "dir \...." Das würde mir ja VOLLKOMMEN reichen! Ob die Netzwerkumgebung unter Windows was ausgibt oder ich den NAS per IP und nicht per Namen ansprechen muss, wäre mir herzlich egal. Ich kanns irgendwie nicht glauben, dass das ein Problem ist und hoffte an meiner laienhaftigkeit zu scheitern.

Aber nachdem ich das DNS Problem gemeistert habe und sowohl per Namen als auch per IP Rückmeldung bekam, dachte ich es muss doch langsam funzen...

Mein Big Prob ist, dass ich nicht weiß, ob ich im NAS das Problem lösen KÖNNTE, oder in der Sense, oder oder. Der Netzwerk Guru bin ich nicht;(

Im FreeNAS Forum hab ich das gefunden:
http://forums.freenas.org/index.php?threads/pfsense-two-lan-subnets-freenas-shares.26913/

Den Lösungsversuch des TE hätte ich nichtmals versucht, aber vl kann jemand anders aus den Antworten etwas nützliches ableiten?

Ich gehe weiter kämpfen….gegen Windmühlen

orcape

Korrekt, wenn ich per ftp:\ anfrage, kommt die Benutzkennungsabfrage als "Antwort"….grrrr

..logisch, da sind keine Broadcasts gefragt.

Ich gehe weiter kämpfen….gegen Windmühlen

…lass den Quatsch, das hat schon der Don Quijote mit seiner Dulcinea von Toboso nicht hinbekommen.
Versuchs mal mit IPV6, da ist Broadcast Geschichte.
Ich schreib dann mal ab...;-)
Gruß orcape

flachfalke

ok…

Würdest Du mir das kurz näher erklären? Reicht es die Subnets, die auf den NAS sollen auf IPV6 umzustellen, oder wie darf ich das verstehen?

Eine andere Alternative wäre dann nur, alles was mit dem NAS kommunizieren soll, in ein Subnet zu packen?

oh man... :-[

orcape

Reicht es die Subnets, die auf den NAS sollen auf IPV6 umzustellen, oder wie darf ich das verstehen?

Die ausgehenden Rules noch IPV6 aktivieren, natürlich muss IPV6 auch auf NAS und PC aktiviert sein bzw. das unterstützen.
Bei IPV 6 ist Multicast aktuell, nicht mehr Broadcast.
Wissen tu ich 's auch nicht, aber vermuten….;-)

orcape

Das mit IPV6 scheint aber auch nicht wirklich die Lösung unseres Problems zu sein.
Samba4 soll wohl auch noch nicht wirklich mit IPV6 umgehen können.
Als nächstes Problem habe ich mit OpenMediaVault und damit Debian-Wheezy nur ein Samba3.6 an Board.
Also weiter mit FTP oder NFS…..:(
Gruß orcape

orcape

Hi,
habe das ganze nun nach Änderung der Samba-Version auf dem NAS in den Griff bekommen.
Weiterhin nur mit IPV4.
Allerdings ein reines Linux-Netz, zumindest meistens.;)
Auf den betreffenden Interfaces die Freigabe der Ports 137-139 oder eine any-to-any Rule.
Folgendes Tutorial….
http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-de-4/s1-samba-network-browsing.html
Hier mal die Samba.conf des NAS….

======================= Global Settings =======================
[global]
workgroup = orca.net
server string = NAS
netbios name = skyflight
interfaces = 127.0.0.0/8 172.16.7.0/24 192.168.33.0/24 192.168.89.0/24 192.168.155.0/24
security = user
domain master = yes
local master = yes
wins server = yes
remote announce = 192.168.89.255 192.168.155.255 192.168.33.255 192.168.55.255
dns proxy = no
log level = 0
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
syslog only = yes
panic action = /usr/share/samba/panic-action %d
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = no
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\$
pam password change = yes
socket options = TCP_NODELAY IPTOS_LOWDELAY
guest account = nobody
load printers = no
disable spoolss = yes
printing = bsd
printcap name = /dev/null
unix extensions = yes
wide links = no
create mask = 0777
directory mask = 0777
use sendfile = yes
aio read size = 16384
aio write size = 16384
null passwords = no
time server = no
wins support = yes

#======================= Share Definitions =======================
[orca]
path = /media/0dfd442f-28c4-421b-9b37-32570c3828e8/orca
guest ok = no
read only = no
browseable = yes
inherit acls = yes
inherit permissions = no[global]
        workgroup = orca.net
        server string = server orca
        netbios name = orca
        interfaces = 127.0.0.0/8 192.168.33.0/24 192.168.89.0/24 192.168.155.0/24
        security = user
        encrypt passwords = true
        passwd program = /usr/bin/passwd %u
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *p$
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 1000
        os level = 64
        local master = yes
        wins support = No
        wins server = 172.16.7.10
        remote announce = 172.16.7.10 192.168.89.255 192.168.155.255 192.168.33.255
        domain master = No
        dns proxy = No
        usershare allow guests = Yes
        panic action = /usr/share/samba/panic-action %d
        idmap config * : backend = tdb

[orca]
        comment = Home Directories
        path = /home/orca/
        valid users = %S
        admin users = root
        read only = No
        create mask = 0700
        directory mask = 0700
        guest ok = Yes
        public = Yes
        browseable = Yes

ea support = no
store dos attributes = no
printable = no
create mask = 0755
force create mode = 0644
directory mask = 0755
force directory mode = 0755
hide dot files = yes
valid users = "orcape","Tino","orca","Kerstin"
invalid users =
read list = "Tino","Kerstin"
write list = "orcape","orca"

Hier die Samba.conf eines Linux-Client….

[global]
        workgroup = orca.net
        server string = server orca
        netbios name = orca
        interfaces = 127.0.0.0/8 192.168.33.0/24 192.168.89.0/24 192.168.155.0/24
        security = user
        encrypt passwords = true
        passwd program = /usr/bin/passwd %u
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *p$
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 1000
        os level = 64
        local master = yes
        wins support = No
        wins server = 172.16.7.10
        remote announce = 172.16.7.10 192.168.89.255 192.168.155.255 192.168.33.255
        domain master = No
        dns proxy = No
        usershare allow guests = Yes
        panic action = /usr/share/samba/panic-action %d
        idmap config * : backend = tdb

[orca]
        comment = Home Directories
        path = /home/orca/
        valid users = %S
        admin users = root
        read only = No
        create mask = 0700
        directory mask = 0700
        guest ok = Yes
        public = Yes
        browseable = Yes

Dabei befindet sich das NAS in einer DMZ an OPT1, Netzwerk 172.16.7.0/24.
Der Client im LAN, Netzwerk 192.168.155.0/24
Die Daten einfach entsprechend anpassen, sollte funktionieren.
Kleine Fehler in der Config sind mir zu verzeihen…..;)
Gruß orcape

JeGr

Ich weiß zwar nicht wie ihr von SMB/CIFS auf IPv6 kommt, aber die pfSense war bei solchen Problemen seltenst die Ursache. Meist ließ es sich runterbrechen auf:

SAMBA war falsch konfiguriert (bspw. nur das Netz erlaubt, wo er drin steht und das andere Netz nicht)
SMB Browsing hat nicht gepasst
Freigaben falsch konfiguriert
etc etc

Die pfSense an der Stelle ist höchst dumm zu betrachten und da Falke ja schon sagt, dass ihm Netzbrowsing wurscht ist, sollte dem auch nichts entgegen stehen. Ich hab hier ein NAS (Synology was ja Samba ist) im Netz stehen und keinerlei Problem von verschiedenen Netzen aus drauf zu browsen, selbst per Einwahl und OpenVPN ist das drin - und da wird auch nur geroutet und kein Broadcast oder sonstige dark magic (TM) vollzogen.

Insofern würde ich wie Rudi im anderen Thread raten, dir mal den FreeNAS genau anzusehen oder/und testweise einfach mal ne dumme Windows Kiste im gleichen Netz freizugeben und mit der mal zu testen (Vorsicht da die Firewall der Kiste). Am Ende ist es gar nicht die pfs (wie so oft) sondern ne ganz andere Stellschraube.

Grüße

orcape

Hi JeGr,

Ich weiß zwar nicht wie ihr von SMB/CIFS auf IPv6 kommt,

Zitat @flachfalke…

Beim eintichten habe ich mich eher auf die Benutzerechte konzentreirt und nicht an die Broadcast Probleme mit Windows Freigaben geadcht.

Da es Problem mit den Broadcasts bei IPV6 nicht mehr gibt, hatte ich das als Möglichkeit angesehen.
Leider habe ich dann hinterher gelesen, das Samba4 da auch noch Schwierigkeiten macht.

…aber die pfSense war bei solchen Problemen seltenst die Ursache. Meist ließ es sich runterbrechen auf:

SAMBA war falsch konfiguriert (bspw. nur das Netz erlaubt, wo er drin steht und das andere Netz nicht)

SMB Browsing hat nicht gepasst

Freigaben falsch konfiguriert

etc etc

Das habe ich mittlerweile auch herausgefunden.
Bei mir lag nur das Problem vor, das ich auf dem OMV-NAS noch eine Samba3 Version laufen hatte.
Diese war nicht dazu zu überreden, mit meinen anderen Debian-Jessie PC ´s zusammen zu arbeiten, da hier schon Samba4 zum Einsatz kommt.
Jetzt habe ich das OMV (Wheezy) "gezwungen" Samba4 zu akzeptieren, was es mit einigem "murren" auch tut und schon funktioniert das NAS als domain master und die anderen PC ´s spielen mit.
Danke an @flachfalke, ich hätte ohne seinen Thread das Problem (welches eigentlich keines ist..;-)) wohl weiter vor mir hergeschoben.
Gruß orcape

JeGr

Diese war nicht dazu zu überreden, mit meinen anderen Debian-Jessie PC ´s zusammen zu arbeiten, da hier schon Samba4 zum Einsatz kommt.

Ja, 2x Samba unterschiedlicher Versionen… Unschön.

@flachfalke: aber auch in deinem Fall denke ich, dass es eben eher auf Samba Seite zu suchen ist, nicht an der pfSense. Hoffe du bleibst am Ball.

flachfalke

@orcape:

Danke an @flachfalke,…

Nicht dafür :) Aber freut mich, wenn man als Noob auch irgendwie etwas beitragen kann.

Ich bin absolut kein Crack und auf Linux basierten Dingen noch weniger. Darum zweifel ich grundlegend immer an meinem KnowHow und tue mich schwer ein Thread aufzumachen für Dinge, dir nach meiner Ansicht eigentlich funktionieren müssten.

Denn eigentlich will ich es nicht verstehen müssen, dass ein NAS keine CIFS über ein Subnet sichtbar bekommt für Windows…, aber nachdem orcape hier schrieb, dass ich besser meine Energie in ein Workaround stecke, hatte ich das vor. Aber bis heute bin ich zeitlich noch nicht dazu gekommen und freue mich grad auch darüber, denn JeGr macht mir doch wieder Hoffnung.

Den FreeNAS habe ich nämlich nur installiert in Sicht auf HDD und Dateisystem inkl. CIFS Freigaben und Benutzerrechten. SAMBA hab ich nicht konfiguriert/geändert. Hatte ich auch nie Bedarf dran, denn in meinem Netzwerk wo ich es eingerichtet habe bzw die Benutzerrechte und Co. getestet habe, steckte er immer im selben Netz mit allen Clients.

Aber wenn ich jetzt JeGr

SAMBA war falsch konfiguriert (bspw. nur das Netz erlaubt, wo er drin steht und das andere Netz nicht)

lese und die ersten Zeilen von orcape Samba Config Datei, denke (und HOFFE) ich, dass dort mein Problem liegt. Denn da habe ich nie Hand dran angelegt.
Für mich allein war ich froh genug, dass ich von den Subnetzen pingen, nslookup und Co erfolgreich ausführen konnte und dachte damit ist die Sache geritzt?
Aber aus der Zeile hier:

interfaces = 127.0.0.0/8 172.16.7.0/24 192.168.33.0/24 192.168.89.0/24 192.168.155.0/24

von orcape entnehme ich peinlichst, dass man im SAMBA die Subnetze eintragen muss!? Zugegeben…sollte es daran liegen freu ich mir ja n Loch wohin, aber da wären wir auch wieder beim newbie meinerseits.

Hoffe du bleibst am Ball.

Wie du merkst, habt ihr mir Hoffnung gemacht. Ich bin gespannt…
Könnt ihr mir noch was mit auf den Weg für morgen geben? Also ich muss im NAS in der Samba Config die nötigen Subnetze hinzufügen und dann könnte es schon klappen?

Greets!!

JeGr

@flachfalke: ja man kann Samba durchaus beschränken, dass Anfragen nur aus bestimmten Netzen angenommen werden. Ob das bei dir der Fall ist kann ich nicht sagen, aber da wäre zumindest ein Ansatzpunkt :)

flachfalke

Gute Nachricht: Problem besteht nicht mehr!
Schlechte Nachricht: Keine Ahnung warum…

Hab gestern Abend kreuz und quer gelesen und mir einige Dinge notiert, die ich ändern wollte:

NETBIOS Namen müssen kleingeschrieben sein
Allowed Hosts hinzufügen im NAS
und noch mehr...

Aber als ich heute auf die "Baustelle" kam, hab ich mit dem NetBios Namen des NAS angefangen und nach dem Speichern, konnte ich ihn über den Windows Explorer erreichen :o
Zum gegencheck nochmal umgeändert, aber daran lag es wohl nicht. Also: Im Grunde habe ich nichts geändert, aber es klappt nun. Weiß der Geier warum.

Am Wochenende hatte sich die pfSense zum zweiten mal in 9 Monaten verabschiedet und es fand ein Reboot statt. Aber wenn es daran liegen sollte...kann ich leider auch keine Erklärung dafür finden.
Natürlich freue ich mich, dass es klappt, aber es kommen die nächsten Probleme.

Was nicht sein sollte, ist, dass wenn ich von verschiedenen PC's aus auf den NAS pinge, die Latenz stark schwankt. Von realen 1-3ms bis hin zu 150ms und mehr ist alles dabei.

Auffällig ist der Load average mit circa immer den Werten: 2.69, 2.38, 2.33, die auch mal über 3 klettern.

Die SystemActivity zeigt das dazu:

last pid: 69124;  load averages:  2.48,  2.46,  2.37  up 0+03:56:43    19:10:06
185 processes: 9 running, 161 sleeping, 15 waiting

Mem: 219M Active, 684M Inact, 548M Wired, 272K Cache, 414M Buf, 2461M Free
Swap: 8192M Total, 8192M Free

  PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
  256 root       138   20  6908K  1404K CPU1    1 185:57 96.00% /usr/local/sbin/check_reload_status
   10 root       171 ki31     0K    32K RUN     0  71:11 48.00% [idle{idle: cpu0}]
   10 root       171 ki31     0K    32K RUN     1 131:15 19.97% [idle{idle: cpu1}]
67561 root        55    0   150M 38068K RUN     0   0:00  1.95% /usr/local/bin/php
    0 root       -16    0     0K   192K sched   0   0:57  0.00% [kernel{swapper}]
   11 root       -32    -     0K   272K RUN     0   0:52  0.00% [intr{swi4: clock}]
   11 root       -68    -     0K   272K RUN     0   0:31  0.00% [intr{irq257: re1}]
61062 root        76    0   157M 49568K accept  0   0:19  0.00% /usr/local/bin/php{php}
    0 root       -68    0     0K   192K -       0   0:13  0.00% [kernel{dummynet}]
    3 root        -8    -     0K    16K -       0   0:07  0.00% [g_up]
   11 root       -68    -     0K   272K WAIT    0   0:06  0.00% [intr{irq19: ath0 atap}]
29496 root        76   20  8296K  1888K wait    0   0:06  0.00% /bin/sh /var/db/rrd/updaterrd.sh
    4 root        -8    -     0K    16K -       0   0:04  0.00% [g_down]
   13 root       -16    -     0K    16K -       0   0:03  0.00% [yarrow]
   11 root       -32    -     0K   272K WAIT    0   0:02  0.00% [intr{swi4: clock}]
84962 root        64   20 12160K  7120K select  0   0:02  0.00% /usr/local/sbin/ntpd -g -c /var/etc/ntpd.
42964 root        64   20  5784K  1484K select  0   0:02  0.00% /usr/local/sbin/apinger -c /var/etc/aping
55780 root        44    0 24232K  4600K kqread  0   0:02  0.00% /usr/local/sbin/lighttpd -f /var/etc/ligh

alle paar Sekunden kommen die "savevoucher" und "filter_sync" PIDs dazu

  PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
  256 root       134   20  6908K  1404K RUN     1 186:31 77.98% /usr/local/sbin/check_reload_status
79333 root       128   20   152M 33476K CPU0    0   0:00 53.96% /usr/local/bin/php -f /etc/rc.filter_sync
   10 root       171 ki31     0K    32K RUN     1 131:41 43.99% [idle{idle: cpu1}]
68114 root       126   20   162M 50864K RUN     0   0:03 41.99% /usr/local/bin/php -f /etc/rc.savevoucher

Über die Suche nach "/usr/local/sbin/check_reload_status" kommen zig Threads hier im Forum, auf die es keine mir Verständliche Lösung gibt. Manche haben aufgrund dies die pfSense neu aufgesetzt oder geupdatet.
Einn Thread gibt es, wo alle 5 Minuten die Voucher und Firewall Regeln neu gesynct werden, was ihm auffällig vorkam. Bei mir, passiert das alle paar Sekunden!

Feb 10 18:19:08 	check_reload_status: Synching vouchers
Feb 10 18:19:07 	check_reload_status: Synching vouchers
Feb 10 18:18:45 	check_reload_status: Syncing firewall
Feb 10 18:18:42 	check_reload_status: Syncing firewall
Feb 10 18:18:38 	check_reload_status: Synching vouchers
Feb 10 18:18:38 	check_reload_status: Synching vouchers
Feb 10 18:18:14 	check_reload_status: Syncing firewall
Feb 10 18:18:11 	check_reload_status: Syncing firewall
Feb 10 18:18:05 	check_reload_status: Synching vouchers
Feb 10 18:18:05 	check_reload_status: Synching vouchers
Feb 10 18:17:44 	check_reload_status: Syncing firewall
Feb 10 18:17:41 	check_reload_status: Syncing firewall
Feb 10 18:17:37 	check_reload_status: Synching vouchers
Feb 10 18:17:37 	check_reload_status: Synching vouchers
Feb 10 18:17:05 	check_reload_status: Synching vouchers
Feb 10 18:17:05 	check_reload_status: Synching vouchers
Feb 10 18:16:43 	check_reload_status: Syncing firewall
Feb 10 18:16:40 	check_reload_status: Syncing firewall
Feb 10 18:16:36 	check_reload_status: Synching vouchers
Feb 10 18:16:36 	check_reload_status: Synching vouchers
Feb 10 18:16:09 	check_reload_status: Syncing firewall
Feb 10 18:16:08 	check_reload_status: Syncing firewall
Feb 10 18:16:04 	check_reload_status: Synching vouchers
Feb 10 18:16:04 	check_reload_status: Synching vouchers
Feb 10 18:15:41 	check_reload_status: Syncing firewall
Feb 10 18:15:39 	check_reload_status: Syncing firewall
Feb 10 18:15:35 	check_reload_status: Synching vouchers
Feb 10 18:15:35 	check_reload_status: Synching vouchers
Feb 10 18:15:14 	check_reload_status: Syncing firewall
Feb 10 18:15:12 	check_reload_status: Syncing firewall
Feb 10 18:15:03 	check_reload_status: Synching vouchers
Feb 10 18:15:03 	check_reload_status: Synching vouchers
Feb 10 18:14:38 	check_reload_status: Syncing firewall
Feb 10 18:14:35 	check_reload_status: Syncing firewall
Feb 10 18:14:31 	check_reload_status: Synching vouchers
Feb 10 18:14:31 	check_reload_status: Synching vouchers
Feb 10 18:14:02 	check_reload_status: Synching vouchers
Feb 10 18:14:02 	check_reload_status: Synching vouchers
Feb 10 18:13:33 	check_reload_status: Syncing firewall
Feb 10 18:13:32 	check_reload_status: Syncing firewall
Feb 10 18:13:23 	check_reload_status: Synching vouchers
Feb 10 18:13:23 	check_reload_status: Synching vouchers
Feb 10 18:12:49 	check_reload_status: Synching vouchers
Feb 10 18:12:49 	check_reload_status: Synching vouchers
Feb 10 18:12:32 	check_reload_status: Syncing firewall
Feb 10 18:12:26 	check_reload_status: Syncing firewall
Feb 10 18:12:22 	check_reload_status: Synching vouchers
Feb 10 18:12:22 	check_reload_status: Synching vouchers
Feb 10 18:11:56 	check_reload_status: Syncing firewall
Feb 10 18:11:55 	check_reload_status: Syncing firewall
Feb 10 18:11:46 	check_reload_status: Synching vouchers
Feb 10 18:11:46 	check_reload_status: Synching vouchers
Feb 10 18:11:29 	check_reload_status: Syncing firewall
Feb 10 18:11:25 	check_reload_status: Syncing firewall
Feb 10 18:11:21 	check_reload_status: Synching vouchers
Feb 10 18:11:21 	check_reload_status: Synching vouchers
Feb 10 18:10:46 	check_reload_status: Synching vouchers
Feb 10 18:10:46 	check_reload_status: Synching vouchers
Feb 10 18:10:29 	check_reload_status: Syncing firewall
Feb 10 18:10:24 	check_reload_status: Syncing firewall
Feb 10 18:10:20 	check_reload_status: Synching vouchers
Feb 10 18:10:20 	check_reload_status: Synching vouchers
Feb 10 18:09:42 	check_reload_status: Synching vouchers
Feb 10 18:09:42 	check_reload_status: Synching vouchers
Feb 10 18:09:27 	check_reload_status: Syncing firewall
Feb 10 18:09:24 	check_reload_status: Syncing firewall
Feb 10 18:09:20 	check_reload_status: Synching vouchers
Feb 10 18:09:20 	check_reload_status: Synching vouchers
Feb 10 18:08:37 	check_reload_status: Synching vouchers
Feb 10 18:08:36 	check_reload_status: Synching vouchers
Feb 10 18:08:24 	check_reload_status: Syncing firewall
Feb 10 18:08:20 	check_reload_status: Syncing firewall
Feb 10 18:08:15 	check_reload_status: Synching vouchers
Feb 10 18:08:14 	check_reload_status: Synching vouchers
Feb 10 18:07:40 	check_reload_status: Syncing firewall
Feb 10 18:07:39 	check_reload_status: Syncing firewall
Feb 10 18:07:30 	check_reload_status: Synching vouchers
Feb 10 18:07:30 	check_reload_status: Synching vouchers
Feb 10 18:07:21 	check_reload_status: Syncing firewall
Feb 10 18:07:18 	check_reload_status: Syncing firewall
Feb 10 18:07:14 	check_reload_status: Synching vouchers
Feb 10 18:07:14 	check_reload_status: Synching vouchers
Feb 10 18:06:29 	check_reload_status: Synching vouchers
Feb 10 18:06:29 	check_reload_status: Synching vouchers
Feb 10 18:06:18 	check_reload_status: Syncing firewall
Feb 10 18:06:17 	check_reload_status: Syncing firewall
Feb 10 18:06:07 	check_reload_status: Synching vouchers
Feb 10 18:06:07 	check_reload_status: Synching vouchers
Feb 10 18:05:29 	check_reload_status: Synching vouchers
Feb 10 18:05:28 	check_reload_status: Synching vouchers
Feb 10 18:05:21 	check_reload_status: Syncing firewall
Feb 10 18:05:17 	check_reload_status: Syncing firewall
Feb 10 18:05:06 	check_reload_status: Synching vouchers
Feb 10 18:05:06 	check_reload_status: Synching vouchers
Feb 10 18:04:34 	check_reload_status: Syncing firewall
Feb 10 18:04:28 	check_reload_status: Syncing firewall
Feb 10 18:04:24 	check_reload_status: Synching vouchers
Feb 10 18:04:24 	check_reload_status: Synching vouchers
Feb 10 18:04:09 	check_reload_status: Syncing firewall
Feb 10 18:04:04 	check_reload_status: Synching vouchers
Feb 10 18:04:04 	check_reload_status: Synching vouchers
Feb 10 18:03:59 	check_reload_status: Reloading filter
Feb 10 18:03:59 	check_reload_status: Syncing firewall
Feb 10 18:03:23 	check_reload_status: Synching vouchers
Feb 10 18:03:23 	check_reload_status: Synching vouchers
Feb 10 18:03:08 	check_reload_status: Syncing firewall
Feb 10 18:03:06 	check_reload_status: Syncing firewall
Feb 10 18:03:02 	check_reload_status: Synching vouchers
Feb 10 18:03:02 	check_reload_status: Synching vouchers
Feb 10 18:02:28 	check_reload_status: Syncing firewall
Feb 10 18:02:26 	check_reload_status: Syncing firewall
Feb 10 18:02:14 	check_reload_status: Synching vouchers
Feb 10 18:02:14 	check_reload_status: Synching vouchers
Feb 10 18:02:07 	check_reload_status: Syncing firewall
Feb 10 18:02:04 	check_reload_status: Syncing firewall
Feb 10 18:02:01 	check_reload_status: Synching vouchers
Feb 10 18:02:00 	check_reload_status: Synching vouchers
Feb 10 18:01:14 	check_reload_status: Syncing firewall
Feb 10 18:01:12 	check_reload_status: Synching vouchers
Feb 10 18:01:12 	check_reload_status: Synching vouchers
Feb 10 18:01:12 	check_reload_status: Syncing firewall
Feb 10 18:01:01 	check_reload_status: Syncing firewall
Feb 10 18:00:36 	check_reload_status: Synching vouchers
Feb 10 18:00:36 	check_reload_status: Synching vouchers
Feb 10 18:00:16 	check_reload_status: Syncing firewall
Feb 10 18:00:12 	check_reload_status: Syncing firewall

An Services habe ich folgende:

apinger 	
captiveportal 	xx
captiveportal 	xy
cron 	
dhcpd 	
dnsmasq 	
ntpd 
radiusd 
squid

Und in einem Thread kam man darauf, dass es vielleicht daran liegen kann, dass sich ein regestrierter Voucher auf mehreren Netzen (versucht) einzuloggen, was zu einem Problem dieser Art führen kann? Das konnte ich so direkt nicht bestätigen.

Im Grunde habe ich keinen Schimmer, wo ich anfangen muss. Das Problem wird die CPU Last sein? Aber die Ursache kann x-Möglicheiten sein, oder?

Hier mal ein Ping von der pfSense aus zur Veranschaulichung

PING 192.168.70.3 (192.168.70.3) from 192.168.60.1: 56 data bytes
64 bytes from 192.168.70.3: icmp_seq=0 ttl=128 time=3.597 ms
64 bytes from 192.168.70.3: icmp_seq=1 ttl=128 time=7.451 ms
64 bytes from 192.168.70.3: icmp_seq=2 ttl=128 time=71.085 ms
64 bytes from 192.168.70.3: icmp_seq=3 ttl=128 time=91.081 ms
64 bytes from 192.168.70.3: icmp_seq=4 ttl=128 time=58.562 ms
64 bytes from 192.168.70.3: icmp_seq=5 ttl=128 time=53.692 ms
64 bytes from 192.168.70.3: icmp_seq=6 ttl=128 time=54.931 ms
64 bytes from 192.168.70.3: icmp_seq=7 ttl=128 time=0.878 ms
64 bytes from 192.168.70.3: icmp_seq=8 ttl=128 time=97.305 ms
64 bytes from 192.168.70.3: icmp_seq=9 ttl=128 time=46.065 ms

--- 192.168.70.3 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.878/48.465/97.305/32.939 ms

Die Sense 2.1.5 läuft auf einer APU1C mit 4GB Ram. Angeschlossen ist sie an ein Cisco 10 Port managed Switch auf dem zwei WANs ankommen und in der pfSense zum MultiWan mutieren. Einmal aus einem DSL Modem im Bridgemode mit PPPOE und Nr.2 ist ein LTE Router per DHCP.
Dazu läuft wie man bei Services sehen kann Squid und zwei CP. Ein Gästenetz und ein HeimWlan. Beide via Voucher Zugang.
Alle "wichtigen" Clients sind verkabelt.

Passt zwar nicht mehr in den Thread, aber möchte auch nicht einen aufmachen. Gibt zu der CPU Load Sache schon so viele. SChlau werd ich aus keinem.

Zwar läuft das Netzwerk, mit den beschriebenen Einschränkungen, aber eine Endlösung stellt es so nicht dar. Die Übertragungsrate auf den NAS z.B. bleibt bei 6MB/Sekunde stehen, obwohl dazwischen nur ein (GB) Switch ist. Das kann es ja nicht sein ;(

Aber aus Angst das Netz nun bei versuchen komplett zu killen, würde ich mit einer zweiten Apu anfangen es neu zu gestalten.
Oder ihr habt den einen heissen Ansatz, was da bei mir falsch läuft.

Greets,

JeGr

Da sich mit der neuen Version so einiges geändert hat, würde ich eher sagen mit 2.2 neu aufsetzen, dann hast du hoffentlich auch keine Stör- oder Seiteneffekte mehr, die sich jetzt vielleicht erledigt haben. Wenn du eh noch relativ am Anfang bist, würde ich dann auch gleich auf der neuen Codebasis anfangen aufzusetzen und nicht mit dem alten Stand - gerade was CP etc. angeht, wurde da ja einiges gestrickt.

orcape

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