It should be fixed now: https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/857a4a79864a4b250271e5a5648ddb2a3ad249ee Once that makes it into snapshots anyhow.

Thnx I'll watch out and try it out once I can upgrade the box.

Ah.. yeah there is someone else on here that needed to set promisc on the nic to even get DHCP on bge. Rather strange, not sure if it's a specific chipset problem or a driver issue. Looks like it's been around a while.

It should just skip the package and go on, though I can't say I've tried that lately. It will remove the fact that it's "installed" in the config but it should keep the settings.

I'll try the latest snap this weekend and turn the dhcp stuff back on and see if still having had problems.

It was undercounting before :) Previously it wasn't listing all system/kernel threads, now it is.

It sounds like your config was not properly imported, and may have caused other issues. The things you mentioned should have been carried over without issue.

The reject showing in the logs really only works for TCP connections which do support a reset in that way. UDP handles it as ermal describes, and other protocols can't use reject at all.

@jbp: We have two cases here: 1. pfsense lets people use characters from their own languages (until now) 2. pfsense doesn't let people use characters from their own languages -> pfsense should reject characters it doesn't support. They are supported in 2.0 where it's feasible to do so, they were not supported in 1.2.3, they just happened to work without exploding the config in certain specific spots. Other spots would explode the config there. Congratulations, you stepped on a land mine and it didn't go off. The way the characters were stored in the config in 1.2.3 was invalid XML, it doesn't meet the spec, which is why the config is now rejected on 2.0. If you run your 1.2.3 config through a standard xmllint tool it will show you that they are invalid XML. On 2.0 in description fields and some others that can take such characters, we CDATA escape the values so that they are properly handled in XML.

I've seen this happen before, but it's rare. I can't reproduce it in current code though. If you had a DHCP WAN and then changed it to static, sometimes dhclient was left running. If you kill dhclient (or reboot) the log messages go away.

It binds to all interfaces. As long as you allow access to udp port 161 it should respond on any interface, assuming the service is enabled and actually running.

Can I just add a note here? I loaded the pfSense-2.0-RC1-1g-i386-20110226-1633-nanobsd.img.gz to a 1GB flash and it seems that the file system for this was r/w after boot. I then proceeded to upgrade, which went OK and loaded the latest update. However, after rebooting with the latest update the file system is still r/w. When I loaded a latest base image from snapshots, then the file system was r/o. Can someone explain why my updated 1GB nano build is still r/w - it's essentially the same build at the latest base version. Cheers, JD

You need a bit more complicated rule than that. If you want your LAN clients' http traffic transparently redirected to the squid server, it needs to be more like: Interface: LAN NOT <- check that Source Type: Single Host Source address: IP of the squid box Destination: any (Or you could check NOT and put the IP of the firewall there, too, or use an alias containing local/vpn networks) Destination Port: 80 Redirect target ip: IP of the squid box Redirect target port: 3128 (or whatever port you have squid listening for transparent connections on) I think that should work, though generally it is recommended to put the squid box on a separate interface from where the clients are entering, then you don't have to use the source part of that redirect.

Very interesting, and I can confirm this does happen. When you delete the last IP from an alias, the rules.debug correctly contains no IPs in the alias, but the pf table still holds the last IP. It would appear the GUI and backend code is doing the right thing, but perhaps an extra step is needed to flush the table in this specific case when an alias is emptied out. However, it's rare that someone would be leaving an such alias empty.

That was fixed a while back, it's not that way in snapshots. Also the little "m" is milli, not big "M" (Mega) meaning that should be shifted the other way, so that's actually 0.350 packets per second, so I wouldn't say that's too high.

Manufacturers keep shrinking and shrinking cards over time without changing part numbers. I just had to make a smaller 4GB image for someone yesterday. Can you get more info on the exact size of this "2GB" (and I use the term loosely…) card?

Hi jimp. I don't have a username there. Would you mind posting it for me? I've done the research and stuff but don't feel like making an account just to report a quick bug. ;)

@GruensFroeschli: You could run the OpenVPN instance on the LAN instead of the WAN and then forward the port from the WAN to your LAN. Sometimes solutions are so simple. Never thought of running OpenVPN on the LAN interface, but everything works like a charm. Thanks Alexander