io inizierei ad allineare le due versioni del fw tutte alle 2.3.x

Ciao,
pare che il mio problema si sia risolto cambiando il valore "State type" in "none", nelle impostazioni avanzate del "Rule 1".

Si tratta di una minor update, una novità inserita dalla 2.3
Normalmente sono solo fix di bug e in alcuni casi non richiedono nemmno un riavvio del firewall
Puoi procedere serenamente :)
Ciao

pfSense captive portal non ha il concetto di quantità di traffico. Solo il tempo.

Via google translate

Ciao,
lo fai in Nat Outbound
Ciao Fabio

Ciao Francesco,
tutta la parte di filtraggio web (HTTP/HTTPS) è gestita da un apparato Watchguard. Il motivo è presto detto: se da una parte potevo fare tutto anche con pfSense, è anche vero che la parte relativa al controllo del traffico HTTPS non è efficace come lo è sul Watchguard. Considerato che la nostra struttura è piuttosto ampia, diventa prioritario avere un ambiente dove poter intervenire in maniera veloce e sicura (abbiamo parecchie regole per specifici utenti e subnet). Da questo punto di vista, abbiamo visto che Watchguard fornisce una soluzione ottima: in realtà si potrebbe usare per molte altri servizi (antispam, filtro pop, terminatore VPN), ma l'uso come content filter HTTP/HTTPS per le nostre esigenze va benissimo.

Esatto, il filtraggio web è affidato esclusivamente a questo apparato e solo per alcune subnet interne. Tanto per fare un esempio, la subnet relativa a tutti gli apparati per gli ingressi ed uscite dalle sedi è ovviamente esclusa. Per quanto riguarda SQUID (due installazioni), offre servizi di proxy per quattro subnet, e l'unico controllo che esegue è che le chiamate arrivino dalle subnet autorizzate al suo utilizzo.

Ciao,

@proto:

su github c'è il sorgente di "filterlog" che legge da pflog0 e scrive direttamente nel syslog.
quindi solo parser esterni!

Ho dato un'occhiata ma è troppo per me (0 di programmazione). Mi accontenterò del formato stock di pfsense che con la documentazione si legge discretamente

Ciao!!!

Se usi PFSense come server dhcp i mac li puoi filtrare da lì, anche se magari non è il massimo.

Chiedo scusa ho mandato un pezzo di post che non dovevo…

Comunque ho verificato tramite servizi online (http://www.yougetsignal.com/tools/open-ports/) che tutte le porte di tutti gli host della LAN sono chiuse come hai detto tu.

–------------------------------------------------------------------------------
se vuoi bloccare il traffico dalla wan verso la 135 del tuo host, non devi fare nulla, di default è bloccata
Se vuoi bloccare l'accesso da un host della lan alla porta 135 di un altro host, non puoi fare nulla perchè normalmente il traffico tra host della stessa lan non passa dal firewall.

In sintesi tutte le porte dei client risultano chiuse attraverso il firewall solo quando connessi ad internet mentre non è detto tra connessioni fra host della stesso rete locale..

In effetti le prove di controllo delle porte le ho fatte in locale senza passare attravverso il firewall anche se in realtà avrei dovuto fare il controllo direttamente da remoto
Fabio ti ringrazio per la rapida spiegazione.

Ciao,
Devi creare una configurazione multi wan, prova a seguire quest'articolo
http://www.pfsenseitaly.com/2012/09/multi-wan-con-pfsense-parte-1.html?m=1
Ciao Fabio

si, latenza più alta, MTU anche più bassa, presumo che sia dovuto al fatto che sotto ci sia un tunnel 6in4 o qualcosa del genere….
Sinceramente... sono tornato sui miei passi dopo un paio di giorni di prova e ho rimesso su il tunnel H.E. (che mi dà una /64 + /48 statiche...).
Sarà pure un servizio sperimentale ma non ha il minimo senso pratico assegnare indirizzi ipv6 dinamici,
è inadatto ad essere utilizzato su un router che serve una rete, ogni volta che cade la connessione vengono riassegnati nuovi indirizzi agli host e questo genera problemi, oltre ovviamente a vanificare uno dei principali vantaggi di avere ipv6 (ad esempio in ambito controllo remoto).

Risolto…..

dato che il pc win 10 non lo utilizzo per navigare, non avevo inserito il GW....

scusate....

Buona giornata

io passato ora dalla 2.3 alla 2.3.1 e nessun problema.
ciao

In effetti tu hai ragione: "istruisci SNORT a sopprimere quel determinato allarme per quel determinato IP….". Di conseguenza quell'IP verrà ignorato per quella specifica regola ma potrebbe farne scattare altri trigger...

Ecco perchè la Suppress list non è altro che l'elenco delle tracce non ancora approvvate definitivamente a causa di possibili falsi positivi che potrebbero anche non esserlo perchè determinati da nostre valutazioni errate.

Credo che lascerò ancora quel piccolo elenco creato nella Suppress list e, a poco a poco lo sposterò nella Pass list.

Grazie Zanotti