I apologize in advance, because some of the following details are vague due to me reporting this problem after the fact and not having a clear idea of how to reproduce it. I realize that if I'm the only one experiencing this issue then this thread isn't likely to go anywhere, so I'm hoping that some other poor soul's search will land him here so that we can get a clearer picture of what the problem is/was.
built on Wed May 1 12:20:46 EDT 2013
I have a multiplicity of vlan interfaces and it's been working fine. A few weeks ago I added a new vlan to an interface that was already parent to many vlans. I then attempted to activate and assign a static IP address of 192.168.86.254/24 to the new interface, but after hitting the Save (Apply?) button, I received an error to the effect that the address or subnet was already in use on another interface. After the page refreshed itself, the text in the static IP assignment box had changed to 192.168.1.254.
After attempting this a couple of times with the same result, I tried rebooting pfsense, knowing that at times in the past a reboot has been necessary to 'cement' changes to interfaces. Even after a reboot however, the same thing happened.
I also attempted downloading and modifying the interfaces-config.xml file. I confirmed through search that '192.168.86' did not occur anywhere in the file, then made the change and uploaded the file. I don't recall if I saw errors at this point, but the interface address again reverted to 192.168.1.254/24 in the GUI. I don't recall if I rebooted before, after, or before and after attempting this direct edit of the config file.
At this point I decided to just accept the fact that my new interface would be 192.168.1.254/24, and I enabled the dhcp server and set a corresponding range for the pool on the interface (the dhcp server was already enabled on other interfaces).
For a few weeks this configuration worked fine (although not a single client connected to the new interface, so by 'fine', I mean it in the sense of the whole system without actually testing the new network).
Today however, pfsense stopped responding on all network interfaces for reasons that I am unable to diagnose remotely. I power-cycled the firewall and it came back up fine. Within a short time however, I noticed that dhcp leases weren't being handed out on any interface. I found in the system log "bad range, address 192.168.1.100 not in subnet 192.168.86.0 netmask 255.255.255.0". The new interface had reverted to an address of 192.168.86.254/24, but the dhcp server still had the now-incompatible pool of addresses in the 192.168.1.0/24 subnet, and the dhcp server was failing to hand out leases on all interfaces, presumably because it had failed to start due to this error.
I fixed the address range on my new subnet (back to the now-active 192.168.86.0/24 subnet) and after applying changes, dhcp appears to be working normally on all interfaces where it is enabled.
So my questions are:
1. Why was I seeing the bogus error when attempting to assign a valid, unused address and subnet, even after reboots?
2. Why did the interface revert at some point to the address that it hadpreviously rejected? The only reasonable explanation I can think of is that the config file had retained my manual edits despite the GUI reverting to a different range. At some point, pfsense re-read the config file and this time didn't have a problem with it, and applied it.
Anybody seen anything similar? I apologize if this is a known issue. Because I don't remember the exact error I saw, I wasn't able to formulate search terms specific enough to my situation to produce any meaningful results.
edit: I should add, that the only config changes I have made since then were some minor modifications to some existing firewall rules, and a manual re-ordering of my interfaces in the interfaces-config.xml file. I downloaded that file and made the ordering changes yesterday, then uploaded the file again yesterday. Having just looked at the file copy that I edited locally, I see that the assigned address for my new interface is 192.168.86.0/24, so obviously that edit which I made a few weeks ago survived in the xml file, and then was activated today, probably when the firewall booted after having been power cycled due to the lock-up.
In retrospect, had I rebooted pfsense immediately after manually editing the config file the first time, it seems like the change may have taken effect at that time. That still doesn't answer the question of why the change was rejected when attempting to make it in the GUI, even after reboots. It also doesn't answer the question of why pfsense locked on me today, but obviously there's not much forensic evidence now on which to base a hypothesis on this point.