Project

General

Profile

Actions

Bug #13807

closed

NAT changes aren't rolled back using Restore recent configuration on the console

Added by Gustavo Domínguez over 2 years ago. Updated over 2 years ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
Configuration Backend
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
2.6.0
Affected Architecture:
amd64

Description

Accidentally I natted all traffic from the intranet(1) going to the firewall(2) to an internal host. Obviously I wasn't meaning for that to happen but rather using an VIP.

I noticed as soon as I clicked and acted immediately trying to race against the rule reload and managed to delete the NAT rule, apply the changes and even browse a couple of pages more but in the end it stopped responding and Telegram started dinging like crazy because error notifications.

This is a VM and luckily my intranet is a switch, so I still had access to the hypervisor. I opened the console went to option 15, Restore recent configuration, and undid one. according the history a NAT rule. The second didn't take despite the UI having confirmed it. But it never came back. I rebooted attempting to force things to reload from scratch but it didn't help.

On the console I could see I was online, I had not enabled access through the Internet on the custom access port but it was enabled through HAProxy. After logging in, the NAT rule was still gone but natting was still happening, all of the passed traffic to the host traffic was being natted to confirmed it.

So my next move was to add new rules to give myself SSH access from the Internet to edit /cf/conf/config.xml but it didn't work for some reason. I cleared the states, panicked a little when I got disconnected but after a very long loading time, I regained access in another browser.

Finally to fix it, what I did was to revert the configuration to restore the NAT rule using the little rewind-kind of icon that tooltips "Revert config". It didn't take long reloading or anything like that, right away the NAT rule reappeared. On it before deleting it, I changed the protocol to something I'd never use(3) just in case it lingers around for some reason.

The dings on Telegram stopped when I applied the changes. I confirmed from another device I had access and came back still from the Internet side to delete the NAT rule. I don't know what will happen if I ever need PIM I don't know how to test that. As for SSH rules I created later, I can't test anymore if they would've worked or whatever since they got deleted when I rolled back (or forward, I don't know) to the point in time config where bad NAT rule existed.

I was going to put this in the user forum but it seemed more appropriate here. Hopefully it's really a bug, well-- I'm not hoping for a bug, what I mean is I don't want to waste anybody's time.

Anyway… Thanks.

1: single internal interface, transit network
2: "(This Firewall)"
3: PIM. The firewall is at the third hop from the network ( routing-switch1 → firewall-a2 → firewall-b/pfsense3 ). PIM makes more sense on the switch if at all.

Actions #1

Updated by Jim Pingle over 2 years ago

  • Status changed from New to Not a Bug

This is normal and expected. Restoring a past config doesn't activate it, it only changes the configuration data back. You need to apply the settings in some way (e.g. reboot, manual filter reload, etc).

Actions

Also available in: Atom PDF