In theory it should work though the last time I tried it in a VM the upgrade locked up - though it did complete, I had to force a manual reboot.

We have some workarounds in place to help facilitate the switch (it keeps a copy of the 32-bit reboot binary aside just in case), but apparently there's more to it than that now.

You do have to completely delete all of your RRD graphs after the upgrade because the data format changes from 32 to 64 bit.

If you watch the bug reports, you'd noticed that some of the "breakage" comes when trying to fix other bugs that have been in the list for ages. Sometimes progress comes with growing pains, but in the end it gets worked out. I agree there has been a bit more breakage than usual over the past couple weeks but each thing that broke was an attempt to fix a different issue.

As often happens with such wide-reaching projects, it may work OK in our testing but fails for users in certain specific configurations. We can't possibly test every combination of configuration possibilities out there, which is where the testing help from the community is really appreciated.

There is always a little bit of danger with snapshots. I usually load one up in a VM and make sure it functions well for certain key things I need before attempting to upgrade my real hardware firewall.

I added a ticket to remind us to add a checkbox on the openvpn config pages to add this to the config in future versions:

http://redmine.pfsense.org/issues/1120

Even if someone has crypto hardware they may want to disable its use for testing/comparison (People often install an older accelerator card in fast hardware only to find out it's actually slower than using the CPU directly.)

Take a look at the console and the logfiles while you click save. You need physical access for that though…
If you are not on the latest snap then always update to latest before reporting a problem...

@grazman:

The sip server is local, but it declines to match packets whether i use the local IP address or not. I simply "restated" the sip server name (replace asterisk) and changed the RTP range. When a call goes to the trunk provider, it matches the RTP range but still goes in the default queue.

Since all of my media is anchored by my sip server, I simply added a LAN rule to match all traffic from it and place it in the voip queue, but I've never had to do this before.

I also think some of the queue's are not being created using the wizard (which i defaulted the customization by updating and removing the shaper and running the default asterisk shaper script).

This is still happening through the Dec. 19 snapshot. Also, the custom port definitions that were in the original VOIP shaping rules are no longer in there (i.e. udp 10000-20000 for asterisk rtp), and matching by ip address does not work. If adding a lan rule to match the traffic, it only recognizes one direction, adding a second rule for the other direction does not work and ceases to recognize any traffic in the desired queue.

Since mcrane has moved onto FusionPBX, I suspect we won't see the old Freeswitch package on 2.0 (I believe it's not there because it doesn't work on 2.0/PHP5). Hopefully mcrane will create a FusionPBX package on 2.0 though, until then there are the instructions clarknova linked.

well load balancer is the only choice to make both WAN to run.

in server listening port : wich port?

in server IP address :  what i have to fill in? wan ip?

after that just add to pool enable and save it?

no need to do anything in firewall rules?

I am newbie in pf2.0, look confusing in setting.

Bump!

Do nobody know this?
If I do remember correct, this was an easy task in pfSense 1.2.3

Package is installing fine now, thanks, and logging is working. I opened new IPsec thread.

Reinstalled ok

I know it's been a few months, but wanted to follow-up for closure.  Been waiting for Christmas break.

Your changes worked great! Thanks, again.

@senate014:

Hi Mitch,

You will solve the problem by simply doing the following:

Firewall > NAT > Outbound > Select "Manual Outbound NAT rule generation (Advanced Outbound NAT (AON))" > Then make sure the following rule is located in the table below:

Interface > WAN
Source > Your Internal LAN Subnet
Source Port > *
Destination > *
Destination Port > *
NAT Address > *
NAT Port > *
Static Port > YES

I have the exact same setup and has the exact same problem, I almost pulled my hair out until a friend showed me the light! :)

Cheers,

Andy

Not sure what the logic for updating DHCP received DNS servers looks like (I haven't looked at the code for that in 2.0 in quite a while), but if you have the allow override boxed unchecked it should probably not be updating that file.

Ahh, yes indeed. Doing iroutes for client-specific overrides on the server side, as well as adding "route 172.16.21.0 255.255.255.0" to the server side options has fixed it. Thanks for the pointers jimp :-).

Further to this:
I am using the same hardware as jp141. I'm currently playing with the box so there's a good chance it's my fault  ::) but..

Twice now I have had the box unexpectedly reboot. Both times it just after I logged into the web GUI. I captured this error on the console:

Message from syslogd@pfSense at Dec 17 13:11:49 ... pfSense php: /index.php: Successful webConfigurator login for user 'admin' from 192.168.1.100 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address  = 0x10317 fault code              = supervisor read, page not present instruction pointer    = 0x20:0xc096066b stack pointer          = 0x28:0xec2bfb38 frame pointer          = 0x28:0xec2bfb3c code segment            = base 0x0, limit 0xfffff, type 0x1b                         = DPL 0, pres 1, def32 1, gran 1 processor eflags        = interrupt enabled, resume, IOPL = 0 current process        = 11 (irq256: mskc0) trap number            = 12 panic: page fault cpuid = 0 Uptime: 13m52s Cannot dump. Device not defined or unavailable. Automatic reboot in 15 seconds - press a key on the console to abort Rebooting...

I'm running the 13/12/2010 2G embedded snapshot.

I have no idea how to read this. :-[

Steve

Thanks for your help, I think I got it to work, but I couldn't get the traffic to use the root queues. Intead I created a child queue with bandwidth set to LAN speed minus qInternet and set the floating rules to use the new queues.

Should be fixed now:

https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/f889516190ab1ec29ab533c662d932bb4f02c392

The console is not a "live" screen. It is printed and then left there. It's non-trivial to just update the screen and then redisplay the menu.

Printing a message just adds text at the end of the window and then scrolls down.