I've tried it couple of times, even after rebooting and still get the same message. Edit:  Well, after a few more tries, it finally worked.  Thanks.

No basically means it is not supported. However pfSense is more or less a freebsd system so you might get things working if you know what you are doing but there probably is nobody who can help you with that kind of setup. I would go with the small/simple modemrouter in front and use that one as gateway as this saves you from reapplying your changes with each new update or updates breaking your changes.

@sullrich: Okay, run this from a shell: /etc/rc.conf_mount_rw fetch -o /etc/inc/system.inc "http://cvs.pfsense.com/cgi-bin/cvsweb.cgi/~checkout~/pfSense/etc/inc/system.inc?rev=1.79.2.12;content-type=text%2Fplain;only_with_tag=RELENG_1" Perfect! Doing this, now the DNS is ok!! Great Job! Thank you!

It doesn't work. I selected "Bridge with : none", so I used a seperate subnet. The Lan subnet is 192.168.2.0/24 The WLan subnet is 192.168.3.0/24 All kinds of securities are off. Firewall rule for WLan is allowed from any to any XP client can get a correct IP (192.168.3.200), but no connection. What can be wrong?

Check at interfaces>wan the option "Block private networks" is checked. Your WAN is a private IP range. Btw, you don't need allow rules on WAN if all connections are opened from clients behind the pfsense to the outside world. you only need to open ports if you want to supply services to the public (you then need nat as well).

Good news  ;D

@sullrich: Yep, but some cards have been coming out recently that make me want to change my mind (unlimited writes).  But for some reason I just don't trust them yet. It's better to be safe than end up with dead cards.

@Aussie_Bear: Just to update… I downloaded ver 0.95c, and this issue has been resolved. It loads back all the settings from the floppy. :) Case closed :D Awesome!

Issues this command from the shell: update_file.sh /etc/crontab && killall -HUP cron

Fixed in 0.95.c

LOL, there's the option! (The floppy controller on this old setup died. I just tried PfSense on another box)

@sullrich: 3. look in system logs for ntop entries Looks like it gets killed due to lack of RAM (128MB), I didn't create a swap partition due to the CF card.  I didn't think ntop was such a memory hog, I usually have under 40% memory usage with it off. I gotta stop asking questions I can find answers to…. Sorry, but thanks.

@czappi: I Have now Install Vers. 0.94.12 but i have the same problems I become follow message in the systemlog. and time is not set. When enable Dyndns (dynamisch) i have no access to Internet. Bridge between LAN and OP2 (WLAN) is not possible the client become no IP adress, if i use not bridge but static with own dhcp on WLAN it works. Jan 1 01:26:56 inetd[2519]: 19000/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19000/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19001/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19001/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19003/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19003/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19004/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19004/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19006/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19006/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19007/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19007/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19009/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19009/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19010/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19010/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19012/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19012/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19013/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19013/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19015/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19015/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19016/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19016/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19018/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19018/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19019/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19019/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19021/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19021/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19022/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19022/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19023/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19023/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19025/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19025/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19027/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19027/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19028/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19028/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19030/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19030/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19031/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19031/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19033/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19033/tcp: bind: Can't assign requested address Jan 1 01:26:56 inetd[2519]: 19034/tcp: bind: Can't assign requested address Fixed in 0.94.12.

Just fixed by Scott. See http://cvstrac.pfsense.com/tktview?tn=703,6. Hopefully there will not be the problem in next release.

@Jesse7: @hoba: Any chance you have CARP configured? With CARP the machines are sending out "Hey, I'm still alive" broadcasts so other clustermembers know about the availablility. I don't think I had CARP enabled perhaps I did or had an option like that enabled.  Is carp enabled by default?  When I went to the page that allows you to configure carp nothing is ticked, but when I go to carp status it shows three nodes and there is a button "disable CARP"  no other info. And yeh I don't have the 2 second blinking anymore. CARP ip's are added under Virtual IP's.  They WILL make your switch port blink every second, its a heartbeat.

Awesome, thanks for your (and whoever contributed) efforts… (Regarding the Multi-WAN situation) Well, a few comments on the low-end system. It seems to handle pfSense...Just barely. Sometimes I get the box killing a process due to "lack of swap space" (The WebGUI would load halfway through something and stop... But if you refresh, its OK again). So yes, I think you need 64MB. (pfSense system status screen says about 70% RAM used when under load, and 59% when idle). 48MB RAM is possible, but I don't recommend it. I guess I need to hunt for some old EDO or PC66 SDRAM modules. (Maybe get a PowerLeap CPU upgrade adaptor to bring this old box up to a 400Mhz K6-2 setup?) I used the low-end box on a 10Mbit Cable, and it seems fine, as I'm getting full speed...Not sure of two 10Mbit lines though...Time will tell. A bit of a side question... The chipset the mobo has is an Intel 430VX. This does not allow for more than 64MB RAM to be cacheable. Its total capacity is 128MB RAM. Would this affect pfSense performance if it were to reside in the non-cacheable area of memory? I'm asking this as I'm not sure how BSD works under this scenario. (I know Windows would load into the upper regions when the RAM is non-cacheable and this would cause performance issues). My other box would be to use an EPIA PD10000…Which would be more than enough grunt for what I want to use a multi-wan firewall solution for.

Bridging OPT1 with WAN was what I did and its, by far, one of the simplest configurations.  Be aware that this will make it impossible to configure CARP fail over. Alternatively you could use Proxy Arp, which would require some minor configuration of your DMZ machines.  This (I think) will also break CARP fail over, and frankly, I can't think of any good reason to use this solution verus bridging the two interfaces. Finally, you could alias a bunch of IP addresses to WAN and use 1:1 NAT.  This is the most intrusive solution in terms of configuring your DMZ machines, but it means you can use CARP failover without drama and would allow you to obscure the actual IP addresses of your DMZ machines.

@manfred.herrmann: I would like to use pfSense in XEN virtual machine. On XEN there is a 5.3 based Kernel-Patch available. Please point me to a starting point for bsd newies :-) Is there a chance to use 5.3 with pfsense/freeSBIE ? Nope.  Not at this time.  Atleast not without you spending 40+ hours to backport everything.