Esce pfSense 2.1

E' stato annunciato oggi pfSense 2.1, la nuova major release del sistema di firewalling, routing, vpn basato su FreeBSD: Fra le varie novità di networking si trovano un aumentato supporto per IPV6 e anche il supporto nativo al formato PBI (Push Button Installer) creato per PCBSD.

La release note ufficiale si trova qui.

pfSense & OpenVPN: verify error

Se pfSense rifiuta una conessione OpenVPN con certificati fornendo un VERIFY ERROR simile al seguente:

VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: 

/C=IT/ST=Italy/L=Sassuolo/O=MySite/CN=MySite_CA/emailAddress=xxx@xxx

significa che si è fatta confusione con i certificati e che si sta usando il certificato del server al posto del classico ca.crt (certificato che garantisce quello del server) nella configurazione del client OpenVPN.

pfSense & Timezone: problemi al firewall

pfSense ha un problema di sincronizzazione dell'orologio di sistema quando si cambia TimeZone: in sostanza se viene cambiata l'ora di sistema si ha che quasi tutti i processi si allineano alla nuova ora, mentre il filtro/firewall no. Questo potrebbe produrre alcuni problemi quando si hanno delle regole di filtro basate sul tempo (ossia con uno scheduler). Come spiegato qui, è bene riavviare l'intero firewall per aggiustare il tempo.

pfSense e migrazione DHCP

pfSense è un'ottima distribuzione firewall, ma che anziché basarsi sui file di configurazione classici dei demoni e dei servizi, salva la propria configurazione in un file XML che viene letto e interpretato dalla interfaccia PHP/Web e che viene poi tradotta nei file di configurazione di ogni servizio. 

Se da un lato questo è utile, dall'altro la migrazione da una piattaforma diversa da pfSense ad una pfSense richiede un editing manuale della configurazione o la conversione dei file di configurazione in un formato XML-compatibile. Io ho creato un piccolo e semplice script Perl che consente di migrare le porzioni di mapping statico ARP-IP di un file dhcpd.conf nel formato XML. Lo script è pubblico e disponibile direttamente nel forum di pfSense.

Vodafone UMTS e connessioni IPSec

Sono letteralmente diventato matto nel tentativo di far funzionare una connessione IPSec da un client mobile (Shrew) verso una box pfSense. Il problema, scoperto dopo diversi tentativi, è che la Vodafone blocca il traffico UDP, forse pensando che possa servire per fare un peer-to-peer illegale. Siccome IPSec necessita di UDP nella fase 1 (IKE), quello che succedeva era il nulla: nessun traffico raggiungeva la box pfSense.

La soluzione allora è stata cambiare da IPSec a OpenVPN, che può funzionare arbitrariamente su UDP o TCP, e infatti la connessione via TCP funziona anche con chiavetta Vodafone!

pfSense & VPN: Failed to get sainfo

Qualora dovesse apparire nei log di pfSense il messaggio Failed to get sainfo quando si tenta di avviare un tunnel VPN occorre ricontrollare la fase 2 della creazione del tunnel. Se tutti i parametri della fase 2 combaciano fra i due concentratori VPN, allora è probabile che ci sia un problema nella definizione delle reti locale/remote o della relativa sottomaschera di rete.

Per individuare con esattezza l'errore occorre disabilitare IPSEC nella relativa schermata di configurazione, effettuare il login shell sulla macchina pfSense ed avvaire il comando:

racoon -F -d -v -f /var/etc/racoon.conf

che altro non fa che avviare ipsec con le informazioni di configurazione. A questo punto, quando si inizia a creare il tunnel si vedrà un messaggio simile al seguente:

 010-05-07 10:23:08: DEBUG: getsainfo pass #2
2010-05-07 10:23:08: DEBUG: check and compare ids : value mismatch (IPv4_subnet)

che indica che le due reti definite fra i due endpoint sono differenti da quelle che ci si aspetta nel tunnel.

Una volta corretto il problema, è possibile testare il tunnel direttamente dalla macchina pfSense con il comando:

ping -S

pfSense e default drop all su static route

Ho montato un firewall pfSense dotato di regole di static routing sulla stessa interfaccia: i pacchetti destinati alla rete X venivano smistati in ingresso e uscita dall'interfaccia LAN del firewall. Eppure i pacchetti non passavano, e dopo qualche secondo la connessione veniva interrotta. Il problema è nello state analyzer del firewall, che dopo qualche secondo si accorge del traffico da e per l'interfaccia LAN e blocca la connessione. La soluzione è quella di abilitare la voce Bypass firewall rules for traffic on the same interface dal menu' System->Advanced. In questo modo pf non considera lo stato dei pacchetti che viaggiano sulla medesima interfaccia e non getta la connessione.