Netgate is offering COVID-19 aid for pfSense software users, learn more.

Alternate Remote Backup Techniques

The easiest choice to backup pfSense® software is the free Using the AutoConfigBackup Service service. Rest easy knowing it is taking care of handling remote backups automatically without needing to worry. Sit back, have a cup of coffee, and read on for alternate techniques.

The other techniques in this document may also be used to perform backups remotely, but each method has its own security issues which may rule out their use. For starters, several of these techniques do not encrypt the configuration, which may contain sensitive information. This can result in the raw configuration being transmitted over an unencrypted, untrusted link. If one of these techniques must be used, it is best to do so from a non-WAN link (LAN, DMZ, etc.) or across a VPN. Access to the storage media holding the backup must also be controlled, if not encrypted.


Pulling the configuration means to use a remote client to “pull” the configuration off of the firewall. The methods described below both accomplish the same goal using different utilities.

Pull with wget

The configuration may be retrieved from a remote system by using wget , and this process can be scripted with cron or by other means. Even when using HTTPS, this is not a truly secure transport mode since certificate checking is disabled to accommodate self-signed certificates, enabling man-in-the-middle attacks. When running backups with wget across untrusted networks, use HTTPS with a certificate that can be verified by wget.

The wget command must be split into multiple steps to handle the login procedure and backup download while also accounting for CSRF verification.

For a firewall running HTTPS with a self-signed certificate, the commands are as follows:

  • Fetch the login form and save the cookies and CSRF token:

    $ wget -qO- --keep-session-cookies \
      --save-cookies cookies.txt \
      --no-check-certificate \ \
      | grep "name='__csrf_magic'" \
      | sed 's/.*value="\(.*\)".*/\1/' > csrf.txt
  • Submit the login form along with the first CSRF token and save the second CSRF token (can’t reuse the same file) – now the script is logged in and can take action:

    $ wget -qO- --keep-session-cookies --load-cookies cookies.txt \
      --save-cookies cookies.txt --no-check-certificate \
      --post-data "login=Login&usernamefld=admin&passwordfld=pfsense&__csrf_magic=$(cat csrf.txt)" \ \
      | grep "name='__csrf_magic'" \
      | sed 's/.*value="\(.*\)".*/\1/' > csrf2.txt
  • Submit the download form along with the second CSRF token to save a copy of config.xml:

    $ wget --keep-session-cookies --load-cookies cookies.txt --no-check-certificate \
      --post-data "download=download&donotbackuprrd=yes&__csrf_magic=$(head -n 1 csrf2.txt)" \ -O config-router-`date +%Y%m%d%H%M%S`.xml


The behavior of variable expansion and other aspects of the commands may vary by shell. This example uses bash for the client shell.

Replace the username and password with the credentials for the firewall, and the IP address is whichever IP address is reachable from the client performing the backup, and using HTTP or HTTPS to match the firewall GUI. To backup the RRD files, omit the &donotbackuprrd=yes parameter from the last command.

The system performing the backup will also need access to the GUI, so adjust the firewall rules accordingly. Performing this over the WAN is not recommended. At a minimum, use HTTPS and restrict access to the GUI to a trusted set of public IP addresses. It is preferable to do this locally or over a VPN.

Using cURL

For those who prefer to use cURL, the following example accomplishes the same goal:

  • Fetch the login form and save the cookies and CSRF token:

    $ curl -L -k --cookie-jar cookies.txt \ \
         | grep "name='__csrf_magic'" \
         | sed 's/.*value="\(.*\)".*/\1/' > csrf.txt
  • Submit the login form to complete the login procedure:

    $ curl -L -k --cookie cookies.txt --cookie-jar cookies.txt \
         --data-urlencode "login=Login" \
         --data-urlencode "usernamefld=admin" \
         --data-urlencode "passwordfld=pfsense" \
         --data-urlencode "__csrf_magic=$(cat csrf.txt)" \ > /dev/null

    Now the script is logged in and can perform actions!

  • Fetch the target page to obtain a new CSRF token:

    $ curl -L -k --cookie cookies.txt --cookie-jar cookies.txt \  \
         | grep "name='__csrf_magic'"   \
         | sed 's/.*value="\(.*\)".*/\1/' > csrf.txt
  • Download the backup:

    $ curl -L -k --cookie cookies.txt --cookie-jar cookies.txt \
         --data-urlencode "download=download" \
         --data-urlencode "donotbackuprrd=yes" \
         --data-urlencode "__csrf_magic=$(head -n 1 csrf.txt)" \ > config-router-`date +%Y%m%d%H%M%S`.xml


The behavior of variable expansion and other aspects of the commands may vary by shell. This example uses bash for the client shell.

Push with SCP

The configuration file can also be pushed from the firewall to another host with scp. Using scp to push a one-time backup by hand can be useful, but using it in an automated fashion carries risks. The command line for scp will vary depending on the system configuration, but will be close to the following:

$ scp /cf/conf/config.xml \
    user@backuphost:backups/config-`hostname`-`date +%Y%m%d%H%M%S`.xml

Pushing the configuration in an automated manner requires the firewall administrator to generate an SSH key without a passphrase. Due to the insecure nature of a key without a passphrase, generating such a key is left as an exercise for the reader. This adds risk due to the fact that anyone with access to that file has access to the designated account, though because the key is kept on the firewall where access is restricted, it isn’t a considerable risk in most scenarios. Ensure the remote user is isolated and has little to no privileges on the destination system.

A chrooted scp environment may be desirable in this case. The scponly shell is available for most UNIX platforms which allows SCP file copies but denies interactive login capabilities. Some versions of OpenSSH have chroot support built in for sftp (Secure FTP). These steps greatly limit the risk of compromise with respect to the remote server, but still leave the backed up data at risk. Once access is configured, a cron entry could be added to the firewall to invoke scp.

A summary of the setup is as follows:

  • Generate an ssh key for the root user on the firewall without a passphrase. (Warning: dangerous!)

  • Add a user to a remote system, and add the new public key to its ~/.ssh/authorized_keys file

  • Create a cron job on the firewall that would copy /cf/conf/config.xml to the remote system with scp

Basic SSH backup

Similar to the scp backup, there is another method that will work from one UNIX system to another. This method does not invoke the SCP/SFTP layer, which in some cases may not function properly if a system is already in a failing state:

$ ssh root@ cat /cf/conf/config.xml > backup.xml

When executed, that command will yield a file called backup.xml in the current working directory that contains the remote firewall configuration. Automating this method using cron is also possible, but this method requires an SSH key without as passphrase on the host performing the backup. This key will enable administrative access to the firewall, so it must be tightly controlled. (See Secure Shell (SSH) for details.)