Works fine here… built on Fri May 13 23:17:13 EDT 2011

The VPN might not be reconfigured, but it could be that the states are getting dropped, causing them to reconnect. Some others have reported (but no devs have been able to reproduce it…) that states get reset when filter rules are edited/applied.

That used to say "close", the code behind the button changed at some point.

Well the 64-bit updates are really meant for people who installed from 64-bit ISOs… we just don't have any code in the upgrade that checks (and can't add any to 1.2.3... that boat has sailed) the architecture of the new update file to prevent foot-shooting. It may very well work for some people... so it's one of those "Try at your own risk" / "Here be dragons" areas.

Currently on i386. I wonder if this is related to the "Unable to check for updates." on the dashboard and the "Could not contact custom update server." on the auto update page under the firmware upgrade. EDIT This router has been running for a while, started out with v1.2.3 and then the 2.0 alphas and then about once a week until we're at 2.0RC2. Pretty sure there is some issues resulting from that. I might just wipe the drive in the router and start fresh.

ok, clicking the links to download the files should work again. I cleaned up some more code along the way.

That rule isn't right, but there isn't enough information to really tell you what the right rule would be. If you are using floating rules, rather than rules on each interface, it gets much more confusing to setup. Either way you need two rules: Pass any proto from <local subnets="">to <local subnets="">gateway <default>Pass any proto from <local subnets="">to <any>gateway <whatever gateway="" group="" you="" want="">The first rule bypasses the policy routing for the outbound load balancing/failover. If you use floating rules, those should only be applied in the "in" direction on the internal interfaces.</whatever></any></local></default></local></local>

The jump probably isn't just from the update check, several AJAX timers are delayed and only kick off a few seconds after the initial page loads. You may stop one thing and find that what annoys you is something else entirely.

Update to a current snapshot and try it again, post the "bt" command from the db> prompt as well as the panic message next time if it still panics.

I have a testing network that I need to keep somewhat separate from the LAN.  The only reason I need pfsense to even know about this network is we have people that need to PPTP in on the WAN and be able to talk to machines on this test network. Basically it looks like:  Internet -> pfSense -> LAN network (10.1.0.0/24) -> Gateway ->Test network (10.2.0.0/24) If I could convince the VPN users to switch to OpenVPN then I suppose I could push routes rather than rely on pfSense having the static routes but they feel they know PPTP and they're scared to try something new.  I also tried just telling people that they had to manually add a route to the test network after bringing up the PPTP connection but that was too much for too many of the remote users to handle.

Yeah I figured that out earlier today. Thanks for the response.

/BOOT/LOADER.CONF once I compared the good loader.conf from my i386 build to the bad amd64 file and made the changes…it all worked perfect BAD loader.conf autoboot_delay="3" vm.kmem_size="435544320" vm.kmem_size_max="535544320" kern.ipc.nmbclusters="0" kern.hz=100 vmblock_load="YES" vmmemct_load="YES" vmhgfs_load="YES" vmxnet_load="YES"vmblock_load="YES" vmmemct_load="YES" vmhgfs_load="YES" vmxnet_load="YES" vmxnet_load="YES"vmblock_load="YES" vmmemct_load="YES" vmhgfs_load="YES" vmxnet_load="YES" vmxnet_load="YES"vmblock_load="YES" vmmemct_load="YES" vmhgfs_load="YES" vmxnet_load="YES" GOOD loader.conf autoboot_delay="3" vm.kmem_size="435544320" vm.kmem_size_max="535544320" kern.ipc.nmbclusters="0" kern.hz=100 vmblock_load="YES" vmmemct_load="YES" vmhgfs_load="YES" vmxnet_load="YES"

In what way is it not working? I have captive portal working using voucher validation but in some cases, after authentication, the browser doesn't automatically go to the page the user tried to access.

Really do not need to assign bridge as another interface and then just change description and possibly the ip back and forth to the new assignment. You want feel the difference. LAN/WAN is relevant only on 1.2.x series, i can not stress this that much. In 2.0 LAN is just a description.

Hmm, having more gateways than is necessary just seems like it might cause trouble with load balancing and fail over but perhaps not.  ::) I'm not sure why it didn't work on the other router perhaps it's hard coded to route out of it's wan port. It's a BT Home Hub 3. I'm using it as a WIFI access point on a separate interface. If I set a gateway in that subnet then devices connected to the access point can no longer access the internet. Steve

Hi, I recreated the scene in virtual machines and got the same result, but reading this document (http://doc.pfsense.org/index.php/Reset_States) understand that: when a new rule is applied, the state of the firewall is not automatically cleared to not harm any important connection at that time. Doing some more testing I realized that with the HTTP connections do not need to reset the states, I can delete one by one under Diagnostics -> States, but not the same thing happens if I'm running a ping in a terminal of a machine. Thanks by now. ;D

Thanks for digging into the code and such a detailed report.  It helps quite a bit.

Yes that would be the best solution if your modem supports it.  :)

Edit your first post subject