Restore Config Lost the NAT
-
Unbeknownst to me (because of a lack of verification caused by trusting in the process), I had zero traffic coming through pfSense. I don't have that much anyway.
My box lost the hard drive. I found a config file from a few months back and after installing pfSense onto the new hard drive, loaded that config file using Restore on the webGUI.
Since that backup was saved, the nic cards got swapped around just a bit. (Having loads of Watchdog Timeouts on em0:WAN, so moved WAN to fxp1 and moved OPT1 to em0, but never connected the cable to that nic.)
So, pfSense said the interfaces needed to be re-assigned. Which I did. That was a couple of weeks ago. Recently I got a call from a friend saying my server was not reachable.
Examining the various webGUI screens, I discovered that, oddly, nothing was in the NAT: Port Forward page.
I saved off a another config file from Backup on the webGUI and made a comparison of that with the config file I used to restore. I found the expected differences, but also found the entire <nat>block was missing from the current config file.
Is there a decision made during the parsing of a config file that would cause pfSense to completely abandon the <nat>block if some aspect of the hardware installation didn't match up with the config?
Anyway, I pasted in the <nat>block to the recent config file and reloaded the config file.
It's all good now.</nat></nat></nat>
-
Personally, I have not had that happen. I have had to restore a few times because of hardware failure and upgrade from 32 to 64 bit.
-
I'm in the middle of building my first pfSense box and decided to register just to reply to this. At one point during my configuration, I made some changes to the ethernet cards and assignments so that I can add a different LAN interface card. I eventually ended up with the same physical card that I had originally used for my WAN interface along with the 2nd card for my LAN side. Well after going back to the GUI, all the entries in the NAT Port Forward page were gone. The Rules definitions were still there. Luckily, I'm still pretty early in configuration and it won't take long to redo what I had already setup (i.e. I had not made a backup when this happened).
I'm not sure if this is a bug or just 'normal' behavior.
Jack
Unbeknownst to me (because of a lack of verification caused by trusting in the process), I had zero traffic coming through pfSense. I don't have that much anyway.
My box lost the hard drive. I found a config file from a few months back and after installing pfSense onto the new hard drive, loaded that config file using Restore on the webGUI.
Since that backup was saved, the nic cards got swapped around just a bit. (Having loads of Watchdog Timeouts on em0:WAN, so moved WAN to fxp1 and moved OPT1 to em0, but never connected the cable to that nic.)
So, pfSense said the interfaces needed to be re-assigned. Which I did. That was a couple of weeks ago. Recently I got a call from a friend saying my server was not reachable.
Examining the various webGUI screens, I discovered that, oddly, nothing was in the NAT: Port Forward page.
I saved off a another config file from Backup on the webGUI and made a comparison of that with the config file I used to restore. I found the expected differences, but also found the entire <nat>block was missing from the current config file.
Is there a decision made during the parsing of a config file that would cause pfSense to completely abandon the <nat>block if some aspect of the hardware installation didn't match up with the config?
Anyway, I pasted in the <nat>block to the recent config file and reloaded the config file.
It's all good now.</nat></nat></nat>
-
I must confirm this issue - I did configuration backup and later on config restore.
All configurations in NAT and firewall rules was working and tested but after restoring configuration to new identical Alix board no singele NAT or any rule worked. This means only one thing - Backup/Restore feature is broken.
If you do full flash image backup and rewrite it to new flash - that works fine.
What I needed to do was reset to factory settings and re-configure all NAT and other rules. After that configuration just worked.
So - does anyone have this same problem - I think that this should be easily confirm by doing Backup/Restore and test what happens.
-
Hardware, unless the very same, is not identical and with the way BSD enumerates the interfaces, the new hardware might be out of the order that is expected.
I have backed up and restored my config many times, bit all of mine have been full pfsense installations and never embedded. We need to find out if this is isolated to embedded version or not. I don't have anything to test the embedded with. My full installs are working fine. -
So you mean in other words that backup/restore function is useless?
That can't be the design base for this feature. Can anyone explain usage of backup/restore.
-
A default backup of config.xml contains everything, including NAT. I've never seen a backup or restore do everything except NAT, and I've done hundreds if not thousands of them. It always includes everything, unless you manually select to backup a single section of the config. (Or someone hand edited the config and removed portions of it).
There must be some other factor at work if that's happening, but it's not a general issue that affects everyone.
-
I am just saying that fxp0 on one machine might nat be in the same position on another machine. That is all. NAT restore works. You can even reassign interffaces if the restore know that there are different types of interfaces. Like you had fxp0 and fxp1 and the new one has em0 and em1. But you would only need to swap cables to have it work correctly.
-
If you are careful to account for that when you assign the interfaces after restoring, that's a non-issue.
-
Very true. But it sounds like they might not have been. Hard to know for sure, but all my test restores have been fine.
-
If you are careful to account for that when you assign the interfaces after restoring, that's a non-issue.
OK - so actually this re-assign interfaces should be a mandatory step after restore procedure IF you don't have same hardware. I'm seen this issue now three times and all of them had hardware changes.
-
It is a mandatory step. If the system detects that the NICs do not match, it takes you to a reassignment screen where you can select the interfaces.
If you restore from the console/PFI/some other non-GUI means, it will prompt at boot time for reassignment.
