Fixed.

@jimp:

The speed thing works here too, and adds to the weirdness.

So it seems to be:

OK:
FreeBSD chromium-28.0.1500.71 (Compiled from source)
Windows Chrome 28.0.1500.95 m
OS X Chrome 28.0.1500.71
OS X Chrome 28.0.1500.95 (Tried before and after an update wanted to run)

Broken:
Chromium 28.0.1500.71 Built on Ubuntu 13.04, running on LinuxMint 15 (28.0.1500.71-0ubuntu1.13.04.1) - Installed from Software Manager
Chromium 28.0.1500.71 Ubuntu 13.04 (28.0.1500.71-0ubuntu1.13.04.1) - Installed from Software Center
Chrome 28.0.1500.95 - On Ubuntu and Mint - Installed from the .deb provided by Google

Please add as broken Safari 6.0.5 on OSX 10.8.4 with 1Password extension while Chrome 28.0.1500.95 with same extension works fine. Without extension Safari works fine. I think it is a scripting problem.

Edit: not very obvious, but I was using a non-native resolution on my iMac screen. When I switched to native resolution the problem was gone.

Yes, it happen to me too. Iam using i386.

You are late  ;D  (at least about the "error" message part)

http://forum.pfsense.org/index.php/topic,64558.msg352036.html#new

Fixed thanks for reporting.

argh, yes they were backed out - but reason is valid:
https://github.com/pfsense/pfsense-tools/commit/0d63350445dad1e7281ba085cd9fa0e0fdd7e261

I've never seen that required for lagg in general. Unless it's a problem specific to the failover mode, it's not likely a general issue.
At least with LACP, which is the most common, it usually just works without any fuss.

Which url is reqested from your Internet Explorer?
It should be http://wpad/wpad.dat or http://wpad.some.domain/wpad.dat .

I'm afraid of new things :o

incase it's the failover openvpn causing this issue, I've disabled that interface and disabled monitoring on site ABC's gateway.

Well that made no change.  Routes broke again and rebooting A to restored the connection.

@jimp:

aside from hardware support.

Not an insignificant aside perhaps.  ;)
Though some drivers were backported for 8.1 to allow newer hardware to run.

Steve

Portfast results:

Well, I watched the Cisco 7609's console and during the post update reboot did not see the port cycle with portfast enabled.  It successfully re-installed a package this time.  It was kindof odd to not see the port go down then back up; I'm going to try that again with portfast off to make sure it 'leaves the bridge' when the box reboots.

If so, then portfast fixes it; good thing I don't need bridged interfaces.

Yes, this 3.2GHz twin dual-core box boots very quickly, even from USB flash, and without portfast the typical cisco port won't go into spanning-tree forwarding mode for thirty seconds or more.

BTW, I read at http://doc.pfsense.org/index.php/Samba that creating /etc/rc.conf.local seems to accomodate what /etc/rc.conf intends to do in vanilla FreeBSD (as quoted below). But not sure whether it works in pfSense 2.1?.

Create file

/etc/rc.conf.local

samba_enable="YES" nmbd_enable="YES" smbd_enable="YES" winbindd_enable="YES"

IT is !  ;)

This unique IP is the DMZ

Seems I have to get used to being able to work with the Loopback interface in pfsense, glad to hear this is now fully supported. Thanks!

And by the way: thanks for a great job with the conversion of old configurations. I recently migrated two old pfsense 1.x to 2.1
without a hitch!

I would add some logging to the rules to attempt to determine which rule the traffic is matching.

Ok, will do and report back…

//Danne

UPDATE:
I have now installed 2.1-RC1 (i386) built on Wed Jul 31 07:16:49 EDT 2013 and it now works perfectly.  :D
Have tested a few times to add and remove. Also checked ping before and after to verify that the IPAlias is actually
working when defined and that the ping stops (which is correct) when removed.
You could close this topic now.

We roll snapshots labeled with a specific RC number more as a level (e.g. ALPHAx, BETAx, RCx). We used to do more formal "releases" but then people tended to get stuck on them and think they never needed to update to a -RELEASE.

So these days, we may occasionally roll one out formally, but most of the time the only "releases" are actually the -RELEASE images.

An RC snapshot could technically become -RELEASE if we wanted it to, though the version number would need updated and a new build performed, everything else would be the same.

Typically when it's time for that to happen we shut down access to the snapshots server for a while so people don't grab a -RELEASE image that isn't really the one, true, final -RELEASE if we find things that necessitate rolling a new set of images.