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.