Arg, nevermind, as soon as I post for these things I end up figuring it out (can add users by going to System -> User Manager).

Thanks for reading anyway!!  ;)

Not sure why point one is an issue, not much has changed with how that domain setting is used since 1.2.3 that I can think of.

Point 2 I haven't seen or heard of, but ipv6 isn't supported in pfSense (yet) so that isn't surprising.

Point 3, that worked last time I tried it, but there has been a lot of work done on gateways in the past two days. Unless you're on the most current snapshot and testing these things, it doesn't mean much (and even then, when reporting issues with a snapshot please mention the architecture and complete build timestamp)

I would expect problems when running a months-old snapshot. When testing, staying current (but testing in a VM first if possible) is always advisable. And backups. Keep plenty of backups.

They are basically just a type of rule that exposed some of the more advanced options.

Okay. Now it works. WLAN and LAN do not have any ip addresses anymore, just the bridge itself…

Thanks for your help!

Hi,

There are still issues with Layer7.
You can track progress by visiting: http://redmine.pfsense.org/issues/636

Greetings to China ;)

Sullrich Sorry but I did not understand how I can do that, I tried configuring database syncrhonization voucher but do not know what parameters should be introduced or how to configure the server db vouchers.

Thank you for your accurate response.

The captive portal configuration  is very simple

Enable and Interface: Lan

I added all well known clients and some of them (MS windows client, MAC OS and IPod) are blocked by captive portal authentication page.

–---------------------------------

There is only one log which appear in the system log

php: /services_captiveportal_mac.php: The command '/sbin/ipfw delete 77; /sbin/ipfw delete 78' returned exit code '69', the output was 'ipfw: rule 78: setsockopt(IP_FW_DEL): Invalid argument'

and Portal Auth page

Sep 16 12:31:18 logportalauth[42107]: ACCEPT: unauthenticated, 08:00:27:3e:a1:a4, 192.168.1.116
Sep 16 11:10:46 logportalauth[45822]: ACCEPT: unauthenticated, 00:18:41:e1:1a:3c, 192.168.1.156
Sep 16 10:50:05 logportalauth[45822]: ACCEPT: unauthenticated, 00:24:9f:3f:fd:0b, 192.168.1.127
Sep 16 10:28:45 logportalauth[50046]: ACCEPT: unauthenticated, 00:23:14:ae:30:08, 192.168.1.161
Sep 16 10:16:14 logportalauth[45822]: ACCEPT: unauthenticated, 00:23:14:ae:39:90, 192.168.1.158
Sep 16 09:56:21 logportalauth[54770]: ACCEPT: unauthenticated, 5c:59:48:a1:8c:09, 192.168.1.121
Sep 16 09:53:44 logportalauth[54770]: CONCURRENT LOGIN - REUSING OLD SESSION: unauthenticated, 00:26:37:14:49:4a, 192.168.1.181
Sep 16 09:53:44 logportalauth[54770]: ACCEPT: unauthenticated, 00:26:37:14:49:4a, 192.168.1.181
Sep 16 09:52:05 logportalauth[54770]: ACCEPT: unauthenticated, 00:26:37:14:49:4a, 192.168.1.181
Sep 16 09:45:43 logportalauth[50046]: ACCEPT: unauthenticated, 00:21:e8:b9:af:74, 192.168.1.185
Sep 16 09:43:44 logportalauth[45822]: ACCEPT: unauthenticated, 00:21:6a:85:f5:58, 192.168.1.128
Sep 16 09:37:45 logportalauth[50046]: ACCEPT: unauthenticated, 38:e7:d8:02:1d:f3, 192.168.1.146
Sep 16 09:34:38 logportalauth[54770]: ACCEPT: unauthenticated, c4:17:fe:fb:c0:24, 192.168.1.208
Sep 16 09:30:44 logportalauth[22939]: ACCEPT: unauthenticated, 00:26:9e:3b:36:86, 192.168.1.235
Sep 16 09:19:45 logportalauth[54770]: ACCEPT: unauthenticated, 40:2b:a1:e0:74:a9, 192.168.1.186
Sep 16 09:16:46 logportalauth[50046]: ACCEPT: unauthenticated, 00:23:8b:75:90:3d, 192.168.1.120
Sep 16 09:15:01 logportalauth[45822]: ACCEPT: unauthenticated, 00:22:15:44:73:14, 192.168.1.134
Sep 16 09:06:33 logportalauth[58101]: ACCEPT: unauthenticated, 00:1b:fc:df:8f:2a, 192.168.1.240

But these are unknown MAC address which are not the allowed list

The very strange one, my Debian server was able to access to internet since the morning but later during lunch time, it was not able. there is no log about that server in PFSense.
I just re-create and it solved.

There were some issues with the remove list not being honored (making the snaps larger than they should have been) and some missing kernel modules… a new build is going now, hopefully it comes out ok

That's normal under some circumstances, it's fine.

Hi

I had the same issue, i just disabled a gre rule that I had created before just for testing in the wan interface, then the pptp connection from behinde the pfsense has worked succefully.

Yes, I mean the Floating tab in Firewall rules. If you don't use it I think DMZ-LAN traffic is not affected.

I updated a VM to that snapshot yesterday:

And I just updated another VM to the same snapshot right now. No issues on either one.

Does it make a difference if you re-select the snapshot URL from the drop-down list on the auto update settings?

The only device between my pfSense pc and the internet is an Asus WL-520GU router. Could it be because of Squid acting as a transparent proxy?

In any case, I installed pfSense 2 Beta 4, Sept 9 build and user expiry seems to be working now. :)

I went to check the error and it's not occuring anymore for me. maybe a browser issue on my end.
I'll look into it more if it reoccurs

Thanks for the Reply

I have this problem on all my interfaces with the latest update.
It worked for a long time, then the DMZ interface stopped showing with this error.
A couple of days ago, all of them stopped working. 
No logged errors.

Thank you Jimp!

You can load balance fine without NAT, but you usually have to NAT on all but one of the connections (can't send traffic sourced from a different ISP's public IP). If you have the same IP space on 3 connections, that will likely not work, you need a unique gateway IP for each connection to load balance.

A lot of work has gone into pfSense 2.0 since BETA3. Its probably time to upgrade your firmware.

@jits:

okay, thanks for replying. So, installing <<$beta_software>> at a major company with thousands of customer data at hand would be a big fat hairy no,no. Got it! Think I'm gonna be sick.

There, fixed that for you.

I updated today (2.0-BETA4 (i386) built on Sat Sep 11 15:41:29 EDT 2010) and can say, its failing still completely!

PPP was not up after reboot which comes after install and all scripts went on.

When PPP was up finally nothing more happened in the system-log:

PPP-log:
Sep 12 12:04:19 ppp: [wan] IFACE: Up event
Sep 12 12:04:19 ppp: [wan] 87.79.y.y -> 195.14.x.x

System-log:
Sep 12 12:01:59 php: : Resyncing configuration for all packages. –> at 12:09 this is still the last entry.
Sep 12 12:01:58 php: : Creating rrd update script
Sep 12 12:01:58 last message repeated 2 times
Sep 12 12:01:58 php: : Could not find gateway for interface(wan).
Sep 12 12:01:56 php: : phpDynDNS: (Unknown Response)