Cannot EDIT existing aliases, rules, leases, etc

granroth

I am running pfSense CE 2.6.0-RELEASE on a Protectli Vault. As of when I write this, that is the latest version available to me. I login to the pfSense web GUI using Firefox primarily but also Chrome, on occasion.

I have successfully added dual-wan, many DHCP static leases, and several firewall rules, NATs, and aliases. Adding new content works like a treat.

I find myself completely unable to EDIT any of that content, though. Specifically, anything that has the "pencil" icon for editing has the same behavior -- I click on the "edit" button and the web GUI shows a page identical to an "add" attempt. That is, the page has no data from the existing item.

As I said, this is affecting every attempt I've made to edit anything that has the edit button. Here is one specific example:

Go to Status -> DHCP Leases (https://192.168.1.1/status_dhcp_leases.php)
Click on the edit icon of an existing static lease (https://192.168.1.1/services_dhcp_edit.php?if=lan&id=30)
The page title is "Services / DHCP Server / LAN / Edit Static Mapping" so it absolutely thinks it is editing a lease
Note that all of the fields are empty, including such required fields as MAC Address, IP Address, and Hostname

It is worth noting that if I try to re-enter all of the existing data and just change the one line needing changing, then I get an error about the entry already existing... so this page is very much acting like an "add" even though it claims "edit".

I did try editing the config xml itself on the command line, but that did nothing as it didn't appear to re-load it.

I can post a bunch of screenshots or dig into the logs, if it helps. I am hoping that I'm just doing something silly here and it'll be very obvious to somebody reading this.

SteveITS

@granroth Can you try a private window or another browser just to rule out a browser/cache/cookie issue?

granroth

@steveits said in Cannot EDIT existing aliases, rules, leases, etc:

@granroth Can you try a private window or another browser just to rule out a browser/cache/cookie issue?

Ahah! It is, indeed, a cookie issue!

I thought I was covered by using two different browsers (Firefox and Chrome) and on two different PCs (desktop and laptop) but what I had forgotten is that all four variants had "continuing" sessions from prior attempts.

I fired up Safari -- which I've never used with pfSense -- and verified that Edit does work like expected!

I then went back to Firefox and did an explicit Logout and then logged in using the same tab. Edit did not work.

There were four pending cookies tied to my pfSense session:

id
PHPSESSID
stay_login
tzoffset

I logged out; deleted all four cookies; and attempted to login again. This time I got a "Missing or expired CSRF token" error! Ah, so both Firefox and Chrome do still consider me within the previous session, even though pfSense considers me logged out.

I switch to a new tab and try again... and voila, Edit works! I now see a new PHPSESSION cookie and it's different than before.

TL;DR - it appears that in order to Edit, I cannot re-login using the same tab that I was logged out of.

Thank you, Steve -- that's precisely the type of silly mistake I was hoping it was and would have a simple answer.

SteveITS

@granroth said in Cannot EDIT existing aliases, rules, leases, etc:

it appears that in order to Edit, I cannot re-login using the same tab that I was logged out of

I'd be more inclined to think it was a damaged cookie or session data or something. I don't have that issue...

I take it you're on a Mac? That's a difference but I can't see how that's relevant.

The CSRF is on the (login) page(s) for security but it will eventually expire, so if you log out and leave the tab open to the login page, or delete the cookies etc., you must refresh the page to log in again.

<script type="text/javascript">var csrfMagicToken = "sid:186999287241d7361fc56f93fe0381f81f4e6094,1654720115";var csrfMagicName = "__csrf_magic";</script><script src="/csrf/csrf-magic.js" type="text/javascript"></script></head>

granroth

@steveits said in Cannot EDIT existing aliases, rules, leases, etc:

@granroth said in Cannot EDIT existing aliases, rules, leases, etc:

it appears that in order to Edit, I cannot re-login using the same tab that I was logged out of

I'd be more inclined to think it was a damaged cookie or session data or something. I don't have that issue...

I've done some more testing and this took some doing to reproduce! The problem is not PHPSESSION but rather id.

That is, if I clear all of my cookies and logout/login, the only cookie that is recreated is PHPSESSION and that works like expected. I can edit items in this scenario.

If, however, there is an id cookie, then I do see from the Web Console that it is being accessed but it's never modified nor deleted and it's not session based. If that cookie exists, then I am unable to edit any items!

To recreate, I simply added a new cookie to my pfSense cookie storage like so:

The value is a simple random session value. I set Secure and HttpOnly to true just to match the value of the previous id that had been set. I do not know which of these cookie settings matter -- it's just that if this cookie exists, I cannot edit items.

I don't know what action creates that cookie. I tried re-creating my steps that I would have done on multiple browsers over a few days, but nothing resulted in a cookie with that name. I needed to add it manually in order to trigger this.

johnpoz

@granroth not seeing any ID cookie - here is the only cookie I see when I access the web gui.

Even when I go to edit something.

granroth

@johnpoz Indeed, I have been unable to find a series of steps that will cause pfSense to create the id session on command. That said:

a) It did set it originally since it was in the Cookies list of my pfSense IP in at least two browsers, and I didn't set it manually
b) It absolutely is overriding the id query parameter when editing items, so something is reading it

I'm nowhere near familiar enough with the pfSense code to track down what might be setting and/or reading that cookie -- and honestly, searching for "id" could very well be maddening.

I do see that I'm not the only one to run into this. A quick search brings up this bug report from a year ago: https://redmine.pfsense.org/issues/11268. Matthew ran into precisely the same issue I was seeing.

SteveITS

@granroth Without looking at any of the pfSense code, the PHP variable $_REQUEST "contains the contents of $_GET, $_POST and $_COOKIE": https://www.php.net/manual/en/reserved.variables.request.php

I believe the default order is EGPCS (Environment, Get, Post, Cookie, and Server) so a cookie would override the URL variable. If the code uses the more generic $_REQUEST.

Viper_Rus

Hi. i have the same problem in google chrome. often have to delete cookies. there is no solution? noticed that it occurs only when I enter the domain name. if I go to the internal ip, everything is always fine.