Indirizzi IP bloccati improvvisamente

Cloudfacilesrl

Buongiorno a tutti, illustro rapidamente come abbiamo configurato i nostri firewall per poi spiegarvi il problema che riscontriamo.
Nella sezione NAT avevamo creato tempo fa delle regole dove il source era un single host che faceva riferimento ad un ALIAS contenente tutti i nostri IP pubblici, in tal modo soltanto quegli indirizzi IP dall'esterno potevano accedere alle varie risorse interne.
Ha sempre funzionato tutto alla perfezione, questo per anni.
Da 3 giorni contemporaneamente, su tutti i firewall, alcuni dei nostri IP (presenti negli ALIAS) sono stati bloccati dai firewall, mentre altri (sempre presenti negli ALIAS) continuano a funzionare.
Ho guardato i log e ho trovato questa riga:

Default deny rule IPv4 (1000000103) Source (nostro IP) - Destination (IP del firewall)

Dopo ho guardato in pfinfo e ho trovato DEBUG: URGENT

Checksum: 0xfe83eeb60f319d646f21d2e0c1520497

In ogni firewall c'è questa dicitura, cambia ovviamente il valore del Checksum.

Sembrerebbe che tutti i firewall (hardware diversi in posti diversi) abbiano avuto contemporaneamente un problema di scrittura o lettura delle tabelle, infatti alcuni indirizzi inseriti negli ALIAS venivano ignorati e il firewall a quel punto li bloccava.
Essendo impossibile che tutti i firewall contemporaneamente abbiano riscontrato lo stesso problema, tendo a pensare che si tratti di un'anomalia di pfSense o del Browser (Chrome).

Chiaramente ho verificato che le tabelle a livello di righe avessero un valore sufficientemente alto e ho provato anche ad azzerare i logs con il comando: clog -i -s 511488 /var/log/nomelog.log
Dopo ho fatto anche un Tables reload.
Questo ha temporaneamente risolto il problema, ma il giorno dopo si è ripresentato.

Qualcuno di voi ha riscontrato lo stesso problema e ha trovato qualche soluzione ?

Grazie a chiunque voglia aiutarmi.
Buon lavoro a tutti.

keen

io proverei a fare un reset di tutte le connessioni
da Diagnostics States --> Reset States

come seconda soluzione se uptime del firewall è alta farei un reboot completo

Cloudfacilesrl

@keen Hi Keen, I've already done these operations. The problem returns after a while.
I would like to understand why it is and also fine a definitive solution.

keen

quale versione software state utilizzando ?

Cloudfacilesrl

@keen Hi Keen, version 2.4.5-RELEASE-p1

keen

le regole nel port-forwarding sono corrette?

kiokoman

@cloudfacilesrl
servirebbe uno screenshot di quel blocco,
che flag hanno ? TCP:FA / TCP:FPA ?

1000000103 di solito esce quando la comunicazione viene per qualche motivo interrotta cioè quando i pacchetti arrivano ma lo "State" è già stato chiuso
sintomo di connessione intermittente o connessioni asimmetriche o problema di routing
detta così' è difficile capire cosa succede, dovresti usare wireshark / packet capture per vedere cosa succede

debug urgent checksum non e' di alcun aiuto, quella è una scritta che abbiamo tutti, e sotto ci sono le statistiche di pf (packet filter) di freebsd per le interfacce

serve screenshot o copia/incolla dei log system e gateway
controlla anche se i servizi siano tutti funzionanti correttamente
hai pacchetti aggiuntivi installati? diagnostic system activity mostra processi con alti usi di risorse?

Cloudfacilesrl

Hi, The flags are S or SA.
Now I've done a test and the problem is definitely in the NAT and ALIAS tables.
In practice I have 2 ALIAS, in one there are 4 addresses 2 IP and 2 FQDN, in the second ALIAS there are 20 addresses almost all IP and 3 FQDN.
I use these ALIAS in a simple NAT rule that allows only the IPs inserted in a specific ALIAS to connect via RDP (on masked ports) to resources present in our various datacenters.
These rules have been like this for over a year, but for 3 days some of the IPs contained in those ALIAS have been blocked.
Now I tried to create a new ALIAS with the same IPs as the one in which there are addresses that are blocked, I associated it with the NAT rule by replacing it with the previous ALIAS and now the IPs that were blocked connect normally.
This means that the firewall is not reading certain tables correctly.
The strange thing is that this has happened on all the firewalls we have, and they are hosted on different hardware, in different places and with different connectivity. The firewall of one of our customers (who is therefore outside our networks) had the exact same problem.

kiokoman

@cloudfacilesrl
ok TCP:S è un problema ..
Default deny rule nell'interfaccia WAN è normale,
significa che per qualche motivo la regola di NAT/ pass non funziona o non legge/popola gli ALIAS correttamente

sembra che in questa discussione ci sia qualcuno che ha un problema simile al tuo:
https://forum.netgate.com/topic/158959/trouble-accessing-sg-1100-web-ui-via-ipsec

da terminale

cat /tmp/rules.debug | grep *ipbloccato*

e verifica se risulta inserito nell'alias

verifica che pfctl abbia le regole configurate

pfctl -s rules

Cloudfacilesrl

@kiokoman Ho risolto il problema, non dipendeva nè dalle tabelle ALIAS o NAT, nè da altre regole di firewall.
Il problema si verifica quando l'MTU lato WAN per qualche ragione varia, infatti prima era impostato a 1470 (valore che ci avevano comunicato i nostri provider), mentre adesso l'ho lasciato blank quindi 1500 come default ed il problema non si verifica più.
Sarebbe utile da parte di pfSense, in caso di problemi legati alla continuità del flusso dei pacchetti, indicarelo in modo più specifico sulla riga del log altrimenti con indicazioni troppo criptiche si complica la vita a chi deve fare il troubleshooting.

kiokoman

@cloudfacilesrl
ottimo, grazie per aver riportato la soluzione

Cloudfacilesrl

Purtroppo la soluzione ha avuto vita breve, dopo alcune ore dalla taratura dell'MTU il problema si è ripresentato e non riesco proprio a capire cosa infastidisca pfSense.
Gli IP bloccati sono relativi a connettività utilizzate da anni, sempre uguali e che non hanno subito alcuna modifica, quindi non capisco perchè pfSense si accanisca col protocollo TCP:S perchè i pacchetti di dati viaggiano sempre allo stesso modo.

keen

@cloudfacilesrl se possibile, mi rendo disponibile per collegarmi sul firewall da remoto e provare ad aiutare...o magari sharare il desktop e vedere la configurazione

Cloudfacilesrl

@keen grazie della disponibilità, ma ho postato il problema anche sul forum firewalling e non sono l'unico ad aver sicontrato quello che alla fine si è rivelato un bug. Allego il link al post, dal quale si può poi accedere ad un altro post per lo stesso problema e al momento non c'è ancora una soluzione ufficiale.
La soluzione al momento è quella di creare tabelle ALIAS separate suddividendo gli indirizzi IP e quelli FQDN e soprattutto non inserendo gli FQDN in più di una tabella.
A questo punto bisognerà duplicare le regole e pfSense non dovrebbe più non scrivere correttamente le tables.
Certo questo rappresenta un problema serio a livello di security in quanto non potendo inserire un indirizzo FQDN in piú di una tabella ALIAS, gli indirizzi FQDN sarebbero tutti autorizzati anche su regole in cui non dovrebbero esserlo.
Vedremo se e quando arriverá una patch.
link text

keen

@cloudfacilesrl potresti provare a installare in un ambiente di test, la versione 2.5.0 di pfsense per vedere se il problema si risolve