Netgate SG-1000 microFirewall

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - webmst

Pages: [1]
(for the umpteenth time...)

Almost every time I perform an hw (and pfsense) upgrade, after reloading an old configuration, I consequently realize I cannot access the System-Update-Update_settings tab anymore. If I try, I get a "504 Gateway Time-out error".

I can solve the problem restoring "factory defaults" but when I reload the old configuration, it comes back.

It is obviously a configuration issue but - as setups are very complex to be manually re-entered from scratch - I'm wondering if I can amend the config.xml file.

In trying to figure out what's missing in my old configuration files, I noticed they're always missing the "firmware", "gitsync" and "pkg_repo_conf_path" keys/values in the "system" key from config.xml (all recalled in system_update_settings.php).

As nobody modified config.xml manually before, I suppose these keys got lost during some recent upgrade process, so I think this could be a workaround for many other users upgrading older systems experiencing the same issue.

Can anybody please supply an excerpt of a working config.xml file for the afore said keys in order me to restore proper operation?

Thanks in advance.

Packages / Re: No available packages (empty list)
« on: September 29, 2017, 07:15:38 pm »
Hi Gertjan,
the problem was permanent, a simple reboot didn't work.

The problem was (because I've already solved it with a system+package reinstallation, that eventually went fine) due to a pkg-related sqlite database error that - despite applying the raccomandations given in other threads (i.e. forced update/upgrade of the system) - didn't solve the issue (and most of all, they were lenghty to execute).

As the issue was created immediately after installation with no warning, I consider this solution a defeat. As a matter of fact, we still don't know the cause but the reinstallation was surely the fastest way to solve: I already know the beast.

At the current state of the art and from my viewpoint, there has been a considerable loss of performance (mostly on pfsense boxes installed on nanobsd-powered embedded devices) and stability (as it is witnessed by the large number of threads in the forum about this topic) after the introduction of the pkg-based system upgrade/package management method.

Packages / Re: No available packages (empty list)
« on: September 28, 2017, 12:50:05 pm »
Other symptoms:

accessing the 'update' function from the 'system' menu in the gui, it says "up to date", but trying to display the 'update settings" I get a "50 GAteway Time-out" blank screen from ngix (so I cannot try to change the repository source)

Packages / Re: No available packages (empty list)
« on: September 28, 2017, 12:39:39 pm »
I am right in saying that all of this is due to the new pkg-based system & packages install/upgrade method.

Infact, trying manually from the shell, I cannot install anything via pkg too, getting the following error:

pkg: Repository pfSense-core load error: access repo file(/var/db/pkg/repo-pfSense-core.sqlite) failed: No such file or directory

Still, I don't understand why the packaging system isn't creating the new .sqlite file when it relizes it doesn't exist (as it was pointed out in other forum topics).

Not to mention that this is a fresh install and that I've already seen this happening with full installs on a VM and with nanobsd imgs on an embedded device; from my viewpoint it happens randomly.

I think this problem is still to be well analyzed and addressed.

All I can do to fix it quickly it to reinstall... and cross my finger for the next "package install" time.

Packages / No available packages (empty list)
« on: September 27, 2017, 06:36:16 am »
Hi folks,

I'm still finding the following problem since the change of the system upgrade/package management (last year, now based on the slower "pkg" method).

Again, on a fresh 2.3.4-p1 install (it happens on both a VM full install and an embedded device) I encounter a empty list on "available packages", after having already installed some with no errors.

Has anybody any ideas?
Thanks in advance.

Installation and Upgrades / Re: Unable to update repository
« on: May 17, 2017, 09:07:26 am »
In the meantime, in order to address this issue thourougly, I cloned my pfSense system, updating it to 2.3.4 (so we can exclude any CF problem) and installing on a VMWARE esxi 6 and - again after almost 2 weeks - I get similar symptoms: the update check on the GUI, the access to the update page on the GUI, the 'pkg update' from shell have become extremely slow (>5 min) even when executed on a fast piece of hardware; IMHO this explains all the time-outs / aborted procedures previously found on the other low-power nanobsd appliance.
I still have to figure out the cause of this delayed and weird behavior...

Installation and Upgrades / Re: Unable to update repository
« on: May 08, 2017, 10:39:29 am »
Hi jimp,
thanks for your prompt and kind reply.

If I execute "pkg update -f" I get the same "unable to update" on "repository pfSense-core" and "repository pfSense" as before, after a long, long time (1h) waiting for the specific catalogue.

In order me to check for the correct R/W operation of the CF, I copied a large file on it via FTP with no hassle, besides that I can recall there was no error in writing the full 4GB image file on it when I reinstalled pfSense 2wks ago.

From my perspective, every service in the network is working fine with no slowdown, except when I try to execute the various "update operations" that I have already described, that eventually fail.

In reading the warnings in the system log, I was mostly surprised in reading a strange url path, while I'm still wondering why I cannot access the "update settings" subpage getting a "gateway timeout"; that led me to think of a trouble on the new update/package system, that has been recently changed.

Installation and Upgrades / Unable to update repository
« on: May 08, 2017, 08:39:03 am »
Hi folks,

I'm getting the following symptoms on my NanoBSD-based pfSense box equipped with a 4Gb CF (currently running rel. 2.3.3).

I hasten to add that I had already dealt with the same update problem 2 weeks before and that, to solve it quickly, I had reinstalled pfsense writing the CF from scratch, just to experience it later again. I'm saying this to point out that the problem should be triggered by some background operation, with no specific user action, while the box and all the machines in the network are working perfectly.

So, I'm getting the well know "unable to check update status" message from the GUI dashboard and I can't use the package manager to display installed or to install new packages ("unable to retrieve package info") and I can't even access the "update settings" subpage of the update function from the GUI to select the source ("gateway timeout").

Trying to solve, I checked all the update-related solutions on the forum, with no success (including jimp's solution on sticky posts labelled "2.3.x "Unable to check for updates"/"Unable to retrieve package information").

Infact, trying to execute "pfSense-upgrade -d" or "pkg update; pkg upgrade pkg", I get an "unable to update repository catalogue pfsense-core" warning and the following "unable to update pfsense repository".

Looking at the system logs, I found the following warnings, related to attempted update operations, that seem quite strange and give me no clue:

nginx: 2017/05/07 17:36:44 [error] 48369#100083: *167 upstream timed out (60: Operation timed out) while reading response header from upstream, client:, server: , request: "POST /pkg_mgr_installed.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "", referrer: ""

nginx: 2017/05/07 17:43:33 [error] 48771#100098: *213 upstream timed out (60: Operation timed out) while reading response header from upstream, client:, server: , request: "GET /system_update_settings.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "", referrer: ""

Has anybody any ideas except reinstalling the system once again?

Thank you for the suggestion jimp, infact I had noticed this recent modification in rc.carpmaster/rc.carpbackup as I was adding my code manually, but I hadn't still understood its purpose.

However, your tip doesn't fit my case; indeed I have no package to notify about the CARP status change, just some code to execute in order to make a configuration change and an update for some dynamic dns entries; as said before - beside a manual edit of the CARP script files - the best for me would be a selection of a custom file in the GUI and a related call hook in rc.carpmaster/rc.carpbackup.

Thanks for your fast-as-light answer!

I had already thought of using System Patches but I had deemed it too complicated, expecially if compared with the practical solution of this problem (vi+paste text at the end of the rc.carpmaster/rc.carpbackup files).

For this reason, and to create a definitive solution to getting-common necessities, I had preferred to suggest an enhancement for upcoming releases.

CARP/VIPs / CARP scripts surviving an upgrade / enhancement proposal
« on: July 26, 2015, 04:39:04 am »
Hi folks,
I was wondering if there is an "official way" to preserve some lines of code added at the end of the CARP scripts (rc.carpmaster/rc.carpbackup).

I've noticed that those files are always rewritten during an ugrade, leading to a loss a functionality that has to be restored manually later.

Anyway, I suppose that a definitive solution would be to implement a simple GUI "CARP actions customization page" of user-specific code (to be called after system actions in the above said files), i.e the selection of a custom script file (stored in the pfsense configuration file), so that all customizations can survive an upgrade. This would be very useful, as it is becoming common to provide spinoff actions for a CARP status change.

Italiano / Re: 3G/4G VPN senza ip pubblico statico
« on: July 15, 2015, 06:12:12 pm »
Il problema di fondo è che non ci sono più indirizzi IPv4; i provider stanno infatti usando già da tempo indirizzi privati con NAT sulla loro infrastruttura.

In questi ultimi giorni invece, in maniera non uniforme sul territorio italiano, quasi tutte le connessioni 3g/4g consumer di qualunque provider cellulare stanno passando ad indirizzi privati nattati. Anche se in questo momento la propria connessione è su un ip pubblico, non c'è certezza che la prossima volta che si connetterà continui ad essere così.

Anche alcuni provider wireless hanno iniziato a fornire indirizzi privati ai nuovi contratti "salvo richiesta esplicita" (il che fa presagire che il diritto di avere un ip pubblico anche dinamico possa essere successivamente negato o tariffato diversamente).
E' ovvio che questo determinerà (fino all'introduzione di IPv6, la cui disponibilità di offerte è ancora scarsa nel nostro paese) l'aumento medio del prezzo delle connettività per avere un indirizzo pubblico garantito, per non parlare del costo degli ip statici, che non ho mai visto offrire su rete 3g/4g.

Per quanto riguarda specificatamente i provider cellulari, impegnati oggi ad acquisire nuovi clienti consumer grazie alle nuove connettività a HSPA/LTE (21Mbps/42Mbps) competitive per prestazioni alle linee fisse, non sono ancora state definite con esattezza le opzioni commerciali per richiedere l'IP pubblico sulla connessione (provate a parlare con il customer care di un qualunque operatore e ve ne renderete conto); occorre però ricordare che caratteristiche come ad es. "M2M" (che è un'opzione commerciale, non tecnica) vengono solo offerte per le aziende. D'altronde, come dicono loro ai privati "non c'è scritto da nessuna parte che con questa connessione un ip pubblico sia garantito" e "sono fatte solo per dare l'accesso ad internet".

L'impressione che ho quindi avuto come professionista IT e parlando con gli operatori cellulari è che il problema non venga reso palese in attesa che il mercato si abitui alla variazione, con un aumento delle tariffe per chi vorrà fare servizi inbound; d'altronde l'uso di VPN site-to-site, controllo remoto e voip (che sostanzialmente si basano sulla possibilità di fare traffico entrante) sono applicazioni meno diffuse rispetto alla richiesta di connettività standard (basata su traffico uscente).

Vista questa situazione, mi sono personalmente già orientato sulle seguenti opzioni, da cui sono sempre derivati costi maggiori:

- dove possibile, non usare connettività cellulare per VPN / controllo remoto / voip ma preferire linee cablate, con ip statico
- dove è richiesta mobilità, richiedere contratti business con ip dinamico pubblico garantito e senza nat

In alternativa e per concludere (ma con ulteriore aggravio economico/gestionale), rimarrebbe tecnicamente possibile creare vpn site-to-site (quindi collegare anche più siti tra loro) creando un "centro stella vpn" usando un firewall pfsense appoggiato ad una connettività con ip pubblico e facendolo raggiungere da "nodi periferici" su connettività 3g "private", utilizzandole quindi solo in modalità outbound.

Quella della "VPN centrale" è la tecnica che ha da tempo distinto Teamviewer da altre soluzioni di controllo remoto, essa infatti basa la propria superiorità proprio sulla non necessità di configurare il traffico entrante o di avere una connessione "aperta", tutto quello che serve è disporre un "accesso ad internet", quindi anche una connessione 3g/4g nattata va bene.

Chi soffrirà maggiormente di questa situazione (almeno nel primo periodo) è sicuramente il cliente privato, ormai avvezzo a   piccole implementazioni di controllo remoto/telesorveglianza/voip che hanno improvvisamente smesso di funzionare.

CARP/VIPs / Re: Enable Dynamic DNS when failing over to Backup
« on: October 27, 2014, 07:44:42 pm »
I've just seen your post, if still interested try this:

0) We are assuming that the first CARP VIP you have defined on both pfsense boxes is for the "master" (in normal condition) and the second VIP is for the "backup" (in normal condition). As a result, CARP interfaces are something like xxx_vip1 and xxx_vip2
1) Setup 2 dyndns names, respectively the master and the backup FQDNs (be careful, the order matters) on both the "master" and the "backup" pfsense boxes

E.g.: (master pfsense) (backup pfsense)

2) Modify file rc.carpmaster adding the following at the end of it:

Code: [Select]
/* Start DynDNS for CARP nodes */
$config['dyndnses']['dyndns'][strval((int)(SUBSTR($argv[1],-1)-1))]['enable'] = true;

3) Modify file rc.carpbackup adding the following at the end of it:

Code: [Select]
/* Stop DynDNS for CARP nodes */
$config['dyndnses']['dyndns'][strval((int)SUBSTR($argv[1],-1)-1))]['enable'] = false;


The above mentioned scripts trim the VIP interface name extracting its interface number (e.g. "xxx_vip1"->1), that becomes an index to access every pfsense's DynDNS table, enabling/disabling the service update for the given box, so there should be a 1:1 relationship between overall VIPs and DynDNSes sequence, being them defined in the same way on all the CARP boxes. Due to current code, this trick can support up to 9 pfsense systems, with related VIPs and DynDNSes (tested on nanobsd 2.1.5-release i386).

Pages: [1]