Indirizzi IP bloccati improvvisamente
-
@keen Hi Keen, version 2.4.5-RELEASE-p1
-
le regole nel port-forwarding sono corrette?
-
@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 succededebug 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? -
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. -
@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 correttamentesembra 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-ipsecda terminale
cat /tmp/rules.debug | grep *ipbloccato*e verifica se risulta inserito nell'alias
verifica che pfctl abbia le regole configurate
pfctl -s rules -
@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. -
@cloudfacilesrl
ottimo, grazie per aver riportato la soluzione -
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. -
@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
-
@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 -
@cloudfacilesrl potresti provare a installare in un ambiente di test, la versione 2.5.0 di pfsense per vedere se il problema si risolve
