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.

2.1-BETA1 (amd64)
built on Wed May 1 12:20:46 EDT 2013
FreeBSD 8.3-RELEASE-p8

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.

I tried disabling both serial ports in the BIOS and pfsense doesn't boot. With one or both serial ports enabled, I have to employ this workaround (manually--the patch package didn't work) in order to be able to edit my pppoe interface. Tried on May 1 snapshot.

2.1-BETA1 (amd64)
built on Wed May 1 12:20:46 EDT 2013
FreeBSD 8.3-RELEASE-p8

I think I'm seeing the same thing. Static dhcp leases do not resolve for local lookups, despite the option being enabled in the DNS Forwarder options. This worked on my last snapshot from early March, and prior 2.0.x releases.

The ppp log is constantly spammed with IPv6 messages (despite the fact that IPv6 is disabled on this machine), so I don't have an informative answer for you. To add to the fun, my provider had a RADIUS problem that made this network unreachable to me for 22 hours, so I'm looking forward to learning a few things when I get on site tonight.

I had the same problem. Manually edited the file and was able to edit my pppoe connection. Unfortunately after saving the changes to the pppoe connection, the WAN never came back up.

Since this has to do with unused serial ports, is there another workaround, such as disabling serial ports in the BIOS? My board has a couple of serial ports, but I'm not using them and I don't remember if they are disabled in the BIOS.

2.1-BETA1 (amd64)
built on Mon Feb 18 22:59:11 EST 2013
FreeBSD 8.3-RELEASE-p5

Some of my interface graphs in the dashboard and on the Traffic Graph page are showing impossible speeds, likely about double of the actual amount of traffic there. Could this be related?

In the screenshot, the WAN has a 42 Mbps d/l speed. The LAN traffic is coming from nowhere but the WAN, but shows higher speeds (and a similar curve). Note that there are other interfaces pulling from the WAN, so the WAN and LAN curves won't match exactly, but the LAN speed should not exceed the WAN speed.

I tried 2.1 but the foray was brief, as some show-stopping bugs had me rebooting within minutes. The good news is that by rebooting into 2.0.1 without a single USB device connected, this problem does not occur for me, even after 20 days uptime.

Still looking forward to a snapshot that lets me use a keyboard without the accompanying IRQ storm.

Any progress to report here?

Today I updated from 2.0.1 to 2.1-BETA0 snapshot from 2 days ago. Disastrous. Both the web UI and the shell are unresponsive for several seconds at a time. Reloading the web configurator didn't help. When I was able to run top, both CPU cores are showing 90%+ idle.

As a bonus, several of my local networks have no internet, for reasons that aren't immediately apparent. Also, the traffic graphs on the dahsboard, other than those for the WAN and LAN interfaces, are displaying their OPTx names rather than their assigned aliases, but this is the least of my concerns.

Thank goodness for dual slices.

2.0.1

I have considered moving to 2.1, I'm just not really excited about testing software on this particular machine. I'll have to try my options though, one early morning at a time

Really need a network diagram to understand what you have and what you're trying to do.

squid will kill your flash drive before too long. I believe quid can be configured to use RAM only, which is what you want until you get proper disk storage.

I played with squid on pfsense about a year ago until I ran into some odd behaviour. The first annoyance was that it appeared to be downloading Windows updates proactively. This was probably due to the custom config I created with the help of a tutorial from the docs, but I wasn't fond of seeing all my bandwidth being eaten up by a non-human user. The second problem was large http downloads dying midstream, for example iso files from MSDN stalling or quitting after ~1.5 GB on multiple attempts. I suppose these problems were solvable, but I didn't have any more time to mess with it then.

install this driver from cd

That's not going to happen. Save yourself some grief and buy a supported NIC, such as Intel.

Does anybody have an update on this? I recently commissioned an Intel DH57JG board and I'm seeing the same issue. Disabling legacy USB in the BIOS, and setting hw.usb.ehci.no_hs="1" in /boot/loader.conf.local both make the problem go away for a few hours, and then it comes back. This is a production system, so I'd like to know if anybody has it licked before I spend the next week getting up at 4 am to try one option at a time.

http://forum.pfsense.org/index.php/topic,28379.msg148389.html#msg148389