Problema su Routing

[federicop]

Ciao, ho configurato una connessione VPN punto punto e funziona tutto.
Cioè riesco a vedere l'interfaccia web di pfsense da remoto (delle due VPN).

solo che ho un problema , ho piccolo nas con interfaccia web sulla lan "B" che non riesco a raggiungere e non capisco il perchè!

LAN "A" 192.168.0.0 - PFSENSE 192.168.0.1
LAN "B" 192.168.1.0 - PFSENSE 192.168.1.1 - NAS 192.168.1.2

se dalla lan "A" digito 192.168.1.1 entro in pfsense tranquillamente ma se digito 192.168.1.2. non riesco a vedere la pagina di accesso nas

ovviamente dentro la lan "B" digitando l'ip del nas funziona!

da che potrebbe dipendere?

[federicop]

Nessuno?

[federicop]

Help!

[federicop]

Altra cosa anomala..... se digito l'ip della pagina di login di configurazione dello switch (192.168.1.3) a volte la raggiunge a volte no.

e se vado nel firewall o in snort non trovo nessun messaggio anomalo o di blocco..

[Babiz]

@federicop Ciao , ai "tempi ho avuto gli stessi problemi, ma poi ho risolto sottoponendomi ad un "corso accellerato" da autodidatta.

Nel mio caso ho una vpn ipsec ed oltre a configurare gli endpoint della vpn stessa è necessario fornire indirizzi ip aggiuntivi sul pfsense in modo tale che il router "sappia" instradare i pacchetti attraverso le interfacce.
Ovviamente questo fà parte delle conoscenze di base sul funzionamento del pfsense e si trova quindi documentazione in abbondanza nella rete.
In parole povere sul pfsense "B" ove vi sono i dispositivi remoti da raggiungere si addano i virtual IP relativi alle subnet stesse nel mio caso in: FirewallVirtual IPs
Virtual IP Address
192.168.0.99/24 MODEM IP Alias IP for supervisor nat managing device if not respond on not the same subnet.
192.168.1.99/24 LAN IP Alias same as above
10.18.55.1/24 LAN IP Alias additional subnet for ipcam secondary ip address

Il passaggio successivo consiste nell'impostare il NAT ibrido e definire una regola di routing "manuale" nel caso si vogliano raggiungere le diverse subnet al di fuori dell'endpoint del tunnel
Firewall NAT Outbound
nella tab "Outbond" Outbound NAT Mode imposto Hybrid Outbound NAT rule generation.
(Automatic Outbound NAT + rules below)
Apparirà la sezione Mappings e quindi sarà necessario aggiungere "Add" le relative mappature per consentire al router B l'instradamento dei pacchetti, quindi fra la subnet locale e remota attraverso un' esempio del genere , nel mio caso:
Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port Description Actions
MODEM 192.168.2.0/24 * 192.168.0.0/24 * 192.168.0.99 *
LAN 192.168.2.0/24 * 192.168.1.0/24 * 192.168.1.99 *

Ecco la subnet 192.168.2.0/24 è la mia locale (router A) e quindi istruisco il router remoto per instradare i pacchetti di ritorno delle diverse subnet remote verso la mia. Facile no?

.Verificare infine le impostazioni NAT in System Advanced:
Nel mio caso da Firewall & NAT (entrambi i pfsense A e B) ho impostato la modalità "Pure NAT" su NAT Reflection mode for port forwards.
ed abilitato : Enable NAT Reflection for 1:1 NAT
ed anche: Enable automatic outbound NAT for Reflection

Spero sia tutto chiaro anche se non mi sarò spiegato alla perfezione ...
Ecco il link alla discussione originaria riguardante questo genere di cose, può darsi sia più precisa dal momento che ho scritto tutto a memoria non vorrei aver omesso qualche dettaglio: https://forum.netgate.com/post/733613

[federicop]

@Babiz ...... ora leggo ciò che hai scritto, ma per velocità e brevità non ho scritto alcune cose.

VPN creata con OpneVPN ed è la terza sede collegata, in sostanza avevo già la Sede A e B collegate tra loro con lo stesso sistema, creati i Routes ecc e funziona tutto, mentre sulla sede C, nonostante sia tutto configurato in maniera identica non riesco ad accedere o ad avere problemi.

ora però leggo i tuoi suggerimenti e ti dico

[federicop]

Allora... ho letto ciò che hai scritto e io attualmente ho:
Firewall NAT Outbound
Mode Automatic - sia sul server A sia sui client B e C
Firewall & NAT
NAT Reflection mode for port forwards - disabled
Enable NAT Reflection for 1:1 NAT - disabilitato
Enable automatic outbound NAT for Reflection - disabilitato

Ripeto che avendo due "client" B funziona perfettamente e C no! (esempio a volte mi apre la pagina login dello switch altre no!
Aggiungo che la pagina di login del psfsense B e C la raggiungo tranquillamente e ci lavoro pure.

[Babiz]

@federicop ok potrei ipotizzare che un tunnel ipsec o ovpn una volta stabilito sia "analogo"

Il punto che devi considerare, l'instradamento dei pacchetti "di ritorno" dalle sedi remote non avviene in automatico (considerando IPsec) se non lo si imposta appunto in modo esplicito.

Il fatto che tu riesca a gestire i vari pfsense e non i device collegati alle varie subnet, dipende proprio da questo.

Quando tu stabilisci una connessione TCP ad esempio attraverso il tunnel, il router remoto tiene traccia della route (ma il servizio attestato sulla subnet remota non può risponderti correttamente se non specificando esplicitamente un virtual IP ed una regola di nat ibrido, opportuna, in maniera tale che la comunicazione sia stabilita in entrambi i sensi.

Usando il tool Diagnostic / Packet Capture puoi verificare tu stesso su entrambi i router (locale e remoto) questo comportamento e dove i pacchetti si "perdono".
Prova perciò a configurare sulle sedi remote un virtual IP (fuori dal range dei lease dhcp), il nat ibrido ed aggiungi le regolette di routing come da mio esempio , logicamente adattate alle tue subnet.

Il funzionamento sui tunnel IPsec in questo modo è garantito, riguardo i tunnel ovpn anche se utilizzano protocolli completamente differenti dovresti ottenere gli stessi risultati, però non mi sento di affermare ciò con certezza assoluta in quanto anche la gestione del routing fra tunnel ovpn è probabilmente più "automatizzata" rispetto ad IPsec.

Altra cosa che mi viene in mente.. è tipo buona norma non avere subnet duplicate nelle reti gestite , per evitare possibili "confusioni" (quindi potrebbe essere impossibile gestire più di due sedi remote)
Penso sia ovvio impostare subnet univoche sulle sedi remote e locali. Ed anche tunnel univoci.

Ma questo è solo un tipo di approccio possibile, probabilmente il protocollo ovpn permette di giocare con più flessibilità , mi vien da pensare che sia possibile ottenere su un'unica subnet "di gestione" la comunicazione punto-multipunto, il che comporterebbe probabilmente l'impiego di VLAN in sedi remote e configurazioni ovpn specifiche.
Purtroppo su ovpn non sono assolutamente ferrato, anche perchè mi trovo benissimo con IPsec per quello che debbo gestire io.

Saluti

[federicop]

This post is deleted!

[federicop]

Confermo che ho subnet differenti...

seguendo il tuo ragionamento però non riesco a capire perchè avendo avendu subnet differenti e tutto il resto configurato identico una sede la raggiungo e lavoro tranquillamente l'altra no!

[Babiz]

@federicop Mmm beh c'è poco da capire se non tocchi con mano, usa DiagnosticsPacket Capture sulla sede remota , seleziona l'interfaccia lan il protocollo TCP e l'host address che fa capo ad es. ad un tuo switch managed remoto con livello del log Medium, avvia la cattura.
Dalla sede locale apri la pagina di configurazione dello switch e fai il login.
Passa nuovamente alla pagina DiagnosticsPacket Capture sulla sede remota e stoppa la cattura.
Apparirà un log della comunicazione tipo questo:
https://pastebin.com/fch8td7K

Da qui puoi evincere che la comunicazione non avviene direttamente fra subnet locale e remota ma resta "trasparente" per il dispositivo da configurare in remoto, il quale comunica solo con il VIP del pfsense impostato (192.168.0.99) e quindi la palla passa al router che si occupa di traslare gli indirizzi IP delle diverse subnet (impostando opportunamente una voce di routing manuale in Firewall / NAT -> Outbond ( Con NAT Ibrido attivo)

e non potrebbe essere altrimenti, perchè per poter funzionare cioè per poter stabilire una comunicazione, spesso e volentieri le interfacce web degli apparati "managed" sono programmate per funzionare esclusivamente all'interno delle loro subnet..

quindi non risponderebbero in ogni caso a richieste provenienti da subnet diverse, da qui la necessità di impostare un VIP ed una regola di routing NAT ibrida.

Penso comunque che se il discorso routing +ovpn ti funziona sulla prima sede ma non sulla seconda senza niente di tutto ciò, impostato...
allora il problema è probabilmente nella configurazione ovpn.

Comunque con il sistema del packet capture puoi confrontare tu stesso i risultati provenienti dalle diverse sedi e quindi agire di conseguenza.

Puoi anche selezionare l'interfaccia ovpn e guardare cosa ci transita nel mentre fai la richiesta di login al dispositivo managed remoto, per dire, ti servono più informazioni per poter eliminare via via le possibili cause del problema, anche un'occhiata ai log di sistema non guasta

[federicop]

@babiz ho provato ad impostare la tua configurazione (su openvpn) e il risultato del DiagnosticsPacket Capture è

21:51:31.127049 IP 192.168.0.60.64200 > 192.168.6.125.80: tcp 0
21:51:31.127235 IP 192.168.6.125.80 > 192.168.0.60.64200: tcp 0
21:51:31.127362 IP 192.168.0.60.64201 > 192.168.6.125.80: tcp 0
ecc.....

ergo non comunica.....

ho provato a riguardare la configurazione server VPN ma mi sembra tutto apposto e identica all'altra, salvo subnet differenti

[Babiz]

@federicop ciao, si mi sembra abbastanza normale che non cominichi come ho già scritto in precedenza le webui degli switch a volte non sono "progettate" per rispondere a request http fuori dalla loro subnet.

per "imbrogliare" tali webui troppo zelanti, una soluzione è quella di assegnare un VIP ed instradare tramite NAT Ibrido la comunicazione, lavoro che il pfSense di suo esegue egregiamente, (sui miei APU attualmente accedo a qualsiasi interfaccia "dispettosa" eheh.

Direi che puoi provare a configurare il pfSense con tale "metodo" se vuoi far funzionare la gestione di questi dispositivi da remoto, oppure buttare via tutto ed affidarsi ad un sistema cloud tipo Ubiquiti che non necessita di configurazioni di routing particolari per la gestione dei dispositivi eh.

Allego la schermata di come dovrebbe apparire la tabella del NAT ibrido necessaria per comunicare attraverso le diverse subnet, ovviamente con i rispettivi VIP già impostati in precedenza.

Questo è il mio setup remoto (il mio ip locale è nel range 2.0/28 ma la minestra è la stessa.

[federicop]

@Babiz io continuo a non capire una cosa....

Come detto ho due sedi client e sulla una delle due funziona tutto e sull'altra no! e soprattuto l'interfaccia web dello switch a volte funziona altre no... se non funzionasse senza ip virtuale come indichi te non dovrebbe funzionare mai.

altra cosa, se abilito il nas a file manager e dalla sede "server" digito \192.168.x.x (ip del nas) se fosse solo un problema di gestione web, dovrebbe aprirmi le cartelle, in realtà non lo fa.
Ho controllato anche le impostazioni di sicurezza del NAS per scongiurare che ci fosse qualche impostazione che bloccasse, ma è tutto ok.... comunque riprovo a impostare come dici te anche se con il primo tentativo non ha funzionato

[federicop]

@babiz io ho impostato un VirtualIP 192.168.6.125 (che è lo stesso che nella lan sede client B corrisponde al NAS)

poi imposto quanto segue, ma stranamente dalla lan server se digito 192.168.6.125 mi restituisce la pagina di login di pfsense

[Babiz]

@federicop ciao, allora se vuoi provare ad impostare una regoletta di nat ibrido con il suo vip devi fare le cose per bene eh.

Il vip non deve corrispondere a nessun ip già assegnato nella lan della sede remota e di solito si imposta al di fuori del range del pool dhcp .
Se imposti un vip sulla sede remota avente lo stesso ip di un host esistente, della sede remota, non fai altro che creare un problema di routing aggiuntivo.

Nel mio esempio i vip sono impostati per le varie subnet a 192.168.x.99 y.99 z.99 ecc considerando che ho impostato il campo dei pool dhcp partendo da 192.168.x.100 a 192.168.x.254 in modo tale da avere indirizzi ip liberi e non duplicati in rete (gli ip duplicati interferiscono nelle tabelle arp rendendo impossibile associare in modo univoco gli host al MAC address. Quindi ora devi impostare un corretto vip e controlla anche la tabella arp del pfSense remoto, che non contenga voci con indirizzi ip duplicati che puntano a mac diversi.
Il vip correttamente impostato fà sempre capo al indirizzo mac della interfaccia relativa , sul pfsense.

[federicop]

@Babiz

Devo configurare anche un VIP anche per la WAN? da come ho capito non serve... se non voglio raggiungere ip delle WAN.
Non ci sono duplucati... ho allegato lo screen di una configurazione provata, ovvero avevo provato anche con un ip non assegnato nella lan.

[Babiz]

@federicop ok, le "Auto created rule" servono per far funzionare i tunnel e non si possono cancellare ovviamente.
Non servono regole aggiuntive sul lato wan dal momento che tutto il traffico viene instradato attraverso il tunnel al limite ci si assicura che sia presente una regola "any to any" su entrambe le interfaccie del tunnel locale e remoto (sotto Firewall / Rules), il routing è automatico in questo caso, almeno qui da me funziona così!

Ho perplessità riguardo il tunnel ovpn perchè immaginando lo scenario peggiore , non vorrei vi fossero delle impostazioni specifiche del protocollo che vanno a "sovrapporsi" a quelle generate dal sistema in automatico, rendendo così la comunicazione fra i siti remoti , per così dire "intricata" .
Purtroppo il funzionamento di questa "tecnica" posso garantirtela solo attraverso l'mpiego un tunnel ipsec basilare e relative "phase2" impostate coerentemente sulla sede remota.

Mi viene da pensare che nel caso di ovpn , siccome ho una vaga idea di come funziona, sarebbe più conveniente per te impostare relativo server sulla sede remota con endpoint nella tua subnet 6.0/24, in modo che dalla tua sede locale attraverso il client ovpn venga stabilita una connessione alla subnet specifica. Sono a conoscenza del fatto che ovpg gestisca in modo "elastico" i vari tipi di routing possibili e che esistano almeno un paio di metodi diversi per la creazione di tali tunnel i quali offrono opzioni di routing differenti a seconda delle proprie esigenze.
Magari se ho un pò di tempo mi ripasso i principi fondamentali del protocollo ovpn :D non si sà mai che mi giunga l'illuminazione!
Ciao.

[federicop]

@babiz said in Problema su Routing:

a.
Confermo che la soluzione non funziona

[Sandokan]

Con OpenVPN i network da raggiungere vanno elencati in "IPv4 Local network(s)" nella configurazione del server, e possono essere più di uno. Temo che se c'è indicata solo LANA, LANB sia (correttamente) irraggiungibile quando connessi a LANA.

[Babiz]

Ciao, concordo con te a riguardo è probabilmente la prima cosa da verificare, purtroppo sembra non esserci stata una grande collaborazione da parte di chi aveva tale problema.
(cioè se ad esempio avessi un dubbio per risoòlverlo cercherei di darmi da fare, postare una configurazione, fare delle domande specifiche e pertinenti e così via in modo da "venirne fuori" in qualche modo)
In questo caso ciò non è avvenuto e a mio avviso la sensazione è stata tipo quella di esser di fronte a chi "vuole la pappa pronta". (oltre che una perdita di tempo)
Pertanto ho ritenuto opportuno accantonare la discussione, giacchè non ritengo la "pappa pronta" una pratica condivisibile sopratutto a livello di forum e community.
Il nostro amico @federicop ha ancora molta strada da fare sotto questo punto di vista.
Beninteso @Sandokan sei assolutamente libero di aiutare e dare la pappetta a chi meglio credi, se ciò ti rende felice.

Resta un dubbio riguardo a questo thread perchè ciò che "richiede" il nostro amico , rientra comunque nel bene e nel male fra le pratiche basilari penso del networking e del routing e quindi ne deduco che tale problema potrebbe perfettamente risolversi "da solo" dopo una buona lettura di una qualsiasi guida relativa al protocollo ovpn.
Saluti.

[federicop]

@babiz liberissimo di pensarla come credi, e quindi di "accantonarmi" ma questo non vuole dire che tu abbia ragione.
Però strano non capisco perchè se mi hai "abbandonato" hai scritto queste cavolate e sopratutto te che sei uno psicologo di forum non abbia capito che magari @sandokan non la pensa come te.

Infatti le tue sensazioni sono totalmente sbagliate!

Ho postato configurazioni e ho fatto domande specifiche però devo ammettere che hai ragione quando dici che di strada ne ho da fare (come tutti), ma invece ha la sensazione che il tuo è il tipico atteggiamento di chi pensa di sapere tutto, poi alla primo intoppo dice che è colpa degli altri.

Se basta "studiare" come dici te, perchè te che hai studiato non sei riuscito a darmi direttive giuste?
Inoltre se basta studiare i forum che li facciamo a fare, teoricamente dovremmo saper far tutto!

Forse perchè ci possono essere mille problemi e magari un confronto con altri ti fa accendere la lampadina?

Comunque, la realtà è che non voglio la pappa pronta (per mia natura) infatti anche in questo caso pfsense me lo sono studiato e scaricato installato e configurato (senza il tuo aiuto), postando qualche richiesta di help ogni tanto come molti; ma facendo altro di lavoro avendo solo la passione dell'informatica non ho sempre tempo di approfondire tutto e magari qualche esperto riesce a darmi la dritta giusta.

E anche le configurazioni VPN le ho fatte leggendo e capendo il funzionamento, ma se ho un dubbio come devo fare?

Saluti

[federicop]

@sandokan IPv4 Local network(s)" nella configurazione del server OpenVPN non c'è.

ho solo IPv4/IPv6 Tunnel Network - IPv4/IPv6 Remote network(s)

e sapevo di questa funzione e della possibilità di mettere più di un ip, infatti avendo due sedi client avevo aggiunto nel IPv4/IPv6 Remote network(s) il secondo ip ma stranamente no funzionava quindi ho dovuto creare un nuovo server su un'altra porta.

Ho configurato un client specific Overides ma instradando il IPv4/IPv6 Tunnel Network non il Local....

[Sandokan]

@federicop

Che versione di pfSense stai utilizzando? Sulla 2.4.4 " IPv4 Local network(s)" è sotto "Tunnel Settings". Dal punto di vista del server VPN, i network "locali" sono quelli lato server, mentre quelli "remoti" sono quelli oltre il tunnel, cioè quelli lato client. Nel tuo caso, da quello che ho capito (ma dettagliare la configurazione sarebbe sì utile), sia la LAN A che quella B sono lato server, quindi nell'elenco dei network locali raggiungibili tramite il tunnel vanno indicati tutti e due. Metterli in remote networks non funziona, perché il server VPN in quel caso pensa che siano sull'endpoint remoto, e ruoterebbe sul tunnel i pacchetti lì destinati.

La documentazione esplicitamente dice di non usare le normali rotte statiche, ma di utilizzare IPv4 Local Network(s). Ha senso perché un utente VPN potrebbe non dover avere accesso a tutte le reti della destinazione, ma solo ad un sottoinsieme.

LAN B comunque deve avere una rotta con un gateway che inoltri i pacchetti al pfSense per inviare il traffico alla rete remota della VPN (attenzione ad eventuali sovrapposizione degli indirizzi di rete...)

Aggiornamento.... ho appena fatto un test:

pfSense configurato come segue:
WAN: 192.168.201.2 (ha davanti un altro router WAN con l'IP pubblico)
LAN: 192.168.200.10
OpenVPN: 192.168.150.0/24

LAN è collegata ad uno switch L3 (192.168.200.1, che si occupa del routing) con le subnet (su opportune VLAN):
192.168.200.0/24
192.168.10.0/24

il pfSense è il default gateway per lo switch (sull'interfaccia LAN), mentre il pfSense ha ovviamente le rotte per le subnet gestite dallo switch, con l'indirizzo dello switch come GW.

Create una configurazione piuttosto "standard" di OpenVPN - tutti parametri di default - e inserite le subnet in "IPv4 local networks", con il filtro di default any/any sull''interfaccia OpenVPN, raggiungo senza problemi un NAS posizionato sulla subnet "10".

Se non inserisco le subnet, non ci accedo, anche perché le rotte non vengono nemmeno inserite nella routing table del client.

[federicop]

Allora:
PFsense client 2.3.5-RELEASE-p2 (i386)
PFsense server 2.4.4-RELEASE (amd64)

Posto la configurazione server

Client:

Se non ho capito male ciò che hai scritto dovrei aver configurato come dici te....

[Sandokan]

Ma ti funziona così, o ancora no?

C'è una cosa interessante... se setti Server mode a "Peer to peer (SSL/TLS)", che è la modalità che uso per maggiore sicurezza, appare la voce "IPv4 Local Network(s)". Se invece la imposti a "Peer to peer (shared key)", la voce sparisce. Non lo avevo notato, mi dispiace di aver creato confusione, a questo punto.

Effettivamente c'è un nota nel pfSense Book che spiega che utilizzando i certificati le rotte sono "pushate" dal server verso i client, mentre con le pre-shared key questo non è possibile e le rotte vanno definite su entrambi i lati come necessario.

La tua configurazione, se le reti sono quelle corrette per i due lati della VPN, dovrebbe essere a posto.

Riporto l'esempio nel "pfSense Books", che è il seguente:

SitoA: 10.3.0.0/24
SitoB: 10.5.0.0/24
Tunnel: 10.3.100.0/30

Il SitoA (10.3.0.0/24) ospita il "server" OpenVPN:

"Tunnel network" è impostato a "10.3.100.0/30"
"Remote network(s)" è impostato a "10.5.0.0/24". Questo fa sì che il pfSense server sul SitoA sappia che i pacchetti per la rete "10.5.0.0/24" del SitoB vanno ruotati sulla VPN.

Il SitoB (10.5.0.0/24) ospita il "client" OpenVPN:

"Tunnel network" è impostato a "10.3.100.0/30"
"Remote network(s)" è impostato a "10.3.0.0/24". Questo fa sì che il pfSense client sul sito B sappia che i pacchetti per la rete "10.3.0.0/24" del SitoA vanno ruotati sulla VPN.

(Notare che essendo subnet /24 10.3.0.0 e 10.3.100.0 sono subnet separate)

Se ci sono altri network sui due lati da raggiungere, vanno indicati. Bisogna anche assicurarsi che i gateway delle macchine che devono comunicare sulla VPN inoltrino correttamenteil traffico verso i pfSense.

Puoi verificare le rotte sui due pfSense con "Diagnostics > Routes", appaiono come interfacce "tun" o "tap". Puoi provare il ping da varie interfacce del pfSense sempre da "Diagnostics", per cercare di capire dove si interrompe la comunicazione.

Ovviamente ci devono essere le opportune regole di firewalling per far passare il traffico VPN.

Se il NAT Outbound è su auto, dovrebbe funzionare senza problemi. Per regole più complesse, è necessario associare l'interfaccia OpenVPN ad una interfaccia OPT, ma non è strettamente necessario (tranne nel caso di reti con indirizzamento sovrapposto sui due lati)

[federicop]

è pi sicura la Peer to peer (SSL/TLS)??

ma quale dispiacere!!! grazie del tempo che dedichi!

la VPN funziona infatti raggiungo il server dal client e viceversa, solo che da server verso client non riesco a raggiungere l'interfaccia web nas oppure la directory nas della cartella condivisa, e se prendo un'altro apparato con interfaccia web, tipo lo switch una volta mi compare e altre no!

le regole sono *
il NAT Outbound è su auto

ecco perche mi sembra tutto ok non riesco a capire dove sta il problema! ora faccio anche le prove diagnostic

[federicop]

[Sandokan]

La tabella di routing dice poco ad un "estraneo" se non sai di quale macchina è , quali sono le subnet da una parte e dall'altra, e quali indirizzi sono assegnati a cosa, in particolare alla WAN, alle LAN :). Vedo che ci sono divese reti e subnet.

L'indirizzo del NAS è quello del primo post? Perché nei remote networks della VPN la subnet 192.168.1.0/24 non c'è, ma l'indirizzo 192.168.1.2 nella tabella di routing appare assegnato all'interfaccia di loopback, è un indirizzo assegnato ad una interfaccia del pfSense o del NAS?

192.168.1.1 è il default gateway del pfSense, ma non mi è chiaro a quale macchina faccia riferimento, come sono collegati i due siti?

Sarebbe utile uno schema preciso dei network e delle assegnazioni IP.

Comuqnue, per capire dove si bloccano i pacchetti, procedi così: vai in Diagnostic -> Ping, e partendo dall'interfaccia LAN alla quale è collegato il NAS, vai a ritroso, e vedi quando non risponde più.