Current snap is OK:

2.0-BETA4 (amd64)
built on Tue Nov 9 17:26:01 UTC 2010

Current snap is OK:

2.0-BETA4 (amd64)
built on Tue Nov 9 17:26:01 UTC 2010

Current snap is OK:

2.0-BETA4 (amd64)
built on Tue Nov 9 17:26:01 UTC 2010

It's not all. What we can see at 1 Jan 00:05!
It's not a bug. This is future from guys who can find sunrises in Internet and can understand what is “previous period”. :) I can't understand. IMHO,  it is a sample of broken logic: a page view information around 4 years - what is “previous period” for whole page, for each graph?  Also more difficult to quick check situation on floating density of graphs.
I manually revert settings to standard network graphing with floating window as we can see in other network products.
I need this actually not only for me.

Kernel issues regarding panics are solved.
As far as the scripts/programs involved you can check commits.

I had a similar thing happen to me once. In my case it was due to LastPass's autofill function. For whatever reason it replaced the pppoe password on that page then automatically hit the submit button for me. I had to get on a LAN host and fix it, after hitting LastPass with a hammer of course.

Thanks. I'll check today again with new snapshot and confirm if it is working.

Looks like there was an issue with one of the commits made over the weekend to fix a security issue. It should be fixed after the commits that just happened. It should be fixed in the next new snapshot dated after this post.

In the outbound rule I would set the source to

10.0.0.3/32 and remote the port assignment…

Skynet 10.0.0.3/32 * * * YES
Skynet 10.0.0.0/24 * * * NO
Somnet 10.0.0.0/24 * * * NO

Also as other said you should not need to port forward anything for your provider to work... You only need port forward when you want to register phone to a SIP server you might have on your side, but since you're talking about a ATA, you should not need it, the registration should take care of everything. The outbound NAT below should take care of sending the traffic coming from the ATA to Skynet.

hi

it's overwritten, or wiped out, or back to default…whatever you call it. so you might want to copy your modified files somewhere, say admin's home directory or usb key, do the upgrade then copy back to where those files were. i've been doing this for years since 1.2...

cheers,

Just to let you: this issue seems to be solved. Been running for 3 days without problems. The solution was simple: just check "Hardware Checksum Offloading".

This is the only option that is not checked by default. So far, it worked.

Can anybody confirm these issues or if I'm doing something wrong? I really wanna stay on pfsense and not move to anything else….

i need NAT on opt1 :(

Hi jimp,

sorry for the very late answer. I wasn't able to upgrade since those multi wan and nat issues.

Now I upgraded to today's snapshot and those "pfctl: DIOCADDRULE: Device busy" errors disappeared completely.

Thank you very much for the fantastic work!

I tried that  but I am getting:

pkg_add -r snort
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.1-release/Latest/snort.tbz… Done.
pkg_add: warning: package 'snort-2.8.5.3_1' requires 'pcre-8.02', but 'pcre-8.10' is installed

=========================================================================
Snort uses rcNG startup script and must be enabled via /etc/rc.conf
Please see /usr/local/etc/rc.d/snort
for list of available variables and their description.
Configuration files are located in /usr/local/etc/snort directory.

NOTE: Starting with Snort 2.4.0 (released on 2005-04-22)
      the rules are no longer included with the distribution.
      Please download them from http://www.snort.org/rules/.
      You might consider installing security/oinkmaster port to simplify
      rules downloads and updates.

It's static IP. Both server point to same gateway.

Let's called it server A (PF 1.2.3) and server B (PF 2.0).

When I monitor arp (tcpdump) request on server A. I can see server B looking for the gateway. I also can see some gateway arp. But when I run tcpdump  on server B, I just can see server B looking for gateway. No arp packet from gateway and server A.

Only way out is to reinstall from a good ISO (the 15xx iso from the 3rd is OK I believe) and you might be able to do a recovery install to reload the config from the hdd. Otherwise you'll need to restore from a backup.