Separare LAN da WIFI è possibile?

LiquiD_85

Salve, sto cercando un modo in cui gli utenti collegati via wireless ad un accesspoint a sua volta collegato a sense non possano accedere agli utenti collegati via cavo sempre a sense, apparte mettere una sottorete c'è modo???

Grz1000 a tutti voi.

Rampage

la soluzione più semplice che mi viene in mente è usare le VLAN.
crei una VLAN alla quale connetti l'AP con una classe di indirizzi tutta sua e sei a posto.

Zanotti

Io ho realizzato la cosa semplicemente con 3 schede ethernet. Rapido e indolore.

LiquiD_85

Mmmm … però se poi metto una terza scheda di rete devo aprirgli le varie porte suppongo o no!? il che potrebbe non essere sbagliato per il mio scopo ... mi sai dare qualche dettaglio in più? Del tipo ce qualche settaggio particolare per la terza ethernet? Sono completamente separate o tipo i client ethernet possono esplorare i client wireless, o vice versa!? Grz ...

Zanotti

Se metti una terza scheda di rete ovviamente dopo devi settare le regole che fanno al caso tuo. Tornando al mio esempio, il mio firewall per quanto riguarda la terza ethernet è separata anche fisicamente dagli switch perchè tramite il cavo va a finire dentro un access point. I client in wireless si collegano a questo access point ma poi è il Pfsense che assegna loro tramite DHCP gli ip che ho riservato.

La terza ethernet, che ho chiamato HOTSPOT, ha come rete 10.0.0.0/24 e come IP ha 10.0.0.1, l'access point ha 10.0.0.2 e i client wirelless hanno un range che viene loro assegnato che va da 10.0.0.10 a 10.0.0.20. Il traffico resta comunque separato anche per il fatto che sia l'interfaccia WAN che LAN hanno netmask e classi di rete totalmente differenti tra loro e oltretutto è possibile mettere regole ad hoc per impedire che ci sia passaggio di traffico tra le interfacce e relativi gateway.

Sempre lato rete wireless ho inserito delle regole che oltre gli orari di uffici si attiva il blocca tutto quindi anche chi dovesse collegarsi alla rete non va da nessuna parte. Stessa cosa per servizi di posta e proxy. Magari se la cosa ti interessa provo a postare qualche regola.

LiquiD_85

Ti ringrazio, momentaneamente non mi serve di fare una restrizione così severa (complimenti cmq per la gestione molto professionale), però mi interesserebbe molto capire come assegni classi di ip diversi in base all'interfaccia, cioè se non ho capito male tu hai configurato il tutto così

Via cavo:
IP: 192.168.1.x
SubnetMask: 255.255.255.0
Gateway: 192.168.1.1

Via wireless:

IP: 10.0.0.x
SubnetMask: 255.255.255.0
Gateway: 10.0.0.1

giusto?
A questo punto mi chiedo 1) come fai a dire al server DHCP asegna 192 ai client cavo e 10.0.0.x a quelli wireless e 2) come fai comunicare la scheda 10.0.0.1 con la wan?

Forse sono domande sceme anzi SICURO :) ma sono nuovo di sense anche se ne ho piazzati già 3-4 ma non ho mai fatto nulla di particalare apparte chiudere e aprire porte e settare il captive portal con un normale local authentication … Grz1000 sei gentilissimo!!!

Zanotti

Si in effetti il mio schema è simile a quello che hai postato, per quanto riguarda il server DHCP tu lo puoi abilitare su di una interfaccia a tua piacimento, potresti abilitarlo sia per LAN che per HOTSPOT come nel mio caso. A seconda poi se tu sei un client wireless o un pc della LAN risponde il servizio DHCP che è attivo sul segmento di rete.

LA comunicazione tra WAN e client wireless nel mio caso è particolare, in pratica lascio ai client solo la possibilità di usare le porte 53 dns, 110 pop3 e 25 smtp. La navigazoine Internet è demandata al proxy squid che gira sulla WAN. I client wireless si collegano solo se puntano il browser al gateway HOTSPOT e solo sulla porta 8080 che a sua volta è un port forward per la porta 3128 della WAN, su cui gira squid appunto.

If Proto Ext. port range NAT IP Int. port range Description
HOTSPOT TCP/UDP 8080 x.x.x.x IP WAN
(ext.: 10.0.0.1) 3128 PORT FORWARD PER PROXY DA RETE HOTSPOT

Ho provato il captive portal ma non mi piace molto perchè bypassa lo squid e non puo' funzionare in modalità trasparente con quest'ultimo, quindi perdo pure i log del proxy stesso.

Una volta settate le regole:

Proto Source Port Destination Port Gateway Schedule
* HOTSPOT net * HOTSPOT net * * [traffic matching this rule is currently being allowed] Orario_Ufficio
TCP/UDP HOTSPOT net * * 25 (SMTP) * [traffic matching this rule is currently being allowed] Orario_Ufficio
TCP/UDP HOTSPOT net * * 110 (POP3) * [traffic matching this rule is currently being allowed] Orario_Ufficio
TCP/UDP HOTSPOT net * * 53 (DNS) * [traffic matching this rule is currently being allowed] Orario_Ufficio

i client wireless sono abilitati a collegarsi solo su quelle porte e solo negli orari che ho schedulato, oltre l'orario consentito la regola si disattiva e pure il traffico. Si possono ridondare queste regole con altre schedulazioni, per esempio nel week end, per disabilitare il traffico negli orari e nei giorni che si imposta.

Come ultima regola blocco tutto il traffico con:

Proto Source Port Destination Port Gateway
* * * * * *

LiquiD_85

Porca mucca :o :o :o … il giorno che saprò anch'io far lavorare insieme firewall proxy e separare le lan dalle wifi pago la cena a tutti quelli che mi hanno aiutato nel forum :D:D:D

Cmq grosso modo ci sono .. ora mi serve di capire solo una cosa, allora tu hai fatto tutto sto "bordello" (complimenti di nuovo) solo per poter controllare al meglio il traffico giusto? Cioè chiudi tutte le porte e apri solo quelle che vuoi per impedire traffico inutile ... ma se io non chiudo tutte le porte la terza scheda di rete a cui assegnerà ip fai conto 10.10.10.1 e a cui collego l'access point mi vede la scheda WAN in automatico e naviga? E si si può accedere anche alla LAN con ip 192.168 o devo bloccare il traffico a mano???grz1000

Zanotti

La tua domanda trova risposta proprio in un angolino dell'interfaccia di PfSense:

"Rules are evaluated on a first-match basis (i.e. the action of the first rule to match a packet will be executed). This means that if you use block rules, you'll have to pay attention to the rule order. Everything that isn't explicitly passed is blocked by default."

La conferma la puoi trovare anche qui: http://forum.pfsense.org/index.php/topic,7001.0.html

**_Rules:
Rules are processed from top to down.
If a rule catches the rest of the rules is no longer considered.
Per default a "block all" rule is always in place (invisible below your own rules).

Traffic is filtered on the Interface on which traffic comes in.
So traffic comming in on the LAN-Interface will only be processed by the rules you define on the LAN tab.

If you have a private subnet on your WAN: uncheck the "Block private networks" checkbox on your WAN-config page._**

Questo vuol dire che tutto il traffico che non incontra una regola apposita che ne consenta o vieti il passaggio viene droppato. Nella mia configurazione del server, su tutte le interfacce ethernet, la regola finale è sempre quella di blocco di qualunque protocollo da e per qualunque ip. Ci si puo' aiutare comunque facendo regole ad hoc che migliorano e semplificano il tracciamento del traffico nei log.

Questo come e soprattutto perchè?

La regola finale, l'ultima della lista, serve per bloccare qualunque traffico non abbia fatto match con le regole precedenti. Immaginiamo di avere un log del traffico molto grande e fitto, lasciando la configurazione a default non riesco sempre e con precisione a stabilire ( se non guardando le porte) per quale motivo un IP è stato bloccato.

Immaginiamo di avere in 3° posizione una regola che consente il traffico in entrata il protocollo SMTP, ne aggiungo subito, in 4° posizione quindi, un'altra che invece blocca il protocollo POP3. Per come è ideato PF il firewall non avrà bisogno di scorrere tutte le regole per poi scartare con l'ultima regola ( BLOCCA TUTTO ) un traffico verso POP3 ma lo farà non appena arriverà alla 4° regola.

Questo di sicuro è un vantaggio perchè il tempo di routing di un pacchetto si riduce e sui log invece di vedere il nostro, e tanti altri, ip scartato dalla regola finale, lo vedremo bloccato da una regola che avremo opportunamente commentato a dovere e più facilmente riconoscibile nel log. Lo stesso principio viene applicato in presenza di regole schedulate.

Tornando al tuo quesito, apri solo quello che ti è necessario perchè il firewall blocchera' tutto quello che non è esplicitamente consentito.

La rete 10.10.10.X ( i client wireless per inteso) che prendi in esame con le regole di defalut non potra' mai uscire tramite WAN. Ci tengo pero' a farti notare che un conto è l'ethernet che funge da gateway per i client wireless e un altro sono i client wireless stessi. Per forza di cose la scheda ethernet tramite route statiche "sà" della presenza di altre reti, ma questo non è sufficiente affinchè anche i client wireless che gestisce possano navigare verso la rete LAN o uscire tramite WAN. I client wireless se non sono informati tramite route statiche di altre reti su altre classi di IP e non potranno mai accedervi. Questo significa anche che un client wireless non potrà mai raggiungere IP della LAN o uscire tramite WAN se non c'è una regola che ne consente il traffico.

E' più facile a farlo che a spiegarlo, comunque il forum è pieno di queste informazioni, prendi ad esempio il link che ho postato. Se hai altre domande chiedi pure.

C'è una sola eccezzione a quanto scritto sopra ed è dovuto al pacchetto OpenVPN.

LiquiD_85

Grz1000 sei stato gentilissimo, scartato la storia dell'ordine delle regola del quale ero al corrente, il resto lo hai spiegato con estrema chiarezza, penso che farò così e aprirò verso la ethernet3 (clients wireless) la 80 per farli navigare e magari anche le porte per la posta, farò un po di prove in caso posterò ancora quì!! Grz1000 della tua disponibilità!!!

Ps: mi sa che devo aprire anche la 23 ve? :D grz!

Zanotti

Intendevi la 53?

LiquiD_85

Oooops si scusa la 53 :) :D

LiquiD_85

Ciao Zanotti,

sto facendo quella cosa per separare la lan dalla wifi, allora la mia configurazione è questa:

3 Schede WAN LAN e OPT1, WAN Collegata direttamente all'hag fastweb, Lan collegata a uno switch 5porte, e OPT1 collegata da sola ad un access point, ho abilitato il server DHCP su OPT1 e creato la seguente regola in OPT1

Proto Source Port Destination Port Gateway

OPT1 net * * * *

gli ip sono i seguenti:

LAN: 192.168.1.1
SNM: 255.255.255.0

OPT1: 192.168.0.1
SNM: 255.255.255.0

Il problema è che il client wireless prende l'indirizzo ip e tutto ma non pinga nemmeno 192.168.0.1 al quale è collegato direttamente tramite access point!!! Cosa ho sbagliato? Grz1000

LiquiD_85

Ho fatto una marea di prove ma niente, ho provato a cambiare il gateway per OPT1 varie regole su OTP1 su WAN ecc. niente la OPT1 non comunica con la WAN!!!

AIUTO ??? ??? ??? :'( :'( :'(

Zanotti

Allora, la regola che hai messo va bene, nel senso che abilita i client al traffico in uscita verso qualunque rete. Il fatto che tu dai client non riesca a pingare OPT1 mi fa pensare che il problema sia sull'access point wireless. Dovresti in questo caso provare a pingare da OPT1 verso l'IP dell'access point o l'IP di uno dei client wireless.

Se vai in "Diagnostics" -> "Ping" selezioni come interfaccia OPT1 e dopo l'IP che vuoi pingare. A parte il ping i client wireless riescono a navigare? riescono a risolvere un indirizzo esterno? Per caso hai una regola per bloccare tutto il traffico di OPT1 prima di quella che hai postato?

Ad ogni modo i miei timori sono che l'access point abbia un firewall integrato che blocca qualche protocolo (ICMP in questo caso). Per caso l'access point è quello di Fastweb?

Fammi sapere.

LiquiD_85

Aaaahhh che bello sentirti Zanotti :D:D

Allora raporto:

I client OPT1 non possono fare nulla sembrano come isolati possono solo pingare ed entrare nella config del acces point (Linksys WAP200)
I computer della rete LAN posono pingare tutto e tutti compresi i client wireless e la stessa OPT1
Posso pingare la OPT1 da un client wireless solo per circa 10-11secondi in fase di accensione di pfsense come se fosse una wan ???
Da diagnostic tutte le interfacce si pingano LAN->OPT1 OPT1->LAN ecc.

:(